I am working on a project that involves ELF binary file parsing. From past few weeks I am reading quite a bit on ELF format.
However, one thing I really want to understand is how linkers and loaders use the different sections in an ELF file. Can someone please suggest me some resources which can teach me about the same. Appreciate your help.
A detailed description of how an ELF linker works by the author of GNU gold can be found in a series of blog posts starting here.
(Runtime) loaders do not use any sections of the ELF files (a valid ET_DYN or ET_EXEC ELF file can have all section headers stripped). They only use segments. I don't know of any good description of an ELF loader, but here is a possible start.
Related
I am trying to link object files which had originally been created by two different assemblers. We have some legacy assembly code that was compiled into object files using an old MRI assembler for the 68332 processor. We are developing a new application with the GNU Binutils m68k v2.24. We would like to use the original object files as built by the old assembler without change. I have configured our build environment to do this. For historic reasons, our build environment links into three output formats: Srecord, ieee, and ELF. When I run this is succeeding without error for the Srecord and ieee formats. However, for the ELF output format, I receive the following errors:
m68k-elf-ld: failed to merge target specific data of file
As a result the Elf file is not created.
I am first trying to understand what this error message might mean but I was not able to. If anyone knows the GNU Binutils ld documentation enough to point me to where the error definition is defined I would appreciate this.
I have actually loaded our target and run the Srecord output. It seems to pass many tests the same as before so it appears that it is running to some degree.
It looks like our legacy object files may be in coff format format. I would guess that this is the problem. Is there any way to convert a coff file to ELF format?
Thanks in advance for any support.
It looks like our legacy object files may be in coff format format. I would guess that this is the problem. Is there any way to convert a coff file to ELF format?
objcopy can be used to convert between formats. However, to do this it has to have been configured to understand both formats. You can check what formats it accepts with objcopy --info (a shortened list appears at the end of objcopy --help).
If you objcopy doesn't support the required formats, then you'll have to build binutils yourself.
Good day, I am working with Codeblock IDE under Windows in C language and I got the static library in file ".a" with the development of some functions. I must see somehow the code of the functions in the file because i need.
I was reading a lot on the forum but I could not solve my doubt.
someone could help? Tanks!!
(People said that this should be an answer, so here it is!)
*.a files are compiled libraries on Windows (the file extension is different on different operating systems). You can't see the source code unless you decompile it (which is very hard or impossible).
(From another comment) However, if the library is from an open-source project, then you might be able to find the source code.
I am trying to figure out the differences between ELF executables linked for QNX and Linux, respectively.
Is the exact ELF executable format needed by QNX documented somewhere? Minimally, what sections, segments, entries, etc. do I need in an ELF file to get the QNX loader to execute the instruction at the specified entry point?
Have a ELF debugging file.
The file uses the DWARF format.
How can I convert it into the stabs format?
Are there any tools or methods that may be helpful to do this?
Thank You.
http://opensource.apple.com/source/binutils/binutils-20/src/binutils/wrstabs.c
is a link to code that extracts stabs information from ELF binaries. It is long messy and problematic.
There really is no pre-built converter. You would have to reverse engineer something like the code above. As Mats suggested, consider recompiling.
However I am guessing you have a legacy binary with no code behind it. DWARF format was something Sun did about 10+ years ago, which was kind of a flop for Sun, IMO.
This is link on reverse engineering a binary into assembler.
http://www.linuxsa.org.au/meetings/reveng-0.2.pdf
Once you have assembler, in theory, you can build a new binary. The problem is; entry points into extern functions and making them work with you linker correctly. You will also have to remove the stuff related to DWARF. Then recompile linking stabs I guess
However the http://dwarf.freestandards.org site where the documentation lives appears to be permanently offline.
It would have helped my answer A LOT if I knew your hardware.
Recently I tried to write a simple compiler on the linux platform by myself.
When it comes to the backend of the compiler, I decided to generate ELF-formatted binaries without using a third-party library, such as libelf.
Instead I want to try to write machine code directly into the file coresponding to the ELF ABI just by using the write() function and controlling all details of the ELF file.
The advantage of this approach is that I can control everything for my compiler.
But I am hesitating. Is that way feasible, considering how detailed the ELF ABI is?
I hope for any suggestions and pointers to good available resources available.
How easy/feasible this is depends on what features you want to support. If you want to use dynamic linking, you have to deal with the symbol table, relocations, etc. And of course if you want to be able to link with existing libraries, even static ones, you'll have to support whatever they need. But if your goal is just to make standalone static ELF binaries, it's really very easy. All you need is a main ELF header (100% boilerplate) and 2 PT_LOAD program headers: one to load your program's code segment, the other to load its data segment. In theory they could be combined, but security-hardened kernels do not allow a given page to be both writable and executable, so it would be smart to separate them.
Some suggested reading:
http://www.linuxjournal.com/article/1059