Re: [patch] Stop runaway unwinding on stripped executables

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Fri, 16 Mar 2012 15:45:57 +0100
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> 
> On Fri, 16 Mar 2012 14:50:56 +0100, Mark Kettenis wrote:
> > 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.

I was more thinking about the unwinder failing somewhere halfway.

> > 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.

It's not obvious to me that -fasynchronous-unwind-tables is the
default everywhere and on all architectures.  But if it is, than yes,
you have a much better chance of hitting __libc_start_main in your
backtrace.

> Sure the correct solution is to terminate unwinding in '_start'
> (like it is terminated in 'clone'), thanks for refreshing this idea.

Heh, that *is* clever!

> Still GDB could have this workaround for older code.

Not sure about that.  It means more code that has to be maintained.
But then I'm not bothered by these long backtraces since they make it
immediately obvious things went off the rails for me.

> > 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?

We have glibc-tdep.c, so sticking it in there, with an appropriate
gdbarch hook seems a logical place to me.