This is the mail archive of the binutils@sources.redhat.com 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: Problem with linker with binutils-040414


> -----Original Message-----
> From: binutils-owner On Behalf Of Nick Clifton
> Sent: 19 April 2004 10:36

> Hi H. J.
> 
> >I don't think it is a good idea. Linker should try to avoid core dump
> >on bad input. But linker should abort/core dump when there is an
> >internal bug. In this particular case, core dump helped 
> uncover/fix the
> >linker bug. Otherwise, we might discover this bug much 
> later. I suggest
> >we back out this patch or change it to
> >
> >	if (abfd == NULL)
> >	  abort ();
> >  
> >
> I disagree.  The library should never abort.  I can see the case for 
> reporting internal errors with a sensible error message, but an abort 
> (even with a message) is not correct.  Possibly the caller of the 
> library will be able to cope with the error and try another way to 
> perform its function.  Or maybe partial completion of the library's 
> functions will allow the user to proceed further with the 
> work that they 
> are doing.  Either way the library is providing a service to its 
> caller.  It should not dictate that the caller must terminate 
> execution.  Instead it should provide a sensible error indication and 
> allow the caller to decide what to do.

  I understand your reservations about making a library abort (hell, some
systems don't even implement abort!), but I'm not sure if your
counterexamples make sense:

>   Possibly the caller of the 
> library will be able to cope with the error and try another way to 
> perform its function.  

  Well, that's perfectly reasonable in the case of something like a
transient malloc failure or an I/O error, but in those cases bfd already
returns reasonable errno values, and the calling application knows what to
do.  But in the case we're discussing here (and similar cases), there's a
bug in bfd that has led the internal data structures to end up in an
inconsistent state that can't survive further processing.  Would there
really be any point in inventing and in such situations returning a new
errno value called something like
EINTERNALBUGHASTRASHEDINTERNALDATAMAKINGITIMPOSSIBLETOCONTINUEBECAUSEITWOULD
CAUSEASEGVPLEASETRYSOMERANDOMOTHERWAYOFDOINGWHATYOUWANTED?  Just how many
alternative ways are there to open an input bfd and add it's symbols,
anyway?

>   Or maybe partial completion of the library's 
> functions will allow the user to proceed further with the 
> work that they are doing.  

...and return
EINTERNALBUGHASTRASHEDINTERNALDATAMAKINGITIMPOSSIBLETOCONTINUEBECAUSEITWOULD
CAUSEASEGVPLEASETRYSOMERANDOMOTHERWAYOFDOINGWHATYOUWANTEDOHANDBYTHEWAYIDIDHA
LFTHEJOBBUTYOUDONTKNOWWHICHHALFORWHATRESOURCESNOWNEEDDEALLOCATINGORANYTHINGI
MPORTANTABOUTHOWFARTHROUGHTHEJOBIWASBEFOREIGAVEUPWITHOUTCLEANINGUPBEHINDMYSE
LF in errno, I suppose.

  Do you mean that maybe it would be worth doing a link with only half the
symbol table correctly read in from the input bfd because just maybe none of
the symbols in the second half are actually referenced anywhere so we
wouldn't need them anyway and so we might just get a valid final link
output?

  Maybe, but I wouldn't spend much time trying that sort of approach myself.
We can't know that whatever error caused the failure to correctly read part
of the symbols (and which somehow caused the internal data to become so
badly self-inconsistent that we later on ended up with a NULL pointer
supposedly pointing to a vital data structure) didn't also randomly
overwrite some of the values or type flags of other symbols, without
producing any obvious sign that they now have the wrong value or type?

  Silently producing invalid output is worse (IMO from an end-user's point
of view trying to debug why their application doesn't work) than crashing
and letting them know there's a genuine problem.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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