DragonFlyBSD

could you supply the core and binary for debugging?

thanks
simon

I received both from hasso privately.

I have to say that gdb is not really at fault here. Thorough
investigation revealed:

#7 0x0807b766 in ?? ()

This function really doesn't exist. Well, it does, but it doesn't have a
visible symbol. Because of this, gdb can't analyze the function prologue
and thus assumes that there is nothing on the stack - of course this is
wrong. We could change gdb to assume that there is always a stack frame
and this way it could work better for this case.

Previous gdb versions mistakenly assumed a different calling function and
happily unwound the prologue of the wrong function. This led to better
backtraces, but possibly wrong ones.

cheers
simon

Also note that GCC-4 by default rolls up functions it thinks it
can inline on a file-by-file basis. So if function A calls function B
and GCC thinks it can inline function B in function A, whether or
not you've told it to, it will. You'll then get an error for function
B but the gdb backtrace will list the problem as being in function A.

I've noticed this when trying to debug kernels.  I personally think
    its a mistake, along with the idiotic default numeric optimizations
    that break bounds checks.

-Matt

yes, this is in so far annoying, because you can't properly "escape" from
the inlined part. also, debugging symbols sometimes don't seem to work
correctly.

i don't think that it yields a big benefit, but makes debugging harder.
so i would rather not have it. maybe we should research on how to switch
this auto-inlining off.

cheers
simon

Fixed in 1.12.2 and up.