This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug java/18153] New: Java minsyms get demangled as c++


https://sourceware.org/bugzilla/show_bug.cgi?id=18153

            Bug ID: 18153
           Summary: Java minsyms get demangled as c++
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: java
          Assignee: unassigned at sourceware dot org
          Reporter: xdje42 at gmail dot com

make check RUNTESTFLAGS=jmain.exp
gdb testsuite/gdb.java/jmain
(gdb) b jmain.jmain
(gdb) b jmain::main

The "b jmain::jmain" works because the corresponding minsym got demangled as
c++.

This also means that LOC_UNRESOLVED is (I think, still have to verify it)
broken for Java.  LOC_UNRESOLVED does minsym lookup based on the demangled name
derived from DWARF, but in DWARF we know we have Java.  So I'm guessing a
LOC_UNRESOLVED minsym lookup for "foo.bar" will fail because the minsym got
demangled as "foo::bar".

Note: The code to process LOC_UNRESOLVED is in findvar.c:

        memset (&lookup_data, 0, sizeof (lookup_data));
        lookup_data.name = SYMBOL_LINKAGE_NAME (var);

Heads up when you read this: SYMBOL_LINKAGE_NAME here is actually the demangled
name.

I have a significant rework of minsym support in progress.
Hopefully I can address this with this patch.

To fix LOC_UNRESOLVED I think what we really need to do is do the minsym lookup
using the mangled name. That's the topic of another patch in progress.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]