[RFA:] In bfd_assert at the end, call _exit (EXIT_FAILURE)

[RFA:] In bfd_assert at the end, call _exit (EXIT_FAILURE)

[Hans-Peter Nilsson]

I can't find the posting where Nick asked for patches after
finding consensus that bfd_assert should exit rather than
continue (causing incorrect files to be written and the point of
failure only noticeable by inspecting build logs), but here's
the simple approach I took.  No regressions for cris-elf.

Ok to commit?

bfd:
	* bfd.c (bfd_assert): Call _exit (EXIT_FAILURE).

Index: bfd.c
===================================================================
RCS file: /cvs/src/src/bfd/bfd.c,v
retrieving revision 1.106
diff -p -u -r1.106 bfd.c
--- bfd.c	20 Nov 2008 09:28:06 -0000	1.106
+++ bfd.c	23 Mar 2009 14:46:44 -0000
@@ -911,6 +911,12 @@ bfd_assert (const char *file, int line)
 {
   (*_bfd_error_handler) (_("BFD %s assertion fail %s:%d"),
 			 BFD_VERSION_STRING, file, line);
+
+  /* We used to just return from bfd_assert, but that caused more
+     grief than relief.  The different code paths for bfd_assert and
+     _bfd_abort could be united but keeping them separate can
+     simplify debugging.  */
+  _exit (EXIT_FAILURE);
 }
 
 /* A more or less friendly abort message.  In libbfd.h abort is

brgds, H-P

Re: [RFA:] In bfd_assert at the end, call _exit (EXIT_FAILURE)

[Daniel Jacobowitz]

On Mon, Mar 23, 2009 at 03:50:17PM +0100, Hans-Peter Nilsson wrote:
> I can't find the posting where Nick asked for patches after
> finding consensus that bfd_assert should exit rather than
> continue (causing incorrect files to be written and the point of
> failure only noticeable by inspecting build logs), but here's
> the simple approach I took.  No regressions for cris-elf.
> 
> Ok to commit?

My only concern about this is BFD's policy of behaving like a library
- which involves not quitting behind the program's back.  Should we
put this in gas and ld, instead?

I know GDB has triggered BFD errors in the past, and it'd be
disconcerting for them to make it quit.

My position on this is pretty weak.  I'd even be OK with the other
extreme: drop core here.  There's already a few calls to abort.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA:] In bfd_assert at the end, call _exit (EXIT_FAILURE)

[Hans-Peter Nilsson]

> Date: Mon, 23 Mar 2009 10:56:08 -0400
> From: Daniel Jacobowitz <drow@false.org>

> My only concern about this is BFD's policy of behaving like a library
> - which involves not quitting behind the program's back.

Oh right, *that*.

>  Should we
> put this in gas and ld, instead?

Some kind of bfd field to be optionally set after bfd_open,
perhaps?

> I know GDB has triggered BFD errors in the past, and it'd be
> disconcerting for them to make it quit.

Tripping over additional bugs certainly tend to cause additional
stress while debugging. :]

> My position on this is pretty weak.  I'd even be OK with the other
> extreme: drop core here.  There's already a few calls to abort.

...which FWIW is #defined to call _bfd_abort a few lines down.

brgds, H-P

Re: [RFA:] In bfd_assert at the end, call _exit (EXIT_FAILURE)

[Alan Modra]

Why have bfd_assert if it behaves like _bfd_abort?  I'd rather see
occurrences of BFD_ASSERT changed to calls to abort, if so doing makes
sense on a case by case basis.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [RFA:] In bfd_assert at the end, call _exit (EXIT_FAILURE)

[Hans-Peter Nilsson]

> Date: Tue, 24 Mar 2009 12:15:22 +1030
> From: Alan Modra <amodra@bigpond.net.au>

> Why have bfd_assert if it behaves like _bfd_abort?

See comment in patch.  Anyway, I retract it; see subsequent
discussion.

brgds, H-P