This is the mail archive of the mailing list for the GDB 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: [patch] Stop runaway unwinding on stripped executables

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?


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