This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Merging calls to `abort'
On Monday 14 March 2005 04:00, Richard Stallman wrote:
> Steven Bosscher <stevenb@suse.de> wrote:
>
> system.h:#define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
>
> where fancy_abort is a, well, fancy abort that prints some more
> information about what happened, and where. IMVHO any moderately
> large piece of software that uses abort should consider using this
> kind of construct, or use assert.
>
> Look at the irony of this recommendation.
>
> This technique will work, but it is rather wasteful. Each abort call,
> if handled this way, requires two string constants that are redundant
> with the program's debugging info.
It is not as bad as you are trying to project it. All duplicate
strings are merged. And you should be happy with the function name
and line number, it gives the developers the exact location of where
a problem occured. Wasn't that your original complaint, that you
could not tell the line number of an abort?
> It also requires the user to
> change the program, which is a further inconvenience.
The only change it requires is a whopping *one* extra line in some
header that is included everywhere. Oh dear, what a terrible thing
to ask of the developer, what a terrible inconvenience for much more
accurate debugging information!
> What's the point of cross-jumping? ÂIt saves a certain amount of
> space; it has no other benefit. ÂAll else being equal, there's no
> reason not to do it. ÂBut cross-jumping abort calls interferes with
> debugging. ÂThat's a good reason not to do it.
Most people don't do debugging. For some reason you appear to think
that every free software user is also a free software debuggers.
Well, newsflash, that is not the case. The majority of free software
users have never even looked at the source code.
If users are going to report bugs, then for the developers it is very
useful to know the name of the function and the line where the failure
occured. The only way for a user to know this information, is when
the crashing program reports it. So you *need* a fancy_abort like
replacement of abort (e.g. gcc's fancy_abort, or assert) if you want
your users to be able to produce accurate bug reports.
> But you recommend a different solution to this problem: changing all
> the abort calls so that (1) they can't be cross-jumped and (2) they
> use even more space. If everyone follows your recommendation, not
> only will no abort calls ever be cross jumped, but the net result will
> be to make the compiled program even bigger than it would have been.
You don't have to change any abort calls in the source code, you just
replace the definition of abort. You are greatly exaggerating the
increase in space my recommendation would cause. And you complain
that no abort calls can ever be crossjumped, but you are saying that
should not ever happen anyway, so your point is moot.
> This makes no sense.
Your silly overstatement of the burden on the user to change the
program, and the point that crossjumping is a useless optimization,
are the only things that makes no sense.
> So please let's get rid of this optimization. Those who want to use a
> fancy_abort function will still be able to do so, but this change will
> be an improvement for the rest.
With your suggestion, "those who want to use a fancy_abort" are the
ones who pay. In case you had not noticed, this would actually
hurt a number of large free software projects, including GCC itself.
Gr.
Steven