[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shrinking "assert (X)" and "abort ()"

From: Bruno Haible
Subject: Re: shrinking "assert (X)" and "abort ()"
Date: Fri, 6 May 2011 20:03:36 +0200
User-agent: KMail/1.9.9

Hi Paul,

> Sometimes I'd rather have something smaller and faster
> in production code, something like this:
>   #if __GNUC__ < 3 || (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
>    #define __builtin_trap() abort ()
>   #endif
>   #define assert(X) ((void) ((X) || (__builtin_trap (), 0)))
> as this is good enough if you have a debugger

Honestly, I think this would be a misfeature. Precisely because when you
want to debug this, you have no clue. "Illegal instruction" typically
means either a compiler bug or a function pointer that points into random

I once ran into such a __builtin_trap. It was generated by gcc for code
such as

       mode_t mode = va_arg (args, mode_t);

and I had an illegal instruction in front of me. With abort() and assert(),
on the other hand, you can even do remote debugging: You can ask a tester
to run gdb and issue the command "where". You will get a nice stack trace
with either abort() in it, or __assert_fail(). So you get a clue about
what happened.

My objection would be void if
  - the assert(X) macro would expand into small machine code and extra
    debugging information (in non-loaded ELF sections) which includes
    the message X, and
  - gdb would be taught to understand this debugging information and
    include it in its stack trace.

But that's not the state of the art:

$ cat foo.c
static int foo (int x)
  if (x == 3)
    __builtin_trap ();
  return 2*x;

int main ()
  foo (42);
  foo (3);
  return 0;

$ gcc -g foo.c
$ gdb a.out
(gdb) run
Starting program: /home/bruno/a.out 

Program received signal SIGILL, Illegal instruction.
0x080483cd in foo (x=3) at foo.c:3
3         if (x == 3)
(gdb) where
#0  0x080483cd in foo (x=3) at foo.c:3
#1  0x080483f4 in main () at foo.c:11
(gdb) x/i $eip
=> 0x80483cd <foo+9>:   ud2a   

In memoriam Pim Fortuyn <http://en.wikipedia.org/wiki/Pim_Fortuyn>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]