Bug 157179 - Java code misidentified as c++ by gdb when compiled with -findirect-dispatch -shared -Wl,-Bsymbolic
Java code misidentified as c++ by gdb when compiled with -findirect-dispatch ...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
rawhide
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Jan Kratochvil
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-08 09:49 EDT by Robin Green
Modified: 2008-05-06 20:10 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:10:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robin Green 2005-05-08 09:49:18 EDT
Description of problem:
Not sure if this is a gcc bug or a gdb bug. Java code that has been compiled
with -findirect-dispatch -shared -Wl,-Bsymbolic (i.e. "BC ABI") is misidentified
by gdb as C++ code, so you get gdb backtraces in C++ syntax, and you fail to set
breakpoints if you try to set them using Java syntax.

Version-Release number of selected component (if applicable):
gcc-java-4.0.0-2

How reproducible:
Every time

Steps to Reproduce:
0. Install gdb version 6.3.0.0-1.21
1. Build a Java project with gdb --args ant
-Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
2. set language java
3. b 'org.eclipse.jdt.internal.compiler.batch.Main.compile(String[])'
4. run
  
Actual results:
Breakpoint should be hit when the build reaches compile stage.

Expected results:
Breakpoint is never hit. However, translating it to C++ syntax makes it work,
i.e. b
'org::eclipse::jdt::internal::compiler::batch::Main::compile(JArray<java::lang::String*>*)'
works

Additional info:
gdb-6.3.0.0-1.21
Comment 1 Robin Green 2005-05-08 10:00:39 EDT
Curiouser and curiouser. Not sure if this is related, but gdb thinks the symbol
table information is missing as well. Trying again with "set verbose on" reveals
that it is reading the relevant debuginfo:

Reading symbols from
/usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so...Reading
symbols from
/usr/lib/debug/usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so.debug...done.

But I cannot get any local variables or method parameters to display for the
method org.eclipse.jdt.internal.compiler.batch.Main.compile(String[]), even
though it supposedly has read the debuginfo:

Breakpoint 2, 0x04922612 in
org::eclipse::jdt::internal::compiler::batch::Main::compile ()
   from /usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so
(gdb) info locals
No symbol table info available.
(gdb) bt
Reading in symbols for ../../../libffi/src/x86/sysv.S...done.
Reading in symbols for ../../../libffi/src/x86/ffi.c...done.
Reading in symbols for ../../../libjava/java/lang/reflect/natMethod.cc...done. 
                     
Reading in symbols for ../../../libjava/gnu/java/lang/natMainThread.cc...done.
Reading in symbols for ../../../libjava/gnu/java/lang/MainThread.java...done.
Reading in symbols for ../../../libjava/java/lang/natThread.cc...done.
Reading in symbols for ../../../libjava/prims.cc...done.
Reading in symbols for ../../../libjava/gij.cc...done.
Reading in symbols for ../sysdeps/generic/libc-start.c...done.
#0  0x04922612 in org::eclipse::jdt::internal::compiler::batch::Main::compile ()
   from /usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar.so
#1  0x03cfb307 in ffi_call_SYSV () at ../../../libffi/src/x86/sysv.S:60
#2  0x03cfafd6 in ffi_call (cif=0xbfb6a398, fn=0x2, rvalue=0xbfb6a3b0,
avalue=0xbfb6a310) at ../../../libffi/src/x86/ffi.c:221
#3  0x0399d404 in _Jv_CallAnyMethodA (obj=0x11a5ee0, return_type=Reading in
symbols for ../../../libjava/java/lang/natClass.cc...done.
0x42a07a0, meth=0x4f2a750, is_constructor=0 '\0', is_virtual_call=1 '\001',
parameter_types=0xfe7f80, args=0xbfb6a410, result=0xbfb6a470,
    is_jni_call=0 '\0', iface=0x0) at
../../../libjava/java/lang/reflect/natMethod.cc:516
#4  0x0399d960 in _Jv_CallAnyMethodA (obj=0x2, return_type=0x42a07a0,
meth=0x4f2a750, is_constructor=0 '\0', parameter_types=0xfe7f80,
    args=0xfe7f90, iface=0x2) at ../../../libjava/java/lang/reflect/natMethod.cc:651
#5  0x0399ddd5 in java::lang::reflect::Method::invoke (this=0x1137de0,
obj=0x11a5ee0, args=0x2)
    at ../../../libjava/java/lang/reflect/natMethod.cc:193
#6  0x001f1763 in org::eclipse::jdt::core::JDTCompilerAdapter::execute ()
   from
/usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0/jdtCompilerAdapter.jar.so
#7  0x0076eb43 in org::apache::tools::ant::taskdefs::Javac::compile () from
/usr/lib/libant-1.6.2.jar.so
#8  0x0076e2dc in org::apache::tools::ant::taskdefs::Javac::execute () from
/usr/lib/libant-1.6.2.jar.so
#9  0x0072b23c in org::apache::tools::ant::UnknownElement::execute () from
/usr/lib/libant-1.6.2.jar.so
#10 0x00729ea4 in org::apache::tools::ant::Task::perform () from
/usr/lib/libant-1.6.2.jar.so
#11 0x007294e3 in org::apache::tools::ant::Target::execute () from
/usr/lib/libant-1.6.2.jar.so
#12 0x007296d7 in org::apache::tools::ant::Target::performTasks () from
/usr/lib/libant-1.6.2.jar.so
#13 0x00723201 in org::apache::tools::ant::Project::executeTarget () from
/usr/lib/libant-1.6.2.jar.so
#14 0x00722ca0 in org::apache::tools::ant::Project::executeTargets () from
/usr/lib/libant-1.6.2.jar.so
#15 0x0071eeb9 in org::apache::tools::ant::Main::runBuild () from
/usr/lib/libant-1.6.2.jar.so
#16 0x0071d166 in org::apache::tools::ant::Main::startAnt () from
/usr/lib/libant-1.6.2.jar.so
#17 0x00b46b99 in org::apache::tools::ant::launch::Launcher::run () from
/usr/lib/libant-launcher-1.6.2.jar.so
#18 0x00b46239 in org::apache::tools::ant::launch::Launcher::main () from
/usr/lib/libant-launcher-1.6.2.jar.so
#19 0x0398a9cd in gnu::java::lang::MainThread::call_main (this=0x77dc8) at
../../../libjava/gnu/java/lang/natMainThread.cc:47
#20 0x03a1e9c2 in gnu.java.lang.MainThread.run() (this=0x77dc8) at
../../../libjava/gnu/java/lang/MainThread.java:105
#21 0x03999ce1 in _Jv_ThreadRun (thread=0x77dc8) at
../../../libjava/java/lang/natThread.cc:289
#22 0x0395f6b1 in _Jv_RunMain (vm_args=0x2, klass=0x0, name=0xbfb6d105
"org.apache.tools.ant.launch.Launcher", argc=14, argv=0xbfb6ab38,
    is_jar=false) at ../../../libjava/prims.cc:1331
#23 0x00d3c9cd in main (argc=19, argv=0xbfb6ab24) at ../../../libjava/gij.cc:328
#24 0x00bd0de6 in __libc_start_main (main=0x80483f4, argc=19, ubp_av=0xbfb6ab24,
init=0x80484d8 <__libc_csu_init>,
    fini=0x8048528 <__libc_csu_fini>, rtld_fini=Reading in symbols for
dl-fini.c...done.
0xbabcfd <_dl_fini>, stack_end=0xbfb6ab1c) at ../sysdeps/generic/libc-start.c:228
#25 0x08048455 in _start ()


Here is the contents of my .gdbinit:

set history save
handle SIGHUP nostop print
handle SIGSEGV nostop print
handle SIGPWR nostop noprint
handle SIGXCPU nostop noprint
handle SIG32 nostop noprint
set debug-file-directory /usr/lib/debug
Comment 2 Robin Green 2005-05-08 10:08:52 EDT
By the way, I used the eclipse-jdt-3.1.0_fc-0.M6.15 and
eclipse-debuginfo-3.1.0_fc-0.M6.15 RPMs for this test case, so the relevant gcc
version is actually whatever gcc version they were compiled with.
Comment 3 Robin Green 2005-05-08 12:29:24 EDT
Possibly a symptom of bug 153247
Comment 4 Jakub Jelinek 2005-05-08 12:40:49 EDT
The Java bits are marked with DW_AT_language 11 (i.e. DW_LANG_Java).
Comment 5 Bug Zapper 2008-04-03 12:09:11 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 6 Bug Zapper 2008-05-06 20:10:14 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

Note You need to log in before you can comment on or make changes to this bug.