Re: [patch] Stop runaway unwinding on stripped executables

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Fri, 16 Mar 2012 14:50:56 +0100, Mark Kettenis wrote:
> People need to learn that if they are debugging stripped stuff they're
> going to end up with runaway backtraces every now and then.

There is no need to teach that them.


> In this particular example you're just getting lucky that you're hitting
> __libc_start_main().

In other cases they end up in 'start_thread' and its caller 'clone' which
correctly undefines $pc and stops the unwinding.


> That probably wouldn't happen if you're somewhat deeper into the call stack
> of the (stripped) program that you're trying to debug.

I can only imagine code which does not use -fasynchronous-unwind-tables.
But normal distros use it, therefore they can numerically unwind anything as
well as with full debug info.

Sure the correct solution is to terminate unwinding in '_start' (like it is
terminated in 'clone'), thanks for refreshing this idea.  Still GDB could have
this workaround for older code.


> But the implementation and actually the whole idea is *very*
> glibc-specific.

Yes, I was thinking about it, but glibc is neither arch nor OS specific.
Where to put it into GDB better?


Thanks,
Jan