Frank Hofmann wrote:
> On Thu, 21 Dec 2006, Roland Mainz wrote:
> > Is there any reason that the Sun Studio compiler still gets called with
> > -xO[1-5]/-O (=optimizer enabled) when "bldenv" was called with the debug
> > switch ("-d") ? Sometimes this makes debugging (or core dump analysis)
> > harder then neccesary... ;-(
>
> Exactly when ? Can you give an example ?
Quick example from "dbx" (debugging a 64bit korn shell 93 instance):
-- snip --
$ kill 5217
signal TERM (Terminated) in _kill at 0xffffffff7eec42b8
0xffffffff7eec42b8: _kill+0x0008: blu __cerror !
0xffffffff7ee3a674
(dbx) where
=>[1] _kill(0x0, 0xf, 0x7fffffffffffffff, 0x8000000000000000, 0x0, 0x0),
at 0xffffffff7eec42b8
[2] job_kill(0xffffffff7f2927a0, 0xf, 0x1, 0x14970c,
0xffffffff7f28aeb0, 0xffffffff7f28ee74), at 0xffffffff7f1418b0
[3] job_walk(0x100109436, 0xffffffff7f1417a0, 0xf, 0xffffffff7ef0ae20,
0xffffffff7f28ee58, 0x3), at 0xffffffff7f14124c
[4] b_kill(0xffffffff7eae3e18, 0x0, 0xffffffff7f28e770, 0x16bf5c,
0xffffffff7f28aeb0, 0x0), at 0xffffffff7f11f2b8
[5] sh_exec(0x1001093e0, 0x24, 0x1001093e0, 0x36, 0x24, 0x100109470),
at 0xffffffff7f16b63c
[6] exfile(0xffffffff7f28e770, 0x1001093e0, 0x34, 0xffffffff7f28ee58,
0xffffffff7f28ee58, 0xffffffff7f28e770), at 0xffffffff7f1507fc
[7] sh_main(0xffffffff7f28e770, 0x0, 0xffffffff7f28aeb0,
0xffffffff7f28e770, 0xffffffff7f28aeb0, 0xffffffff7f28aeb0), at
0xffffffff7f14fcf4
-- snip --
... in this case I (and most graphical analysis tools) would expect that
"dbx" shows me variable names and values - which is AFAIK not possible
when the optimizer was used (dbx operates in a restricted mode when
"-xO[0-5] -g" was used). Recompiling the code without optimisation
brings back this information (and allows graphical analysis tools to do
it's job).
For comparisation the dbx stacktrace without optimisation looks like
this:
-- snip --
$ kill 5240
signal TERM (Terminated) in _kill at 0xffffffff7e8c4278
0xffffffff7e8c4278: _kill+0x0008: blu __cerror !
0xffffffff7e83a634
Current function is job_kill
879 if((r = kill(pid,sig))>=0 &&
!stopsig)
(dbx) where
[1] _kill(0x0, 0xf, 0x1, 0xfffffffffffe54b1, 0x6c00, 0x6c00652f), at
0xffffffff7e8c4278
=>[2] job_kill(pw = 0x1002f2308, sig = 15), line 879 in "jobs.c"
[3] job_walk(file = 0x1002e30d0, fun = 0x10004cfa0 = &job_kill(struct
process *pw, int sig), arg = 15, joblist = 0x1002fe110), line 716 in
"jobs.c"
[4] b_kill(argc = 2, argv = 0x1002fe110, extra = 0x1002df770), line
213 in "trap.c"
[5] sh_exec(t = 0x1002fe090, flags = 4), line 826 in "xec.c"
[6] exfile(shp = 0x1002df770, iop = 0x1002e3020, fno = 0), line 587 in
"main.c"
[7] sh_main(ac = 3, av = 0xffffffff7ffff978, userinit = (nil)), line
362 in "main.c"
[8] main(argc = 3, argv = 0xffffffff7ffff978), line 29 in "pmain.c"
-- snip --
[snip]
> My experience with the code generators, particularly on x86, is such that
> the assembly code actually becomes quite unreadable when optimizaton is
> disabled due to all the unnecessary loads/stores.
I was more thinking about high-level debuggers like "dbx" ... I'd like
to avoid digging in shell code from the assember level if possible...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
