Re: ELF expert's help/advice/opinion wanted for two bugs
On Tue, Jun 29, 2004 at 10:42:10PM +0200, Jeroen van Wolffelaar wrote:
> Lacking deep knowledge of the ELF file format myself, I'm looking for
> someone with better knowledge of it to advice on these bugs:
> http://bugs.debian.org/249435 : lintian
> objdump -T gives "Invalid operation" on some ELF files in
> /usr/lib/debug. Is this objdump at fault? On files without a dynamic
> section, usually objdump simply doesn't display the dynamic symbols,
> so why does it error out here?
> $ file /usr/lib/debug/usr/lib/gconv/ISO8859-1.so
> ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not
> $ objdump -T /usr/lib/debug/usr/lib/gconv/ISO8859-1.so
> objdump: ISO8859-1.so: Invalid operation
Because that fail has a dynamic section - but it's empty. This
confuses objdump terribly.
I don't know if it's an objdump bug or not but my inclination is not.
Files in /usr/lib/debug/ are normal libraries, but files in
subdirectories of /usr/lib/debug generally won't be now that
objcopy --only-keep-debug has been implemented.
> http://bugs.debian.org/256900 : ocaml
> The ocaml compiler produces executable elf's, but once stripped, they
> stop working. The issue is the placement of the bytecode, it
> apparantly is seen by strip as a needless section, good for debugging
> only or something.
> Advice on how to fix ocaml is welcome (or strip, if that is at fault,
> but that seems unlikely to me).
It's a bug in ocaml. If I'm interpreting this right, it's using space
on disk, not loaded by the ELF loader, and then opening the binary to
get at it. Here's the last section (sorting by file offset) in the
 .strtab STRTAB 00000000 020ca0 00327e 00 0 0 1
Here's the binary:
-rw-r--r-- 1 drow drow 157704 Jun 29 16:49 ocaml_binary
The end of .strtab is at 0x20ca0 + 0x327e == 147230. I assume the 10K
after that is bytecode. At least, it's meaningful data, and it has a
string signature at the end.
If you want to be able to use ELF tools on an ELF binary, then obey the
rules of ELF. Put the bytecode in a section, mark it loadable, and
read it from memory instead of grubbing around in /proc/self/exe.