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: [Patch, moxie] Print 'bad' instructions in disassembly instead of aborting


On 09/28/2012 09:30 PM, Hans-Peter Nilsson wrote:
> On Fri, 28 Sep 2012, Joel Brobecker wrote:
>>> If other ports are doing this, it's an accident waiting to happen.
>>
>> ISTR bfd doing it too, because we tripped over something like that.
>> BFD noticed a bad RELA entry and thought it was a sign of an internal
>> error. So it aborted
> 
> It should have called bfd_assert.

Invalid input should not assert -- it should be handled
gracefully, unwinding all resources the library has allocated,
and bailing out, making sure bfd is left in a consistent state.
Assertions should be left for bfd's own logic errors, meaning, true bugs.

>> and GDB never had a chance to handle the situation
>> more gracefully.
> 
> Have a look at bfd_assert in bfd.c.  GDB is one of those libbfd
> clients that would benefit from calling bfd_set_assert_handler
> (recently added, post binutils-2.22) with a handler function to
> do longjmp to error recovery of the current command or
> something.  See ld/ldmain.c for usage.

Simply longjmp-ing (with no cleanup mechanism like gdb has) on input validation
failure and not really caring to make sure bfd is left in a consistent state,
and with all temporary resources unwound correctly (heap, obstacks,
whatnot) would work for ld, because that's not an interactive process that
has to worry about long runs.  gdb is.

So it's probably a good idea to install such a handler, for the rare
true bfd bug, but using it for invalid _input_ is a hack.  Please don't.

-- 
Pedro Alves


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