Re: Target-specific FDE pointer sizes (2/3)

[Richard Sandiford <rsandifo at redhat dot com>]

Nick Clifton <nickc@redhat.com> writes:
>>   - People only ended up with unmarked ILP32 objects through using an
>>     undocumented combination of gcc command-line options.  I think
>> it's reasonable for tools like readelf (and gdb, etc.) to treat
>>     EABI objects as being ABI-conforming without any evidence to
>>     the contrary.
>
> Well no.  One of readelf's main purposes is to be used as a tool to
> investigate broken binaries.  Therefore it should never assume that any
> file is compliant with an ABI, just because it is supposed to be.  It
> should always be paranoid and check for compliance, and alert the user
> to any discrepancies.

But in the case of LP64 objects, there are no discrepancies.  That's my
point.  As far as the ABI spec is concerned, these objects have exactly
the form they're supposed to have.  They were never supposed to be marked
with a .gcc_compiled_long64 section.

In other words, if we do have the warning, we'll be warning about
objects that do exactly what the ABI says they should do.  Objects
that IMO we have little reason to believe might be invalid.

The ILP32 variation is one of those things that "just happened".
I talked about it being "semi-official", but I should really have
said that it's only semi-official in versions of gcc that emit
.gcc_compiled_long32 sections.  As far as I'm concerned, it's
just not supported in earlier toolchains.  I only handled it in
the bfd patch because (in that context) it was easy to do without
any detrimental affect to objects that follow the real ABI.

> Furthermore it should not seg fault or break when it is given a broken
> binary to investigate and it should gracefully handle any corruption
> that it encounters.

FWIW, I've not seen the wrong address size cause readelf to segfault.

Anyway, I don't want this thread to degenerate into a long and pointless
flamewar.  My objections are on record, and I've made then as best I can.
If you still insist on the warning after the above, just say so, and I'll
add it without any more whinging.

Richard