Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm working on program to convert ELF executable files to our internal binary format and backwards using BFD.
I created hello word program and stripped it so it would be as simple as possible. Then I converted it to our binary format and back to ELF. Using readelf and objdump I compare original ELF to result of transforations. Most of information were the same, there were some small differences but I'm not able to say how serious it was. Disassembled code was the same.
When i run transformed ELF i get:
[peter@althotas linux]$ ./empty.elf
Killed
[peter@althotas linux]$
I wasn't expected it to run alright at the first time but now i need some info why was process killed, what info is missing or incorrect and where exactly it went wrong ?
Is there som error log somewhere ? Can I trace what exactly had happened ?
I have already try that. There are no useful info:
[peter@althotas linux]$ strace ./empty.elf
execve("./empty.elf", ["./empty.elf"], [/* 63 vars */] <unfinished ...>
+++ killed by SIGKILL +++
killed
[peter@althotas linux]$
I have already try that. There are no useful info:
[peter@althotas linux]$ strace ./empty.elf
execve("./empty.elf", ["./empty.elf"], [/* 63 vars */] <unfinished ...>
+++ killed by SIGKILL +++
killed
[peter@althotas linux]$
I'm working on program to convert ELF executable files to our internal binary format and backwards using BFD.
I created hello word program and stripped it so it would be as simple as possible. Then I converted it to our binary format and back to ELF. Using readelf and objdump I compare original ELF to result of transforations. Most of information were the same, there were some small differences but I'm not able to say how serious it was. Disassembled code was the same.
When i run transformed ELF i get:
[peter@althotas linux]$ ./empty.elf
Killed
[peter@althotas linux]$
I wasn't expected it to run alright at the first time but now i need some info why was process killed, what info is missing or incorrect and where exactly it went wrong ?
Is there som error log somewhere ? Can I trace what exactly had happened ?
Please post output of
Code:
readelf -l
readelf -d
for original and converted ELF
My guess is that those "small differences" are a big issue
Original empty:
[peter@althotas linux]$ readelf -l empty
Elf file type is EXEC (Executable file)
Entry point 0x80482c0
There are 7 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4
INTERP 0x000114 0x08048114 0x08048114 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0x00454 0x00454 R E 0x1000
LOAD 0x000454 0x08049454 0x08049454 0x00104 0x0010c RW 0x1000
DYNAMIC 0x000468 0x08049468 0x08049468 0x000d0 0x000d0 RW 0x4
NOTE 0x000128 0x08048128 0x08048128 0x00020 0x00020 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
Transformed empty.elf:
[peter@althotas linux]$ readelf -l empty.elf
Elf file type is EXEC (Executable file)
Entry point 0x80482c0
There are 6 program headers, starting at offset 52
My program works with logical sections and I did nothing with segments, but I know that loader treats file as a set of segments. There are biggest differences in program segments which was created by BFD from my information about sections. Like I said I am not able to say how serious these differences are, I started working on this just 2 weeks ago (it is kind of student project). So if anyone can advice me what info are crucial to execute program or how can I trace what goes wrong I would be glad.
PS: I tried strace with many options but it is useless, it always ends with:
execve("./empty.elf", ["./empty.elf"], [/* 63 vars */] <unfinished ...>
I disassembled transformed ELF and instructions and their addresses are all right (same as original).
I'm not completely unprepared, I did read ELF Specification and BFD documentation.
But thank you, you pointed me in right direction. Problem was in program headers, but not in big differences. BFD generates program header automatically from information about sections and I wasn't able to find a way to directly influence this. Our binary format is not rich enought to record all ELF section flags and when I transformed it back I lost some flags. BFD created wrong program header.
Now I add flags and it run fine, I'm going to try some more complex programs. But BFD generated Program header is still pretty different, it has less segments, different alignment and some other differences, but it looks it doesn't matter.
But I would still like to know answer to my first question. Is there a way to find out why was process killed ?
I'm not completely unprepared, I did read ELF Specification and BFD documentation.
But thank you, you pointed me in right direction. Problem was in program headers, but not in big differences. BFD generates program header automatically from information about sections and I wasn't able to find a way to directly influence this. Our binary format is not rich enought to record all ELF section flags and when I transformed it back I lost some flags. BFD created wrong program header.
Now I add flags and it run fine, I'm going to try some more complex programs. But BFD generated Program header is still pretty different, it has less segments, different alignment and some other differences, but it looks it doesn't matter.
But I would still like to know answer to my first question. Is there a way to find out why was process killed ?
Process image built by kernel and dynamic linker (ld-linux.so.2). Information how built such image is in the programs headers. If you program has wrong headers - no hope at all that process will run. Headers instruct kernel/ld-linux WHERE to look for the code and data in the file, WHERE in the memory each part should be loaded, what permission each segment should have - mess something in the headers -
almost every bit here important - and segfault is more than likely
for future questioner I like to tell my case even if my reply is not timely about this thread. because I couldn't find proper answer from google.
I also had the same result when I ran my app. application exactly got SIGKILL during execv syscall. please refer to below
and just try to set 0 on "mmap min address". it will give you clue.
================================================
Linux kernel 2.6.31 on x86.
CONFIG_DEFAULT_MMAP_MIN_ADDR:
This is the portion of low virtual memory which should be protected
from userspace allocation. Keeping a user from writing to low pages
can help reduce the impact of kernel NULL pointer bugs.
For most ia64, ppc64 and x86 users with lots of address space
a value of 65536 is reasonable and should cause no problems.
On arm and other archs it should not be higher than 32768.
Programs which use vm86 functionality or have some need to map
this low address space will need CAP_SYS_RAWIO or disable this
protection by setting the value to 0.
This value can be changed after boot using the
/proc/sys/vm/mmap_min_addr tunable.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.