Re: Malformed phdrs in separated debuginfo

[Mark Wielaard <mjw at redhat dot com>]

On Fri, 2014-02-28 at 13:26 -0800, Roland McGrath wrote:
> A separate debuginfo file is a special animal and I don't think we should
> expect that every random thing that handles fully-formed ELF files will
> handle debuginfo files without being confused.
> 
> I think extra header bits and such are a rat-hole of effort, hassle, and
> slow deployment, with very little payoff.  I'm against that idea.

I am (naively) somewhat more optimistic about the effort, if we could
agree on an approach recognized across the whole toolchain. But I am
afraid you are right about the slow deployment and little payoff part at
least. So...

> Heuristically, a separate debuginfo file with phdrs can be recognized by
> there being SHT_NOBITS sections whose sh_addr places them in parts of
> PT_LOAD segments that cannot be the bss-like case.  If any section with
> SHT_NOBITS,SHF_ALLOC has its sh_addr fall inside the range [p_vaddr,
> p_vaddr+p_filesz) of a PT_LOAD segment, it's either a debuginfo file or a
> malformed oddball.

Yeah, that is kind of what the checks in readelf do now (or actually the
inverse, they check that there is an actual section matching the vaddr,
which is slightly less accurate, but seems to work just fine). It is
probably an heuristic that always works, but it keeps being an heuristic
that requires both headers are available. Probably the best/only thing
to do is to just trust the phdrs if there are no shdrs. It is just a
pity because you have to remember to do the extra checks before trusting
any data the phdrs might point to.

Cheers,

Mark