[Bug gdb/27713] New: debug symbols are present, but still getting "No symbol table info available."

[Bug gdb/27713] New: debug symbols are present, but still getting "No symbol table info available."

[nagyt at nexus dot hu]

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

            Bug ID: 27713
           Summary: debug symbols are present, but still getting "No
                    symbol table info available."
           Product: gdb
           Version: 10.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: nagyt at nexus dot hu
  Target Milestone: ---

I compiled mxnet with debug symbols on aarch64 with gcc 7.5 (gcc (Ubuntu/Linaro
7.5.0-3ubuntu1~18.04) 7.5.0). I confirmed the existance of debug symbols with
both "readelf" and gdb "i sharedlib", I definitely have the debug symbols.

readelf output: https://pastebin.com/S7aPScLK
info sharedlib output: https://pastebin.com/iYpCR5qb

However whenever I switch to a frame in libmxnet.so, and do "info locals" I get
a "No symbol table info available." error message.

I uploaded the full backtrace for all threads here:
threads apply all bt f: https://pastebin.com/ptDLYY71

You can see that every mxnet row gets the same error message.
"No symbol table info available."

 I also tried to do info locals on frame 5 (thread 1) and I got the same error
there too.

(gdb) f 5
#5  0x0000007f82668db4 in MXNDArraySyncCopyToCPU () from
/home/ubuntu/.cache/pypoetry/virtualenvs/genesis-jXhRyLa0-py3.7/lib/python3.7/site-packages/mxnet/libmxnet.so
(gdb) info locals
No symbol table info available.

I tried this with the official gdb 10.1 and also the ubuntu delivered "GNU gdb
(Ubuntu 8.1.1-0ubuntu1) 8.1.1". 

(There were a few differences: i.e. gdb 8.1.1 could show "info locals" for
frame #0 and #1 (Thread #1). gdb 10.1 showed the error message for these frames
too as you can see in the above file. However these frames have nothing to do
with mxnet)

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

[Bug gdb/27713] debug symbols are present, but still getting "No symbol table info available."

[schwab@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
The presence of debug info doesn't mean that it is detailed enough, or that
every part of the object is covered.

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

[Bug gdb/27713] debug symbols are present, but still getting "No symbol table info available."

[nagyt at nexus dot hu]

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

--- Comment #2 from winnie <nagyt at nexus dot hu> ---
Hi Andreas,
 Thank you for your reply. So what can I do in order to check if "it is
detailed enough, or that every part of the object is covered." Since I'm
struggling with this for a while now, I am happy to provide any information in
order to understand what's going on.

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

[Bug gdb/27713] debug symbols are present, but still getting "No symbol table info available."

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to winnie from comment #2)
> Hi Andreas,
>  Thank you for your reply. So what can I do in order to check if "it is
> detailed enough, or that every part of the object is covered." Since I'm
> struggling with this for a while now, I am happy to provide any information
> in order to understand what's going on.

What I would normally do is use "readelf -wi" (or equivalent formulation
for objdump) and pipe through a pager, then search for the particular
compilation unit I'm interested in.
Like, does "MXNDArraySyncCopyToCPU" appear?
One typical failure mode is to have some particular file compiled
without debuginfo, maybe it was missed by "make clean" or something like that.

gdb could be a bit more helpful in diagnosing this situation.
Though of course, without debuginfo it can't supply source file
names, so maybe the best it could do is some kind of generic warning.

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

[Bug gdb/27713] debug symbols are present, but still getting "No symbol table info available."

[nagyt at nexus dot hu]

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

--- Comment #4 from winnie <nagyt at nexus dot hu> ---
Thank you Tom. The MXNDArraySyncCopyToCPU was not in the output of readelf. I
managed to compile a new version that has it. Now I have to wait it for hanging
again, but I think I will be fine from this point, so I guess this ticket can
be closed. Thank you again!

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

[Bug gdb/27713] debug symbols are present, but still getting "No symbol table info available."

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |NOTABUG

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
Thanks for the report.

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