This is the mail archive of the
mailing list for the binutils project.
Re: [Patch, moxie] Print 'bad' instructions in disassembly instead of aborting
On Sat, 29 Sep 2012, Pedro Alves wrote:
> 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.
Thank you for the lecture... But let's keep it real.
People (hacking bfd) add aborts all the time; I've given up on
trying to lecture people myself as you do above. ;) When they
don't know what else to write, they can at least write
BFD_ASSERT rather than abort now, with a standing chance of a
cleanup happening instead of SIGSEGV or calling abort to avoid
> >> 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)
I didn't mention it, as it was obviously implied that the code
receiving the longjmp would do such cleanups. It could do even
do a graceful exit or suggest that the user exits, as the gdb
state may be inconsistent.
> 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.
We were talking about disassembly and relocation inspection,
there's not much inconsistency to expect besides memory leakage.
> 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.
Yes: the intent was an improvement rather than a complete
remedy, catching existing bfd_asserts rather than a preferred
machinery for error handling.