This is the mail archive of the archer@sourceware.org mailing list for the Archer 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: Stack trace from core file without executable


On Sat, Oct 18, 2008 at 2:57 PM, Ray Ruvinskiy <rruvinsk@sybase.com> wrote:

> frysk's fstack had a feature that I found quite useful: the ability to
> extract (fairly accurate) stack traces from core files without needing the
> executable that generated them.

On which platform? And what is contained in the frysk stack trace?

AFAIU, it couldn't contain function names, as these aren't normally
saved in the 'core' at all.

Assuming frysk stack trace looks like a chain of program counters,
what do you use it for? You still need the original executable to
tell you what these addresses are (at which point you could just
analyze the core with the executable in gdb, and get complete
info).

> gdb, on the other hand, does not appear to
> be able to do this very well. (Running a simple executable that does nothing
> but call abort() and then attempting to get the stack trace from the
> resulting core file using fstack and gdb demonstrates this fairly well.)
>
> I was wondering what accounts for fstack's ability (or gdb's lack of
> ability) to do this, and how feasible it would be to migrate this
> functionality to archer or gdb.

In general, on x86_64 and ia64, for code compiled with any level of
optimization (and without -fno-omit-frame-pointer) 'core' does not
have enough info to obtain a stack trace -- you need unwind
descriptors which are present in the executable.

But on x86, SPARC and PPC, gdb probably could do much better.
Still, I don't understand what you would do with that info.

Thanks,
-- 
Paul Pluzhnikov


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