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


> You're going overboard with the rhetoric.  The fact is that libdwfl is
> making use of information that no one has promised would be available,
> that originally was not available with --only-keep-debug, and is only
> in debug info files by accident.

Sorry, that smells badly of rhetoric to me.  elfutils has always made that
information available by intent.  In the absence of an actual specification
for debug files, there has never been any "promise" but the de facto
standard of what objcopy actually produced.  libdwfl makes use of
information that is the most natural to use for the purpose given the
letter and spirit of the ELF specification, and the implicit nature of the
debug files' format as not formally specified.

Look, we can go on with the rhetoric forever.  But I know you're not an
ass, and on good days I am not entirely an ass either.  So let's instead
get back to "be kind to the consumer".

> > 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'd say it is very fragile. [...]

You go on to cite BFD implementation issues on the producer side.  That
hardly constitutes a meaningful characterization of a consumer's method
based on a well-defined meaning of the format the producer is required to
yield.

> be cases where objcopy generates different program headers in a debug
> info file to those in the main executable.

I think that's a sign of a fundamentally flawed implementation (unless
you're only talking about p_offset values, which I've said don't matter).
strip-to-debug should not be recomputing anything having to do with memory
layout at all, just copying it verbatim.  Even as a generic tool, if
objcopy changes program headers (unless you're changing section addresses
explicitly) then it's not doing a faithful copying and that is just broken.

> If you want reliable copied headers, you are imposing a maintenance
> burden on anyone touching BFD.

The only reaction I have to this is some quip about a jigger of vodka in a
bathtub of gin, so I better just skip it.  Look, bottom line, if binutils
diverges from the established format, I'll just tell people, "binutils is
broken; use eu-strip."  I have no intention to wade generally into binutils
implementation issues.  I just thought it was only sporting to raise the
red flag.

> My point was to show that including program headers in debug info
> files can confuse consumers of ELF files, in this case the loader.

The point I made (and you snipped) is that debug files are not normal ELF
files and treating them as such is already a mistake.  Try starting gdb on
a separate debug file and doing some disassembly at a symbol--you get lots
of "add %al,(%rax)" or whatever instruction 0 is on that machine; I call
that a confused consumer too.  The example with the execute bit illustrated
why your particular example is red herring.  The general point is that
context matters, not just content.  The system is full of files that cannot
be unambiguously interpreted from their contents' format alone, and their
consumers all require context for what sort of content is expected in that
file.  

> _bfd_elf_map_sections_to_segments assigns file offsets to all the
> NOBITS sections.  These file offsets comply with the usual ELF
> constraint that they be equal to the section vma modulo max page
> size.  Net result is wasted file space.  We could change this
> specially for --only-keep-debug, but again this means a mainenance
> burden.

In fact, the only formal constraint about section addresses in ELF is that
they respect sh_addralign.  From this and the requirement on program
headers that p_offset and p_vaddr be equal modulo p_align, flows the
constraint that sh_offset and sh_addr must both be aligned to sh_addralign,
but that is all.  (Indeed, the SHT_NOBITS sections produced by libelf
sometimes have gratuitous padding for sh_addralign alignment, but that is
almost always small.)


Thanks,
Roland


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