This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ELF phdrs in .debug files


> gdb doesn't, apparently.  What other consumers?

elfutils libdwfl.  There may be others we aren't aware of.  To begin with,
it's an incompatible, information-losing ABI change, and I think that alone
ought to be enough not to do it lightly.

I gather that gdb collates sections by name to determine what addresses in
the DWARF mean in the stripped file.  Relying on section names is not
kosher for a robust ELF consumer.  I'm aware of BFD's issues and I'm not
suggesting changing gdb.  But its limitations should not lead to imposing
its poor methods on others.  libdwfl follows the phdrs to find the
difference between debug file addresses and stripped file addresses, which
is a robust and very efficient method.

> I think having program headers in a debug file is fundamentally broken.
> After all, the primary purpose of a program header is to tell an
> operating system or loader how to go about preparing a program for
> executing.

I disagree.  Let's not go overboard on the rationales from fundamental
principles, and concentrate on being kind to consumers in practice.  There
is no formal specification for separate debug files, it's our invention.
But to be pedantic about it, I'd say that in ELF the program headers are
the normative specification of the memory layout of the program/DSO at run
time.  The section headers are completely optional in a fully-linked ELF
file and could be missing entirely from the stripped file.  (eu-strip does
not have an option to do this and it's not done in practice, but it's a
completely kosher and reasonable thing for stripping to entail.  Also, I am
already prepared in certain circumstances to work directly from a memory
image and not require looking at the stripped ELF file at all (only the
debug file), wherein the ELF image I have is truncated and has no section
headers available, but has plenty of info to be useful for debugging.)
Precisely because the phdrs are what must always still be available from
the stripped file, they are the right thing for the debug file to mirror to
enable address collation.

> A file containing only debug info isn't a program, so the program header
> is a lie, potentially confusing the loader.

A separate debug file is not a fully linked ELF file for a program whose
allocated sections are all bss, so the section headers are a lie.  It's a
separate debug file, not a normal ELF file.  A separate debug file is not a
program, so don't make the file executable.  A file containing the words
"lose faster" is not a program either.

For example, on Linux, a nonprogram without execute permission:
$ echo lose faster > foobar
$ ./foobar
bash: ./foobar: Permission denied

Now with execute permission:
$ chmod +x foobar
$ ./foobar
./foobar:1: lose: command not found

Your point?  (Mine is, "So don't do that.")

> What's more, having the headers there increases debug file size, by
> considerably more than just the space for the headers.

I don't follow this at all.  The headers themselves are precisely all that
is required.  The p_offset fields in a debug file are not meaningful.  I
certainly never suggested including the allocated sections that the program
headers' segments cover (which would make it cp).


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]