When a stripped executable crashes, making a core dump, how can
this core dump be used to find out in which routine the crash happened.
I did the following test:
1 made a program with a bug in it. (ttt.c)
2 compiled it with the -g option
3 ran it, so it crasshed
4 ran dbx with the executable and core dump. dbx told me nicely
where it crashed. (in which source code routine it crashed)
5 copied the executable to ttt.bak
6 stripped ttt
7 ran ttt so it crashed making a new core dump
8 ran dbx, which only gave information in hexadecimal style
9 copied ttt.bak back to ttt
10 ran dbx again with this core dump and the unstripped ttt execubable
But dbx didn't give me source code information. (At least not the
the correct line where the program crasshed)
------end of test ---
So my conclusion: you cannot just use the core dump of a stripped
version of a program in combination with the unstripped version of
the same program to get dbx to give you source code information on
the crash.
Question:
Is there another way in which you can get this info?
ANSWER
I created two executables:
cc -g -o a.nonstripped ttt.c
and
cc -g -s -o a.stripped ttt.c
# cat ttt.c
main()
int i;
i = 5;
abort();
Example of core dump situation with nonstripped
executable.
# cp a.nonstripped a.out
# ./a.out
IOT/Abort trap(coredump)
# dbx a.out
dbx Version 3.1
Type 'help' for help.
reading symbolic information ...
.using memory image in core.
abort process in raise at 0xd00c6bc0
0xd00c6bc0 (raise+0x24) 80410014 l r2,0x14(r1)
(dbx) where
raise(0x0) at 0xd00c6bc0
abort(0x0) at 0xd00c6ad0
main(), line 5 in "ttt.c"
(dbx) quit
# del a.out core
a.out core
del: Remove these files? y
yes
Example of core dump situation with stripped
executable.
# cp a.stripped a.out
# ./a.out
IOT/Abort trap(coredump)
# dbx a.out
dbx Version 3.1
Type 'help' for help.
reading symbolic information ...warning: no source compiled with -g
.using memory image in core.
abort process in raise at 0xd00c6bc0
0xd00c6bc0 (raise+0x24) 80410014 l r2,0x14(r1)
(dbx) where
raise(0x0) at 0xd00c6bc0
abort(0x0) at 0xd00c6ad0
main() at 0x1000028c
(dbx) quit
# del a.out
del: Remove a.out? y
yes
Example of core dump situation where core produced with stripped
executable. Then, core viewed with nonstripped executable.
# cp a.nonstripped a.out
# touch core
# dbx a.out
dbx Version 3.1
Type 'help' for help.
reading symbolic information ...
.using memory image in core.
abort process in raise at 0xd00c6bc0
0xd00c6bc0 (raise+0x24) 80410014 l r2,0x14(r1)
(dbx) where
raise(0x0) at 0xd00c6bc0
abort(0x0) at 0xd00c6ad0
main(), line 5 in "ttt.c"
(dbx) quit
# exit
Now, please notice how these files were produce. Both files
were produced -g. -g code is not optimized. Optimized
code is very different internally than -g code. Therefore,
you must compare apples to apples. -g code stripped to
-g code nonstripped. Also, remember -g should not be
used with -O. That is documented in the compiler documentation.
Now, if you have optimized code that is stripped, you
can use a compiler listing and a binder map to locate lines of code.
# cc -O -s -qlist -bR:map ttt.c
# ./a.out
IOT/Abort trap(coredump)
# dbx a.out
dbx Version 3.1
Type 'help' for help.
reading symbolic information ...warning: no source compiled with -g
.using memory image in core.
abort process in raise at 0xd00c6bc0
0xd00c6bc0 (raise+0x24) 80410014 l r2,0x14(r1)
(dbx) where
raise(0x0) at 0xd00c6bc0
abort(0x0) at 0xd00c6ad0
main() at 0x10000284
(dbx) map
Entry 1:
Object name: a.out
Text origin: 0x10000000
Text length: 0x716
Data origin: 0x20051400
Data length: 0x38
File descriptor: 0x8
Entry 2:
Object name: /usr/lib/libc.a
Member name: meth.o
Text origin: 0xd0020000
Text length: 0x143d
Data origin: 0x20000200
Data length: 0x144
File descriptor: 0x9
Entry 3:
Object name: /usr/lib/libc.a
Member name: shr.o
Text origin: 0xd00c2000
Text length: 0xb0f24
Data origin: 0x20001200
Data length: 0x4f950
File descriptor: 0xa
(dbx) quit
Therefore, we are looking for the source line that is responsible
for 0x10000284. One clue, we are in main somewhere. Take a look
at the load map:
0706-812 XCOFF BINDER MAP Page 1
ADDRESS LENGTH CL TY NAME SOURCE FILE COMPILE S
00000000 ER .0.errno import
00000000 ER .1.abort import
00000000 ER .2.exit import
0 00000200 000078 PR SD .3..__start *NO TAG* from /lib/crt0
0 00000278 000040 PR SD .4.<.main> .file from ttt.o
00000278 LD .5..main
We can see that main is located 00000278. The dbx map command
indicated that the starting address for a.out was 0x1000 0000.
.....
Object name: a.out
Text origin: 0x10000000
.....
Therefore, code for main starts at 0x1000 0278. Now, the
difference between 0x1000 0278 and 0x1000 0284 is 0xC.
Now, we can use the listing to determine the actual
source line.
IBM AIX XL C Compiler Version 01.03.0000.0009 --- ttt.c 03/05/94 12:36:02
>>>>> OPTIONS SECTION <<<<<
*** Options In Effect ***
FOLD LIST MAF XCOFF
LANGLVL=EXTENDED
>>>>> OBJECT SECTION, OPTIMIZATION <<<<<
GPR's set/used: ss-s ssss ssss s--- ---- ---- ---- ----
FPR's set/used: ssss ssss ssss ss-- ---- ---- ---- ----
CCR's set/used: ss-- -sss
| 000000 PDEF main
1| PROC
0| 000000 mfspr 7C0802A6 2 LFLR gr0=lr
0| 000004 stu 9421FFC0 1 ST4U gr1,#stack(gr1,-64)=gr1
0| 000008 st 90010048 1 ST4A #stack(gr1,72)=gr0
5| 00000C bl 4BFFFFF5 0 CALL gr3=abort,0,fcr",abort",gr1,cr
5| 000010 cror 4DEF7B82 1
Now we can see that the listing indicates line 5 (first column, 5|)
is responsible for 0xC (second column,00000C).
S e a r c h - k e y w o r d s:
CORE DUM STRIPPED PROGRAM
HR
CENTER
FONT size=2WWQA: ITEM: RTA000073500 ITEM: RTA000073500
BRDated: 02/1995 Category: ITSAI6000GE
BRThis HTML file was generated 99/06/24~12:43:27
BRComments or suggestions?
A href="../../../../feedback.html"BContact us/B/ABR
/FONT
/CENTER
/BODY
/HTML