This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: Merging calls to `abort'


Hi,

On Fri, Mar 11, 2005 at 03:28:19PM -0500, Richard Stallman wrote:
> Currently, I believe, GCC combines various calls to abort in a single
> function, because it knows that none of them returns.

afaics it is more generic. It merges them because it knows that it doesn't
make any difference. This is a "problem" we always will have when debugging
optimized programs and has nothing to do with the abort() function as it
is. E.g.:

  #include <stdlib.h>

  int main(int argc)
  {
        char str[] = "Howdy!";
        if (argc > 1) {
                printf("Got arguments.\n");
                puts(str);
        } else {
                printf("Got no arguments.\n");
                puts(str);
        }
        return 0;
  }

When compiled with -Os, the compiler will only generate two function calls.
In the printf-case it is possible to distinguish by looking at the
parameter, in the puts case there is no way of distinguishing if we are in
the `if' or in the `else' branch..

(when compiled with -fno-crossjumping everything is clear again)

> If the goal is simply to make the compiled code as small as possible,
> this is the way to do it.

That's what the user is telling gcc when he is calling the compiler with
-Os. One great thing of free software is it doesn't try to `patronize' its
users. Please do not let us start with that now..

As statet already, the abort information is pretty useless when the binary
is compiled without debug symbols. And usually the `production binaries'
shipped by distributors are built without debug symbols. So you would need
to rebuild with debug symbols anyways - why not just rebuilding without
optimization too when that is what one actually wants to do?

The fancy_abort() function someone suggested in the other mail always
works. And if the author of the software has developed a personal procedure
for looking into problems where a fancy_abort() isn't very helpfull (and it
looks like you did - but that doesn't mean automatically that everyone is
using this strategy for debugging software) then we are still confronted
with the problems stated above (deactiviating some optimizations doesn't
change anything because of the missing debug symbols).

> So maybe it would be better to treat abort specially in the opposite way:
> to inhibit merging two abort calls even in a situation where calls to
> some unknown function might be merged.

In my oppinion that would be pretty ugly. From the compilers point of view
the abort function is just a normal function with the __noreturn__
attribute. It's not a compiler builtin or something like that. Just
matching for a function name in the compiler and treat a function call
diffrently if it is to a function called "abort" is imo a strict no-do.

It would be possible to add a new attribute for such cases - but because of
the need-to-recompile-for-debug-symbols-anyways reason I don't see any need
for such an attribute.

yours,
 - clifford

--
 _  _       _      Nerds on Air - Radio for Geeks      _  __     ___
| \| |___  /_\   On 1st and 3rd Friday of the month   / |/ /__  / _ |
| .` / _ \/ _ \    21:00-22:00 CET on Radio Orange   /    / _ \/ __ |
|_|\_\___/_/ \_\     http://www.clifford.at/noa/    /_/|_/\___/_/ |_|
 
To understand recursion, you must first understand recursion.
 

Attachment: pgp00000.pgp
Description: PGP signature


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