libstdc++.so.6.0.14-gdb.py installed in the wrong place

[bdubbs@…]

See ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816

In Chapter 6, GCC, we should probably add:

mkdir -p /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/&gcc-version;/

or the equivalent 32-bit location

/usr/share/gdb/auto-load/usr/lib/gcc/i686-pc-linux-gnu/&gcc-version;/

and move /usr/lib/libstdc++.so.6.0.14-gdb.py there.

[bdubbs@…]

Fixed in revision 9795.

[Armin]

I think that just /usr/share/gdb/auto-load is correct location for gdb py files.

[bdubbs@…]

Replying to Krejzi:

I think that just /usr/share/gdb/auto-load is correct location for gdb py files.

I put it in the same location as gentoo.

[Armin]

Replying to bdubbs@…:

Replying to Krejzi:

I think that just /usr/share/gdb/auto-load is correct location for gdb py files.

I put it in the same location as gentoo.

Well, I am not sure why is that, but I see that glib installs it's py files into location that I pointed. I don't know which one is correct. Even ArchLinux installs py files into location I mentioned.

[bdubbs@…]

Replying to Krejzi:

Well, I am not sure why is that, but I see that glib installs it's py files into location that I pointed. I don't know which one is correct. Even ArchLinux installs py files into location I mentioned.

Fedora16 installs to /usr/share/gdb/auto-load/usr/lib64/

Looking at the gdb documentation, it looks like it should be

/usr/share/gdb/auto-load/<full path + name>-gdb.py

In this case <full path + name> should be usr/lib64/libstdc++.so.6.0.16

IOW /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.16-gdb.py

or

case `uname -m` in
  i?86) GDBDIR=/usr/share/gdb/auto-load/usr/lib/   ;;
  *)    GDBDIR=/usr/share/gdb/auto-load/usr/lib64/ ;;
esac

[Bryan Kadzban]

Replying to bdubbs@…:

Looking at the gdb documentation, it looks like it should be

/usr/share/gdb/auto-load/<full path + name>-gdb.py

The gdb source agrees, if I make an assumption that the standard "source search path" includes /usr/share/gdb/auto-load, FWIW.

However, the gdb source also shows that there's support for autoloading these python extensions from a ".debug_gdb_scripts" ELF section in the shared object. Does libstdc++ have one of these? (What does "readelf -x .debug_gdb_scripts libstdc++.so.blah" dump for it? The first byte in the section is 1, and the next sequence of bytes is a zero-terminated script name; multiple scripts can be in a single section.)

I doubt we can change that section, but that might be a way to figure out what name gdb will attempt to look for first.

[bdubbs@…]

Replying to bryan@…:

However, the gdb source also shows that there's support for autoloading these python extensions from a ".debug_gdb_scripts" ELF section in the shared object. Does libstdc++ have one of these? (What does "readelf -x .debug_gdb_scripts libstdc++.so.blah" dump for it?

I get:

$ readelf -x  .debug_gdb_scripts /usr/lib/libstdc++.so.6.0.16
readelf: Warning: Section '.debug_gdb_scripts' was not dumped because it does not exist!

Other commands that may be interesting are:

$ readelf  -a /usr/lib/libstdc++.so.6.0.16 |grep libstd
 0x000000000000000e (SONAME)   Library soname: [libstdc++.so.6]
 000000: Rev: 1  Flags: BASE   Index: 1  Cnt: 1  Name: libstdc++.so.6

$ readelf  -a /usr/lib/libstdc++.so.6.0.16 |grep gdb
<nothing printed>

[bdubbs@…]

Looking at ​http://sourceware.org/gdb/current/onlinedocs/gdb/objfile_002dgdb_002epy-file.html#objfile_002dgdb_002epy-file Where the standard gdb install has:

(gdb) show data-directory
GDB's data directory is "/usr/share/gdb".
(gdb) show debug-file-directory
The directory where separate debug symbols are searched for is "/usr/lib/debug".

So it should be looking in:

/usr/$LIB/debug/libstdc++.so.6.0.16-gdb.py
/usr/share/gdb/auto-load/usr/$LIB/libstdc++.so.6.0.16-gdb.py

where LIB is lib or lib64 according to architecture. Of course, we have /usr/lib64 symlinked to /usr/lib.

So we could just do:

mkdir -p /usr/lib/debug
mv -v /usr/lib/*.py /usr/lib/debug

However I just changed the path in the case statement. Fixed in revision 9805.

[Bryan Kadzban]

Replying to bdubbs@…:

/usr/$LIB/debug/libstdc++.so.6.0.16-gdb.py

Should we just use that directory? Might be simpler than what we're doing.

...As you mention later in that same message. That gets my vote. :-)