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 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
invalid output.

> >> 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.

brgds, H-P


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