gdb / dbx / pstack question - getting function argument addresses from stack

gdb / dbx / pstack question - getting function argument addresses from stack

[Pavel Chernikov]

Hi All,

On Solaris platform, when using dbx (or pstack) on a core file (w/o
access to symbol info) I get back the stack trace of function calls
with their argument addresses. On the other hand, when using gdb on
the same core file, the only thing shown is the function name,
followed by () - again, no symbols avail.

Example:
dbx: [1] strlen(0x0, 0x0, 0x5, 0x7efefeff, 0x81010100, 0xffbee178), at
0xff1332ec
gdb: #0 0xff1332ec in strlen () from /usr/lib/libc.so.1

Question 1: is it possible to achieve the same thing with gdb (ability
to see function argument addresses)? If not, is there another utility
that can be used?

We're planning to move to the Linux platform... I've been trying to
figure out a Linux equivalent for Solaris version of pstack to produce
stack traces for a core file, but so far I haven't been able to find
ANYTHING except for gdb. Linux version of pstack only works on a
running process. I compiled "lsstack", but that also only operated
only on a process (contrary to what several sources say).

Full stack trace for both dbx and gdb:

(/opt/SUNWspro/bin/../WS6U2
/bin/sparcv9/dbx) where
current thread: t@1
[1] strlen(0x0, 0x0, 0x5, 0x7efefeff, 0x81010100, 0xffbee178), at 0xff1332ec
[2] gethostbyname_r(0x0, 0x251d4, 0x251e8, 0x920, 0x251d4,
0xff31ef68), at 0xff2b61c8
[3] fm_ptd_pol_check_ldap(0x62678, 0x5fb50, 0x62740, 0xffbeee70, 0x0,
0xffbeee70), at 0xfd406ea0
[4] op_ptd_login_exist(0xfe7dd13c, 0x186e0, 0x0, 0x5fb50, 0x62740,
0xffbeee70), at 0xfd4054e8
[5] cm_custom(0xfe7dd13c, 0x22f58, 0x186e0, 0x0, 0x0, 0xffbef120), at 0xfe75285c
[6] cm_child(0x9, 0xfe000044, 0xfe7dd13c, 0xffbef534, 0x22f58,
0xfe000071), at 0xfe74f210
[7] main(0x1, 0xffbef734, 0xff1be5d8, 0xff11bc20, 0xff3b0000, 0x0), at
0xfe745210
=>[8] main(argc = 1, argv = 0xffbef734), line 33 in "cm.c"

(gdb) where
#0 0xff1332ec in strlen () from /usr/lib/libc.so.1
#1 0xff2b61d0 in gethostbyname_r () from /usr/lib/libnsl.so.1
#2 0xfd406ea8 in fm_ptd_pol_check_ldap () from
/global/opt/portal/6.2/pin4/lib/fm_ptd.so
#3 0xfd4054f0 in op_ptd_login_exist () from
/global/opt/portal/6.2/pin4/lib/fm_ptd.so
#4 0xfe752864 in cm_custom () from /global/opt/portal/6.2/pin4/lib/libcm_main.so
#5 0xfe74f218 in cm_child () from /global/opt/portal/6.2/pin4/lib/libcm_main.so
#6 0xfe745218 in main () from /global/opt/portal/6.2/pin4/lib/libcm_main.so
#7 0x10cb0 in main (argc=1, argv=0xffbef734) at
/pinbuild/cc_builds/6.2_SP4_idc_0912.1300/solaris/legacy_vob/continuus/All_Server~continuus/All_Server/cm:33

My other goal is to (manually, through code) extract a stack trace of
function calls with function argument addresses from a core dump. The
way to do it, it seems, is to get NT_PRSTATUS structure from the
core's NOTES section, and find the stack using ESP register contents.
But then... I am not sure what to do.

Question 2: How can I get a list of function calls with their
arguments off the stack?

Thank you in advance for any ideas / suggestions.
-Pavel

Re: gdb / dbx / pstack question - getting function argument addresses from stack

[Joel Brobecker]

> Example:
> dbx: [1] strlen(0x0, 0x0, 0x5, 0x7efefeff, 0x81010100, 0xffbee178), at
> 0xff1332ec
> gdb: #0 0xff1332ec in strlen () from /usr/lib/libc.so.1
> 
> Question 1: is it possible to achieve the same thing with gdb (ability
> to see function argument addresses)? If not, is there another utility
> that can be used?

There is no way that I know of, right now, to get the information
printed inside the argument section of the frame info. However,
what the dbx is doing, I believe, is simply printing the contents
of the %i0-%i5 registers. This trick only works on Sparc.

Based on the description of what you're trying to do, you should be able
to write a small script/program that starts the debugger with your core
file, extracts the backtrace, then selects one frame after the other and
issue a series of print commands. Your script/program would then
post-process the output and stuff the value of the registers where you
want to see them.

-- 
Joel

Re: gdb / dbx / pstack question - getting function argument addresses from stack

[Pavel Chernikov]

Hi Joel,

Thanks for the reply! It's starting to make sense... Would you mind
elaborating on "issue a series of print commands"? I'm not sure of
what exactly I need to print...

Thanks,
-Pavel

On Thu, Jun 26, 2008 at 10:26 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Example:
>> dbx: [1] strlen(0x0, 0x0, 0x5, 0x7efefeff, 0x81010100, 0xffbee178), at
>> 0xff1332ec
>> gdb: #0 0xff1332ec in strlen () from /usr/lib/libc.so.1
>>
>> Question 1: is it possible to achieve the same thing with gdb (ability
>> to see function argument addresses)? If not, is there another utility
>> that can be used?
>
> There is no way that I know of, right now, to get the information
> printed inside the argument section of the frame info. However,
> what the dbx is doing, I believe, is simply printing the contents
> of the %i0-%i5 registers. This trick only works on Sparc.
>
> Based on the description of what you're trying to do, you should be able
> to write a small script/program that starts the debugger with your core
> file, extracts the backtrace, then selects one frame after the other and
> issue a series of print commands. Your script/program would then
> post-process the output and stuff the value of the registers where you
> want to see them.
>
> --
> Joel
>

Re: gdb / dbx / pstack question - getting function argument addresses from stack

[Joel Brobecker]

> Thanks for the reply! It's starting to make sense... Would you mind
> elaborating on "issue a series of print commands"? I'm not sure of
> what exactly I need to print...

You want to print the value of the input registers. They should be
accessible through the $i0, $i1, ... convenience variables. In other
words:

    (gdb) print /x $i0
    $1 = 0xfeedface

(for instance). While going from frame to frame, just print the value
of all input register.  Your script can then parse the output, collect
the information you're looking for, and then produce the output you
want.

-- 
Joel

Re: gdb / dbx / pstack question - getting function argument addresses from stack

[Pavel Chernikov]

>    (gdb) print /x $i0
>    $1 = 0xfeedface

As you've mentioned previously, this only works on Solaris. Am I
totally out of luck on Linux?

pchernik@ptxubuntu:~/cor$ cat foo.c
#include <string.h>

void bar(char *p1, char *p2) {
       char *p3;
       strcpy(p3, "fail");
}

int main() {
       char *p1 = "test1";
       char *p2 = "test1";
       bar(p1, p2);
}
pchernik@ptxubuntu:~/cor$ gcc -o foo foo.c
pchernik@ptxubuntu:~/cor$ foo
Segmentation fault (core dumped)
pchernik@ptxubuntu:~/cor$ gdb foo core
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/tls/i686/cmov/libc.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `foo'.
Program terminated with signal 11, Segmentation fault.
#0  0x0804834d in bar ()
(gdb) where
#0  0x0804834d in bar ()
#1  0x0804838a in main ()
(gdb) print $i0
$1 = void
(gdb) q

Thanks,
-Pavel

Re: gdb / dbx / pstack question - getting function argument addresses from stack

[Michael Snyder]

On Thu, 2008-06-26 at 14:08 -0400, Pavel Chernikov wrote:
> >    (gdb) print /x $i0
> >    $1 = 0xfeedface
> 
> As you've mentioned previously, this only works on Solaris. Am I
> totally out of luck on Linux?

It only works on *sparc*.

You would be just as out of luck on i386-solaris, but
you could do the same trick on sparc-linux.

Intel is a very different architecture, you know: 
there is not such a simple way of guessing where 
all the function arguments are stored.

Re: gdb / dbx / pstack question - getting function argument addresses from stack

[Pavel Chernikov]

Right, understood - thanks for pointing that out to me. I should have
mentioned that the original platform was SPARC Solaris and the new
platform is I386 Linux.

With that said, am I absolutely-totally-100% out of luck with being
able to find function argument addresses? Or is there some way of
doing this?

Ideally, I'd like to write the following solution in C:
* List all function calls with corresponding function argument list
for each function

Thanks,
-Pavel


On Thu, Jun 26, 2008 at 2:47 PM, Michael Snyder <msnyder@specifix.com> wrote:
> On Thu, 2008-06-26 at 14:08 -0400, Pavel Chernikov wrote:
>> >    (gdb) print /x $i0
>> >    $1 = 0xfeedface
>>
>> As you've mentioned previously, this only works on Solaris. Am I
>> totally out of luck on Linux?
>
> It only works on *sparc*.
>
> You would be just as out of luck on i386-solaris, but
> you could do the same trick on sparc-linux.
>
> Intel is a very different architecture, you know:
> there is not such a simple way of guessing where
> all the function arguments are stored.
>
>
>
>

Re: gdb / dbx / pstack question - getting function argument addresses from stack

[Daniel Jacobowitz]

On Thu, Jun 26, 2008 at 02:56:45PM -0400, Pavel Chernikov wrote:
> Right, understood - thanks for pointing that out to me. I should have
> mentioned that the original platform was SPARC Solaris and the new
> platform is I386 Linux.
> 
> With that said, am I absolutely-totally-100% out of luck with being
> able to find function argument addresses? Or is there some way of
> doing this?
> 
> Ideally, I'd like to write the following solution in C:
> * List all function calls with corresponding function argument list
> for each function

Basically, you can not do this in any reliable way without debug info.
You might be able to approximate of it by studying the x86 ABI, since
GDB does expose the stack pointer at the time of call; in normal cases
(not always), arguments will be consecutive words starting at $esp in
the caller.

A more useful approach might be a GCC mode which generates reduced
debug info, including parameters but little else.  I don't remember if
that's what -g1 does.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb / dbx / pstack question - getting function argument addresses from stack

[Joel Brobecker]

> With that said, am I absolutely-totally-100% out of luck with being
> able to find function argument addresses? Or is there some way of
> doing this?

What I would suggest is that you take a look at the i386 ABI (the
document I have is named "SYSTEM V APPLICATION BINARY INTERFACE,
Intel386 Architecture Processor Supplement, Fourth Edition"), in
particular the section that explains how function calls are made.
You'll see where the arguments are.

That should give you an idea of some of the challenges that you'll have
to solve to provide something comparable on x86. I would say that this
is non-trivial if you want to make it work in the case of functions
that don't use the frame base pointer...

-- 
Joel

Re: gdb / dbx / pstack question - getting function argument addresses from stack

[Michael Snyder]

On Thu, 2008-06-26 at 14:56 -0400, Pavel Chernikov wrote:
> Right, understood - thanks for pointing that out to me. I should have
> mentioned that the original platform was SPARC Solaris and the new
> platform is I386 Linux.
> 
> With that said, am I absolutely-totally-100% out of luck with being
> able to find function argument addresses? Or is there some way of
> doing this?

The key constraint is "without debug info".

Under that constraint you are pretty much out of luck.


> Ideally, I'd like to write the following solution in C:
> * List all function calls with corresponding function argument list
> for each function

That's exactly what debug info is for.
With modern compiler abis and complex architectures
like Intel, it's nominally-close-to-impossible
to do that without debug info.

Re: gdb / dbx / pstack question - getting function argument addresses from stack

[Joel Brobecker]

> As you've mentioned previously, this only works on Solaris. Am I
> totally out of luck on Linux?

The Operating System is actually not the most important factor in
this case. The reason why this "works" on Sparc is because the Sparc
ABI says that the first few parameters should be passed through the
output/input registers. There can be up to 6 registers passed this
way.  So when dbx prints the "parameters" when there is no debugging
info, it is actually printing the contents of these registers.

You didn't say which CPU your Linux was running on, but I'll guess
it's x86. I don't know x86 all that well, but I remember that the
arguments are passed through the stack at an offset to the function
frame base. So the idea that works on Sparc doesn't work for x86,
and I don't see another simple scheme that would work on x86 either.

-- 
Joel

Re: gdb / dbx / pstack question - getting function argument addresses from stack

[Pavel Chernikov]

Right, I should have mentioned that the "old" platform is SPARC
Solaris and the "new" platform is I386 Linux.

Thanks for the info! I guess my only option is to check how x86
OpenSolaris is doing it (IF it is doing it)...

Thanks again,
-Pavel

On Thu, Jun 26, 2008 at 2:50 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> As you've mentioned previously, this only works on Solaris. Am I
>> totally out of luck on Linux?
>
> The Operating System is actually not the most important factor in
> this case. The reason why this "works" on Sparc is because the Sparc
> ABI says that the first few parameters should be passed through the
> output/input registers. There can be up to 6 registers passed this
> way.  So when dbx prints the "parameters" when there is no debugging
> info, it is actually printing the contents of these registers.
>
> You didn't say which CPU your Linux was running on, but I'll guess
> it's x86. I don't know x86 all that well, but I remember that the
> arguments are passed through the stack at an offset to the function
> frame base. So the idea that works on Sparc doesn't work for x86,
> and I don't see another simple scheme that would work on x86 either.
>
> --
> Joel
>

Re: gdb / dbx / pstack question - getting function argument addresses from stack

[Michael Snyder]

On Thu, 2008-06-26 at 14:50 -0400, Joel Brobecker wrote:
> > As you've mentioned previously, this only works on Solaris. Am I
> > totally out of luck on Linux?
> 
> The Operating System is actually not the most important factor in
> this case. The reason why this "works" on Sparc is because the Sparc
> ABI says that the first few parameters should be passed through the
> output/input registers. There can be up to 6 registers passed this
> way.  So when dbx prints the "parameters" when there is no debugging
> info, it is actually printing the contents of these registers.
> 
> You didn't say which CPU your Linux was running on, but I'll guess
> it's x86. I don't know x86 all that well, but I remember that the
> arguments are passed through the stack at an offset to the function
> frame base. So the idea that works on Sparc doesn't work for x86,
> and I don't see another simple scheme that would work on x86 either.

Worse, they're sometimes passed on the stack, and 
sometimes in registers, and sometimes both.  Only
the compiler knows for sure (in the absence of 
debug info).