> 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.htmlStore 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.
