topic Re: How to view function parameters in core file in Operating System - Linux

How to view function parameters in core file

Jose M. del Rio — Thu, 24 Aug 2006 05:38:48 GMT

I'm troubleshooting a 3rd party SW (ESRI ArcSDE) running on top of Oracle - HP-UX.
From time to time (several times a day) one of ArcSDE's processes (called 'gsrvr') core dumps on signal 10.
I have downloaded and installed WDB (an used it for the very first time to examine the core file).
The faulting stack trace is:

#0 0xc01ccb5c in memcpy+0x144 () from /usr/lib/libc.2
#1 0xc6d0b680 in kpcxk2u+0x2cc () from /ora8/lib/libclntsh.sl.8.0
#2 0xc6d38960 in ttccDefineConvert+0x114 () from /ora8/lib/libclntsh.sl.8.0
#3 0xc6d38d9c in ttccfpg+0x370 () from /ora8/lib/libclntsh.sl.8.0
#4 0xc6d181d8 in ttcfour+0x130 () from /ora8/lib/libclntsh.sl.8.0
#5 0xc6d1494c in ttcdrv+0x119c () from /ora8/lib/libclntsh.sl.8.0
#6 0xc6baf2ac in nioqwa+0x4c () from /ora8/lib/libclntsh.sl.8.0
#7 0xc6a01ecc in upirtrc+0x200 () from /ora8/lib/libclntsh.sl.8.0
#8 0xc6a51ca8 in kpurcsc+0x70 () from /ora8/lib/libclntsh.sl.8.0
#9 0xc6a2381c in kpuexecv8+0xa90 () from /ora8/lib/libclntsh.sl.8.0
#10 0xc6a25c74 in kpuexec+0xe00 () from /ora8/lib/libclntsh.sl.8.0
#11 0xc69e5a9c in OCIStmtExecute+0x30 () from /ora8/lib/libclntsh.sl.8.0
#12 0xc7255cbc in db_sda_execute_stmt+0x14c () from /arcsde/sdeexe90/lib/libsdeora8isrvr90.sl
#13 0xc7256078 in db_sda_execute_and_fetch+0x14 () from /arcsde/sdeexe90/lib/libsdeora8isrvr90.sl
#14 0xc71ac864 in db_execute_and_fetch_data+0x6c () from /arcsde/sdeexe90/lib/libsdeora8isrvr90.sl
#15 0xc72bcac0 in db_array_fetch_spix_recs+0x74 () from /arcsde/sdeexe90/lib/libsdeora8isrvr90.sl
#16 0xc72bc1f4 in db_get_spix_fidlist+0xf0 () from /arcsde/sdeexe90/lib/libsdeora8isrvr90.sl
#17 0xc72996fc in db_fetch_search_row+0x58 () from /arcsde/sdeexe90/lib/libsdeora8isrvr90.sl
#18 0xc72b3544 in S_fetch_search_row_by_storage_type+0x58 () from /arcsde/sdeexe90/lib/libsdeora8isrvr90.sl
#19 0xc72b3124 in DB_stream_fetch_row+0x88 () from /arcsde/sdeexe90/lib/libsdeora8isrvr90.sl
#20 0x630b4 in + 0x134 ()
#21 0x62e7c in ()
#22 0x1bff8 in + 0x78 ()
#23 0x523fc in + 0x278c ()
#24 0x4f8a8 in + 0x20 ()

My hypothesis is: gsrvr is passing to Oracle a wrong memory address as one of the parameters to Oracle's function OCIStmtExecute() (frame #11). So, when Oracle tries to memcpy (frame #0) to this address, it SIGBUSes.

By using gdb, I would like to:
1) obtain the args (memory addresses) passed to OCIStmtExecute()
2) dump the contents of these addresses and compare them with the OCI structures parameters, as they should be (Oracle doc).

I know:
2) I must use the 'x' command to dump a memory address
1) as I have no symbols' information (neither Oracle's nor ArcSDE's), gdb cannot possibly know the types and sizes of the parameters passed to the OCIStmtExecute() at frame #11
but, anyway, I would like to dig into it.

So the questions would be:
a) is it possible to know what the args passed to frame #11 were?
b) and to frame #0 (memcpy)?
In both cases:
c) is there any way to determine whether those addresses indeed belonged (were malloc'ed by) the running process.

The only related thing I've found is at "Debugging with GDB" manual:
"When GDB has no debug information; it does not know where the arguments are
located or even the type of the arguments. GDB cannot infer this in an optimized,
non-debug executable.
However, for integer arguments you can find the first few parameters for the top-of-
stack frame by looking at the registers. On PA-RISC systems, the first parameter will
be in $r26, the second in $r25 and so on."
Thanks.

Re: How to view function parameters in core file

OldSchool — Thu, 24 Aug 2006 08:59:04 GMT

Do you have support/maintenance for ArcSDE? If so, I'd contact them. Are you current on ArcSDE patches?

http://support.esri.com/index.cfm?fa=downloads.patchesServicePacks.listPatches&PID=19

Re: How to view function parameters in core file

Jose M. del Rio — Fri, 25 Aug 2006 05:11:31 GMT

Hi SA,
Yes, we have support.
Until a couple of weeks we were up to date with version/patches.
ESRI has just released a new version that we are testing at preproduction.
Thanks for your input.

Re: How to view function parameters in core file

Dennis Handly — Sat, 26 Aug 2006 01:19:51 GMT

To find why memcpy is aborting you should look at the current instructions and the registers:
(gdb) disas $pc-4*4 $pc+4
(gdb) info reg

And from the instruction at $pc figure out whether load or store and which of $r26 .. $r24 are being used and their values.
Note memcpy would be special (hand optimized) in that its parms would still be in registers.

As to frame #11, you will have to look at the machine code or assume the parms are stored in their default locatations.

>a) is it possible to know what the args passed to frame #11 were?

Several ways. You can use "frame 12" and look at the machine code.
Or you can assume they have been stored. So use:
(gdb) frame 12
(gdb) x /8x $sp-64

Assuming the arguments are not more than 4 bytes in size or pointers, the last is the first arg.
Assuming the first arg is a pointer you could use:
(gdb) x /8x *(void**)($sp-32-4*1)
(and so on, by replacing the "1" above.)

>b) and to frame #0 (memcpy)?

Here you print out the registers:
(gdb) p /x $r26
(gdb) p /x $r25
(gdb) p $r24

>c) is there any way to determine whether those addresses indeed belonged the running process.

It's pretty simple, if gdb can display them, they belong.

Re: How to view function parameters in core file

Jose M. del Rio — Mon, 28 Aug 2006 06:35:49 GMT

Impressive!, Dennis

Because I'm a newbie to disassembler and PA-RISC instruction set I still would need some help.

With respect to memcpy(), its prototype is:
void *memcpy(void *s1, const void *s2, size_t n);
Return value: s1.

(gdb) disas $pc-4*4 $pc+4
Dump of assembler code from 0xc01ccb4c to 0xc01ccb60:
0xc01ccb4c : ret
0xc01ccb50 : stdby,e %r21,0(%r26)
0xc01ccb54 : ldb,ma 1(%r25),%ret1
0xc01ccb58 : addib,<> -1,%r24,0xc01ccb54
0xc01ccb5c : stb,ma %ret1,1(%r26)
End of assembler dump.

(gdb) p /x $pc
$14 = 0xc01ccb5c

From my University days, I think $pc was pointing to the next instruction to execute.
So in our case:
1) which assembly instruction is faulty? (addib?)
2) and what does it mean?

(gdb) info reg
flags: 32000041
r1: b9ea800 rp/r2: c690b683
r3: 7800dd64 r4: 1e78
r5: 44c0fad8 r6: 4007ea84
r7: 18 r8: 6
r9: 40080354 r10: 6
r11: 44bfe72c r12: 7800dd94
r13: 1e78 r14: 0
r15: c690b404 r16: 0
r17: 40059338 r18: 400593e0
r19: 77fd4794 r20: 44bfe708
r21: c01cca18 r22: 18
arg3/r23: c656d328 arg2/r24: 5
arg1/r25: 44c0fad9 arg0/r26: 1e79
dp/gp/r27: 40004280 ret0/r28: 1e79
ret1/ap/r29: c5 sp/r30: 7800e180
mrp/r31: 5 sar/cr11: 20
pcoqh: c01ccb5c pcsqh: b9ea800
pcoqt: c01ccb54 pcsqt: b9ea800
eiem/cr15: ffffffffffffffff iir/cr19: f5d1222
isr/cr20: d707800 ior/cr21: 1e79
ipsw/cr22: c001f goto: 96d84
sr4: d707800 sr0: b9ea800
sr1: 0 sr2: 0
sr3: 0 sr5: 471b800
sr6: b9ea800 sr7: b9ea800
rctr/cr0: 0 pidr1/cr8: 2815368
pidr2/cr9: 2815378 ccr/cr10: 0
pidr3/cr12: 0 pidr4/cr13: 100000000
cr24: 2815130 cr25: 0
cr26: c75e60 mpsfu_high: 40007280
mpsfu_low: c67078 mpsfu_ovflo: 0
pad: 847b889002815000 fpsr: c3fe03e
fpe1: 0 fpe2: 0
fpe3: 0 fpe4: 0
fpe5: 0 fpe6: 0
fpe7: 0

3) Shall I assume:
- %r26 is string 's1' = dst string (0x1e79)
- %r25 is string 's2' = src string (0x44c0fad9)
- %r24 is num bytes 'n' (5) ?

4) And that it is trying (unsuccessfully) to copy '08 23 5a 5c 15' to dst?
(gdb) x /1g 0x1e79
0x1e79: 0xe5c7b3eca3287111
(gdb) x /1g 0x44c0fad9
0x44c0fad9: 0x08235a5c15000000

gdb can print 0x44c0fad9, so it belongs to the process's memory space.

5) Additionally, is this reasoning correct?: the memory address 0x44c0fad9 belongs to a data memory region of the process:

(gdb) info target
Symbols from "/arcsde/sdeexe90/bin/gsrvr.shared".
Local core dump file:
`/arcsde/sdeexe90/core.signal10', file type hpux-core.
0x40001000 - 0x45840000 is .data

Regarding frame#11 parameters:

6) >>>> You can use "frame 12" and look at the machine code.
I have tried with frame 1 to infere the parameters to frame 0 but it is too hard for me.
I still have to study a lot :-)

7) >>>> Assuming they have been stored:

OCIStmtExecute() prototype is:

sword OCIStmtExecute ( OCISvcCtx *svchp,
OCIStmt *stmtp,
OCIError *errhp,
ub4 iters,
ub4 rowoff,
CONST OCISnapshot *snap_in,
OCISnapshot *snap_out,
ub4 mode );

that is:
(ptr, ptr, ptr, int, int, ptr, ptr, int)
By calling sizeof(...) I deduce both 'ptr' and 'int' are 4 bytes long.
So, in this case, their values were:

(gdb) frame 12
#12 0xda755cbc in db_sda_execute_stmt+0x14c ()
from /arcsde/sdeexe90/lib/libsdeora8isrvr90.sl
(gdb) x /xw $sp-32-4*1
0x7800ce1c: 0x4003b380
(gdb) x /xw $sp-32-4*2
0x7800ce18: 0x0056ccd4
(gdb) x /xw $sp-32-4*3
0x7800ce14: 0x7800cca4
(gdb) x /xw $sp-32-4*4
0x7800ce10: 0x40008ab4
(gdb) x /xw $sp-32-4*5
0x7800ce0c: 0x00000000
(gdb) x /xw $sp-32-4*6
0x7800ce08: 0x00000000
(gdb) x /xw $sp-32-4*7
0x7800ce04: 0x00000000
(gdb) x /xw $sp-32-4*8
0x7800ce00: 0x00000000

Is that right?
If so, parameter 4 seems rather incorrect: should be a number and looks like a memory address.
Maybe this is the original problem ???

Re: How to view function parameters in core file

Jose M. del Rio — Mon, 28 Aug 2006 07:12:59 GMT

I'm a bit confused.
I have developed the following program:

int foo2(char* s)
{
char* aux;

printf("dentro\n");
aux = 0x12345678;
memcpy(aux, s, 3); // <--- here
return 9;
}
int main(argc, argv)
int argc;
char *argv[];
{
char* s;
s = (char*) malloc(3);
if(!s) {printf("fallo malloc\n"); return 1;}
printf("0x%x\n", s);
memcpy(s, "ABC", 3);
foo2(s);
free(s);
return 0;
}

in order to produce a core and debug it with gdb to test the memcpy() arguments at $r26, $r25, $r24.

ORACLE8_desar>./cdemo81
0x40004bb8
dentro
Memory fault(coredump)
ORACLE8_desar>gdb cdemo81 core
...
(gdb) bt
#0 0xc01cd59c in memcpy+0x144 () from /usr/lib/libc.2
#1 0x6cb8 in foo2+0x74 ()
#2 0x6e10 in main+0xfc ()
(gdb) p /x $r26
$1 = 0x12345678
(gdb) p /x $r25
$2 = 0x40004bb9
(gdb) p /x $r24
$3 = 0x2

Surprise!
1) $r25 contains 0x40004bb9 but the src string is 0x40004bb8
2) $r24 contains 2 but the number of bytes to copy was 3.
Am I misinterpreting something?

Re: How to view function parameters in core file

Jose M. del Rio — Mon, 28 Aug 2006 08:10:47 GMT

Back to the original issue (gsrvr calling OCIStmtExecute()), even more insteresting than parameter 4 is parameter 2: it seems it is not included in the process's memory regions.

(gdb) frame 12
#12 0xda755cbc in db_sda_execute_stmt+0x14c ()
from /arcsde/sdeexe90/lib/libsdeora8isrvr90.sl
(gdb) x /xw $sp-32-4*2
0x7800ce18: 0x0056ccd4

(gdb) x /xw 0x0056ccd4
0x56ccd4: Cannot access memory at address 0x56ccd4

Re: How to view function parameters in core file

Jose M. del Rio — Mon, 28 Aug 2006 11:04:20 GMT

More doubts.
I have developed the following program:
int main(argc, argv)
int argc;
char *argv[];
{
OCIStmtExecute(1, 2, 3, 4, 5, 6, 7, 8);
return 1;
}
to get a core and check the validity of the rule:
x /xw $sp-32-4*N
which doesn't seem to work in this case?:
(gdb) x /xw $sp-32-4*1
0x77ff094c: 0x00000000
(gdb) x /xw $sp-32-4*2
0x77ff0948: 0x00000000
(gdb) x /xw $sp-32-4*3
0x77ff0944: 0x00000000

Is there a different rule for calls to functions in another file? (e.g. shared library).
Am I doing st wrong?

Re: How to view function parameters in core file

Sandman! — Mon, 28 Aug 2006 12:47:21 GMT

>I'm a bit confused.
>I have developed the following program:

>int foo2(char* s)
>{
>char* aux;

>printf("dentro\n");
>aux = 0x12345678;
>memcpy(aux, s, 3); // <--- here
>return 9;
>}
>int main(argc, argv)
>int argc;
>char *argv[];
>{
>char* s;
>s = (char*) malloc(3);
>if(!s) {printf("fallo malloc\n"); return 1;}
>printf("0x%x\n", s);
>memcpy(s, "ABC", 3);
>foo2(s);
>free(s);
>return 0;
>}

>in order to produce a core and debug it with gdb to test the memcpy()
>arguments at $r26, $r25, $r24.

A suggestion Jose; variable declaration and assignment is incorrect i.e. aux is a pointer to char but you have assigned it to an array. imho the proper way to do this would be:

change...
>aux = 0x12345678;
to...
char t[] = "0x12345678";
char *aux = t;

hope it helps!

Re: How to view function parameters in core file

Jose M. del Rio — Mon, 28 Aug 2006 13:34:04 GMT

Hi Sandman,
Thanks for reading the long post (that deserves some prize ;-) and even answering.
I don't get your point.
The syntax you suggest assigns the string "0x12345678" to aux.
This is not my intention.
I intend to assign the memory address 0x12345678 to aux and write some data to it so that a sigbus is raised (and a core dumped). And it is, actually.

Re: How to view function parameters in core file

Sandman! — Mon, 28 Aug 2006 13:58:44 GMT

Jose,

Compiling your code and executing it gives a core dump and when i do a file on it, it tells me that the executable image actually received a SIGSEGV signal not a SIGBUS?

# file core

Re: How to view function parameters in core file

Dennis Handly — Mon, 28 Aug 2006 14:31:32 GMT

> 1) which assembly instruction is faulty? (addib?)

No, PC points at the faulting instruction. In this case STB.

>2) and what does it mean?

http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,959,00.html
Store a byte from RET1 0xc5 at R26 0x1e79 and increment after.

In this case R26 is bad in that 0x1e79 is a read only constant.

3) Shall I assume:
- %r26 is string 's1' = dst string (0x1e79)
- %r25 is string 's2' = src string (0x44c0fad9)
- %r24 is num bytes 'n' (5)?

Yes, except it may have already incremented R25 since the char to store is 0xc5.

>4) And that it is trying (unsuccessfully) to copy '08 23 5a 5c 15' to dst?

Or 1 byte sooner.

>gdb can print 0x44c0fad9, so it belongs to the process's memory space.

Yes, while gdb can print 0x1e79, the hardware will not let the application write to it. (Though gdb can.)

>5) the memory address 0x44c0fad9 belongs to a data memory region of the process:

Yes.

>6) I have tried with frame 1 to infere the parameters to frame 0 but it is too hard for me.

You can't. I noted that:
Note memcpy would be special

Only by disassembling frame 1 could you attempt to figure out the original parms.

>7) >>>> Assuming they have been stored:

>If so, parameter 4 seems rather incorrect:

Then it hasn't been stored. If you disassemble frame #11, you'll probably see no stores for R23 at the beginning.

>int main(argc, argv)

(This is a K&R style definition, only use strict ANSI C or C++ style.)

>s = (char*)malloc(3);

(If you really want to put a string there, you need to have 3+1 for the NULL char.)

>1) $r25 contains 0x40004bb9 but the src string is 0x40004bb8
>2) $r24 contains 2 but the number of bytes to copy was 3.
>Am I misinterpreting something?

You are looking at the CURRENT register contents. It has already done 2/3 of the work to copy 1 byte.
0xc01ccb54: ldb,ma 1(%r25),%ret1
0xc01ccb58: addib,<> -1,%r24,0xc01ccb54
0xc01ccb5c: stb,ma %ret1,1(%r26) <<<

>parameter 2: it seems it is not included in the process's memory regions.

If R25 hasn't been stored, stored args area will be garbage.

>Is there a different rule for calls to functions in another file?

Only that the parms have to be stored, not optimized away.

>Sandman! variable declaration and assignment is incorrect

This is perfectly correct if Jose wants it to abort. You need to take away his 3 points. :-)

If you want to find out where the illegal address 1e79 comes from, you could look at the parms to frames 10 to 1.

Or this address could come from a field in one of the structs from one of the pointers.

Re: How to view function parameters in core file

Sandman! — Mon, 28 Aug 2006 15:13:50 GMT

>Dennis
Even with K&R C the syntax of pointer declaration is incorrect i.e. char* s / char* aux should be char *s / char *aux. Hmmm...you need to take away Dennis' 10 points :-)

Re: How to view function parameters in core file

Dennis Handly — Mon, 28 Aug 2006 18:06:06 GMT

>Even with K&R C the syntax of pointer

My K&R comment had nothing to do with char *s, or char *aux, why are you connecting it? Using K&R is not just a stylistic war.

>is incorrect i.e. char* s / char* aux should be char *s / char *aux.

I'm confused. I see nothing different other than the spacing (and I had a hard time even seeing it) and I prefer the latter style.

The only thing wrong with Jose's case was that he should have had:
aux = (char*)0x12345678;

Re: How to view function parameters in core file

Jose M. del Rio — Wed, 30 Aug 2006 09:37:26 GMT

Hi Sandman,
>>>> the executable image actually received a SIGSEGV signal not a SIGBUS
Yes, you are completely right.
Sorry.

Dennis:
>>>> In this case R26 is bad in that 0x1e79 is a read only constant.
How do you know it?

>>>> This is a K&R style definition, only use strict ANSI C or C++ style
Yes, you are right. It's a code example I took from Oracle doc (cdemo81.c).

>>>> If you really want to put a string there, you need to have 3+1 for the NULL char
Yes, I know, thanks. I've been programming in C/C++ for several years ;-)

With respecto to code:
int main(argc, argv)
int argc;
char *argv[];
{
OCIStmtExecute(1, 2, 3, 4, 5, 6, 7, 8);
return 1;
}

following your indications, Dennis, I have disassembled the previous frame in order to see how the arguments are being stored.
4 of them are kept in registers while the others are stored at $sp-...:

0x6f2c

: ldi 1,%r26
0x6f30

: ldi 2,%r25
0x6f34

: ldi 3,%r24
0x6f38

: ldi 4,%r23
0x6f3c

: ldi 5,%r31
0x6f40

: stw %r31,-0x34(%sp)
0x6f44

: ldi 6,%r20
0x6f48

: stw %r20,-0x38(%sp)
0x6f4c

: ldi 7,%r21
0x6f50

: stw %r21,-0x3c(%sp)
0x6f54

: ldi 8,%r22
0x6f58

: stw %r22,-0x40(%sp)

(gdb) x /xw $sp-0x34
0x77ff093c: 0x00000005
(gdb) x /xw $sp-0x38
0x77ff0938: 0x00000006
(gdb) x /xw $sp-0x3c
0x77ff0934: 0x00000007
(gdb) x /xw $sp-0x40
0x77ff0930: 0x00000008

Is there some convention to decide which arguments will be stored in registers and which ones in the stack?
Or is it data-dependant / compiler-dependant...?

P.S.:
Very useful the "PA-RISC 2.0 Architecture" manual. I'm reading it in order to better understand disassembling.

Re: How to view function parameters in core file

Dennis Handly — Wed, 30 Aug 2006 20:21:02 GMT

>>>> In this case R26 is bad in that 0x1e79 is a read only constant.

>How do you know it?

Typically, the first quadrant is readonly text and code. The second is globals, statics, the heap, stack and privately mapped files. The third and fourth are shared libs, memory or mapped files. So looking at the first nibble: 0-3, 4-7, 8-b, c-f

Of course linking with -N can combine 0-7. And various chatr options can combine 8-f, etc.

>Is there some convention to decide which arguments will be stored in registers and which ones in the stack?

You need to look at the Procedure Calling Conventions manual.

http://devresource.hp.com/drc/STK/archivedocs.jsp
Run-time architecture
http://devresource.hp.com/drc/STK/docs/archive/rad_10_20.pdf

This has some pretty pictures answering your first question.

Basically for PA32, the first 4 parms are in registers. (It depends on size, type, alignment, etc.) Whether they are stored depends on the optimization in the callee.

Re: How to view function parameters in core file

Jose M. del Rio — Thu, 31 Aug 2006 14:24:37 GMT

Thanks again, Dennis.
I've been reading both manuals:
HP Assembler Reference Manual
The 32-bit PA-RISC Run-time Architecture Document
Very instructive.

You are right: the offending pointer (0x00001e79) seems to belong to a (read-only) subspace:
(gdb) info target
...
0x00001000 - 0x0001339d is $SHLIB_INFO$

As you suggested, I've started backtracking the offending pointer from frame 0, 1...
till I have realized something shocking:
at every frame #N level, the value 0x1e79 shows up in 3 registers:
arg1/r25: 4568fb79 arg0/r26: 1e79
dp/gp/r27: 40004280 ret0/r28: 1e79
isr/cr20: 5dab400 ior/cr21: 1e79
Isn't this strange?

Specially if we consider, for example, that these registers should be:
gr26: argc
gr25: argv
gr24: envp
gr26 is obviously wrong as 'argc' and I've tried to dereference r25, r24... but I've found nothing meaningful.
Can you think of any explanation?
Do you think the core file can be some way corrupted?
Anyway, I must say every core file that is generated as a result of a sigbus being raised by this program looks the same.
On the other hand, if I attach to a living process with gdb and dumpcore on demand, the core file looks more normal, in that it contains syntactically possible values, but not semantically:
arg3/r23: 21 arg2/r24: 77fdb200
arg1/r25: 8 arg0/r26: 93
dp/gp/r27: 40004280 ret0/r28: 8

Â¿argc=93?

By using gdb, chatr... I see the executable file is SOM sharable executable.
I don't know if this makes any difference with a "normal" executable file where gr26, gr25... work as expected.
This executable (gsrvr) is never launched directly but forked from its parent (giomgr).

By using tusc I can see it is forked this way:
15:16:52 [/arcsde/sdee][2213]{2650157} <-0.000000> execve("/arcsde/sdeexe90/bin/gsrvr", 0x400afaa8,

0x40082e80) [entry]
argv[0] @ 0x7f6f37c0: "/arcsde/sdeexe90/bin/gsrvr"
argv[1] @ 0x7f6f2440: "esri_sde"
argv[2] @ 0x7f6f22c0: "desar"
argv[3] @ 0x7f6f1e78: "null=database"
argv[4] @ 0x7f6f0a60: "sde"
argv[5] @ 0x7f6f26f0: "NO_shared_memory_chanl_io"
argv[6] @ 0x7f6f3d60: "1089"
argv[7] @ 0x400601f0: "/tmp/sde_client_to_server_FIFO_esri_sde_1"
argv[8] @ 0x4005fdf0: "/tmp/sde_server_to_client_FIFO_esri_sde_1"

Re: How to view function parameters in core file

Dennis Handly — Sun, 30 Oct 2011 01:45:02 GMT

>at every frame #N level, the value 0x1e79 shows up in 3 registers:
arg0/r26: 1e79 ret0/r28: 1e79 ior/cr21: 1e79

There is only one copy of these caller save registers, so the debugger can only display the top level's copy. The IOR register is the data address in the faulting instruction.
If R28 contains this text address, it could come from the return value of a function.

My suggestion was for you to look at the stored parm area for each frame.

>Specially if we consider, for example, that these registers should be:
gr26: argc gr25: argv gr24: envp

I'm not sure what point you are making. R26 contains argc ONLY at the start of main.

>where gr26, gr25... work as expected.

These work the way I and the hardware expects, perhaps not how you expect them.

Re: How to view function parameters in core file

Jose M. del Rio — Fri, 01 Sep 2006 05:22:41 GMT

>>>> R26 contains argc ONLY at the start of main.

According to my first post:
>> #0 0xc01ccb5c in memcpy+0x144 () from /usr/lib/libc.2
>> ...
>> #24 0x4f8a8 in + 0x20 ()

I supposed the last frame should always be main().
That's why I thought r26 should be argc.
But I see now this is not necessarily true.

>>>> >where gr26, gr25... work as expected.
>>>> These work the way I and the hardware expect, perhaps not how you expect them.
I think this can be more about the same (frame 24 != main())

>>>> There is only one copy of these caller save registers, so the debugger can only display the top level's copy.
Yet other registers do vary with every stack frame.
From "Debugging with GDB":
"Normally, register values are relative to the selected stack frame (see Section 6.5 [Select-
ing a frame], page 53). This means that you get the value that the register would contain
if all stack frames farther in were exited and their saved registers restored. In order to see
the true contents of hardware registers, you must select the innermost frame (with `frame
0').
However, GDB must deduce where registers are saved, from the machine code generated
by your compiler. If some registers are not saved, or if GDB is unable to locate the saved
registers, the selected stack frame makes no di erence."

Is there a clear boundary to decide which registers are frame-relative and which ones aren't?

Re: How to view function parameters in core file

Dennis Handly — Fri, 01 Sep 2006 20:16:25 GMT

>Is there a clear boundary to decide which registers are frame-relative and which ones aren't?

If it is more than 4, it is stored by the caller. In this case you can manually look at the args using the $sp-32-4*N formula. If less, it depends on the optimizer.

In regards to which registers are valid for other than the top frame, only the callee save registers are available to be restored. R3-R19, R30. See the Runtime Architecture manuals I listed above.