dbx error "Dectected a Cfront compiled file"
Here's my environment:
$ CC -V
CC: Sun C++ 5.8 Patch 121017-04 2006/08/02
$ fbe -V
fbe: Sun Compiler Common 11 Patch 120760-09 2006/08/16
$ dbx -V
Sun Dbx Debugger 7.5 Patch 121023-02 2006/05/26
$ uname -a
SunOS xenapp02 5.11 snv_40 sun4u sparc SUNW,Sun-Fire-880
since installing the latest CC/dbx patches on Friday I get this error when I try to debug an executable (actually a unit test harness):
$ dbx export/s4_510_cc/dbg/bin/tests/test_fw_comm
Reading test_fw_comm
dbx: Detected a Cfront (CC.2.0.x) compiled file "03 2005/05/11"
- this stab format is unsupported
dbx: warning: object initialization interrupted - no program loaded
I can't reproduce this with a simple testcase (single source file) so I'm not sure what it is about my larger project which could be causing the problem (but note that all was fine until installing the latest Studio patches last week).
Matt.
[985 byte] By [
stupplem] at [2007-11-26 10:03:56]
# 1
Looks like dbx's gone crazy while reading stabs, because it is very unlikely that your file is really named "03 2005/05/11". I checked READMEs for all the patches and found nothing harmful about them, neither one [at least, explicitly] affects debugger info generation. It is possible, however, that some of previous patches did that...
Unfortunately, without a reproducible test case at hand, I can't help much. It is *possible* that after complete re-build of your application (first, clean all object files and libraries, and the do the build) the problem might go away.
# 2
I have a small testcase which produces a different error from dbx:
$ dbx bar
Reading bar
dbx: warning: ".index.stab" section error in "/export/home/matt/dev/playpen/dtrace/bar", stab #94 and beyond have been ignored
Test consists of a couple of source files and an associated Makefile - I can post the whole lot inline here, or send via email ... let me know if this is useful.
Thanks,
Matt.
# 3
Yes, it got to be useful. Please send the files to maxim dot kartashev at sun dot com.
Thank you!
P.S. As an alternative, you can file a bug through http://bugs.sun.com/services/bugreport/index.jsp. You can use 'dbx' as a product for the first stage (it might as well be a compiler bugs, but this can be changed later after initial investigation)
# 4
I've emailed the code/Makefile for my example.
Note that after looking through my checkin history I guessed that the problem might have coincided with the addition of some dtrace USDT probes to my code, and indeed if I remove the USDT probes then dbx no longer has problems loading my binary. So, I guess this a problem in the interaction between code (in this case C++ code) with USDT probes and dbx - possibly a dtrace problem or possibly a dbx one...
Thanks,
Matt.
# 5
Looks like a problem with '-r' option of ld, it corrupts stabs information:
$ dumpstabs foo_with_probes.o
<skip>
Bad string index for stab #3
Bad string index for stab #4
...
<skip>
Workaround would be not to produce combined object file foo_with_probes.o, but link all object files in one step. I checked this and it worked for me.
As for ld problem, I'll look into this more and file a bug, if needed.
# 6
Thanks for looking into this Maxim.
Unfortunately for my 'real' application the dtrace-generated object is part of a static library which gets linked in to my binary, and at present I need the ld -r trick to ensure that the dtrace-generated code is not simply discarded by the linker (see this thread http://www.opensolaris.org/jive/thread.jspa?threadID=13151 on dtrace-discuss for details).
# 7
When using the compiler driver to link your program, the driver will
add some "helper libraries" that augment the way ld processes
stabs sections. If you can find a way to use the compiler driver
in combination with -r (I don't know if our compilers support this)
that might fix the problem. Are you compiling the dtrace object file
with -g? If so, you might try removing the -g from that one .o file
and see if the problem goes away.
--chris
# 8
Thanks for the followup Chris. I'm not sure what you mean by 'Are you compiling the dtrace object file with -g?' because dtrace *creates* the object file directly (dtrace -G that is). Do you mean the compile the source files which contain probes without -g?
I don't really understand the 'compiler driver' idea - but my current thinking is that my best bet is to investigate a way to create a dummy reference to the dtrace-generated object so that I can bypass the ld -r step entirely (... as mentioned in the thread on dtrace-discuss).
For now, I'm just not linking the dtrace-generated object (so my probes don't ever fire) because it's more important to be able to debug.
Matt.
# 9
Sorry about my previous post, I was confused. I forgot dtrace automatically
generated the object file.
I reproduced your problem using the tar file you posted in the dtrace forum.
The problem is that using "ld -r" will mess up your stabs. A few bookkeeping
stabs are generated by the compiler, even when you don't compile with -g.
If you remove these bookkeeping stabs from the dtrace object file, they won't
interfere with the stabs in the other object files.
Run these commands on the dtrace object file to remove the stabs:
mcs -d -n .stab.index foo_probes.o
mcs -d -n .stab.indexstr foo_probes.o
Do this before using the object file with "ld -r".
That should fix the problem.
# 10
Magic. The mcs commands do the trick and now I'm dtrace-ing and dbx-ing again.Thanks Chris.
