Target-specific FDE pointer sizes (2/3)
Nick Clifton
nickc@redhat.com
Mon Jan 31 11:47:00 GMT 2005
Hi Richard,
>>I think that if readelf has to guess it should inform the user that it
>>is doing so. That way the user has a chance to realise that readelf
>>might have guessed incorrectly and that is why its output does not match
>>their expectations.
> Any chance of persuading you otherwise? ;)
You can always try. :)
Three reasons:
>
> - It doesn't seem very useful to print a warning if the user has no
> way of overriding the guess.
But without a warning the user will never know that the guess has been
made. Even if the user can do nothing about it, at least they will know
that it has been made. They could then even get hold of the readelf
sources, modify them to change the guess and then re-run readlef, if
they think that that will help.
> If we do warn about this, I suppose
> we'd also have to add a MIPS-EABI64-specific command-line option
> to readelf, and like I said in my original posting, I'd really
> rather not do that. There's certainly no precedent with the
> existing options.
I agree that there is no precedent for such an option, but that does not
mean that it cannot be added. I would be happy for it to be omitted for
now however. We could wait to see if there is a demand for such an
option from users of readelf.
> - I don't want to warn about unmarked LP64 objects since there's
> nothing suspect about them. They do exactly what the official
> ABI said they should do.
OK.
> - 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. 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.
Cheers
Nick
More information about the Binutils
mailing list