This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] MIPS/BFD: Fix assertions with SGI IRIX files
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: binutils at sourceware dot org, gdb-patches at sourceware dot org
- Date: Wed, 31 Aug 2011 19:00:43 +0100 (BST)
- Subject: Re: [PATCH] MIPS/BFD: Fix assertions with SGI IRIX files
- References: <alpine.DEB.firstname.lastname@example.org> <email@example.com>
On Fri, 19 Aug 2011, Richard Sandiford wrote:
> > If an SGI IRIX ELF variation binary (also produced by binutils for some
> > target configurations) is loaded into GDB configured for the traditional
> > MIPS ELF variation, then a load of assertion failures is spat. They
> > actually come from BFD being confused.
> > As no user input, however unreasonable, should ever trigger assertions
> > and this is simply a case of an unsupported binary format, here's a fix to
> > convert the offending code to do proper error reporting instead.
> > Verified manually with GDB, the error messages are produced. I was
> > unable to trigger this problem with the linker, even though this piece of
> > code looks reachable within to me.
> How about just dropping the assertions? SHN_MIPS_TEXT and SHN_MIPS_DATA
> are easy to handle, and it looks like the code will behave sensibly
> regardless of SGI_COMPAT.
Are you sure this code is safe under the matching conditions given the
assertions to catch them? They were put there for a reason I presume,
perhaps exactly because the originator was not sure about this safety.
Do you happen to remember the story behind? I believe it's a moderately
recent addition as I do remember the times the SGI emulation was the only
one we handled (circa AD 1999).
> I realise you might be thinking that the user would like to know that
> they have the "wrong" emulation.
No, actually not at all. There's no point in making noise if things work
correctly; this just confuses people.
OTOH I think it would definitely make sense to teach tools like
`objdump', `readelf' and `file' even how to tell the MIPS ELF flavours
apart and report that to the user appropriately, although I realise this
may not necessarily be straightforward or reliable.
Also I think emulation selection could be made a bit more flexible in GDB
-- my observation has been that extra emulations are not easily accessible
even if built into BFD -- the logic just picks the first one that does not
reject the binary chosen outright and this does not really work well for
making the choice between traditional and SGI flavour MIPS ELF format.
That's a separate problem though and frankly a marginal one as far as I'm
> But if this is the only detectable difference, it's better just to carry
> on. If there are other detectable differences that cause real problems,
> we should try to diagnose the problem there instead.
> A patch to remove the assertions is pre-approved if you agree that's OK.
OK, but are you positive that'll be no regression? As would be silent
mishandling compared to one accompanied with these assertions, however
obscure they are.