How can I use the call command when analyzing a core

["Garrod, David" <dgarrod@enterasys.com>]

I have a core file for a very complex program that I'm trying to analyze using gdb. The program has lots of internal routines that if I were able to call them would print out all sorts of interesting information about internal data structures. These data structures are complex and more importantly complexly linked. Consequently it is not practicable to write gdb macros etc.

Yes I know the program should have been designed to call these dump routines before aborting. But in this case that would not have been easy because I'm analyzing a SEGV.

If I was doing live debugging I could of course do a:

call the_routine_that_dumps_all_the_interesting_structures()

but if I try that from debugging a core file I get:

(gdb) call a()
You can't do that without a process to debug.

Now of course I realize that if I was doing cross debugging to another architecture this wouldn't be feasible. But in my case I'm debugging a core file that was produced on exactly the same architecture as the one that cored. So I can't see why this is not possible in theory. I've searched the web and surprisingly I can't seem to find references to other people wanting to do this.

I've been browsing the gdb sources trying to get a feel as to how hard it would be to implement this and came to the conclusion that even if it was possible learning the internals of gdb is a massive task (even though I've dabbled in them a little before).

So in summary my questions from this post are:

1) Is there any chance at all of working out how to change gdb to do "call" when analyzing a core on the same
   architecture as the core was taken on?
2) If so how hard is it to do and could I get some pointers on where to start.

Thanks,

Dave Garrod
Enterasys Networks