According to GDB 7.1's info manual, if the app has linked to a XXX.so file, GDB automatically loads XXX.so-gdb.py in /usr/share/gdb/auto-load/. Then the glib package installs libglib-*.so*-gdb.py and libgobject-*.so*-gdb.py for App. that linked glib. When I compile below C source, and inspect "list" variable with GDB print command before "return 0", GDB should load libglib-*.so*.gdb.py and should print following output: (gdb) p list $3 = 0x804be80 = {0x804852c, 0x8048532} But, rather, it actually prints following output: (gdb) p list $1 = (GSList *) 0x804be80 This is because GDB does not automatically load the suitable xxx-gdb.py in /usr/share/gdb/auto-load/. If I manually load that file in the "(gdb)" prompt, it works as expected: (gdb) source /usr/share/gdb/auto-load/libglib-2.0.so.0.2200.5-gdb.py (gdb) p list $3 = 0x804be80 = {0x804852c, 0x8048532} I'm not sure that it is a gentoo packaging bug or GDB's though. The sample program: /* compile: cc -g3 `pkg-config --cflags --libs glib-2.0` */ #include <glib.h> int main(void) { GSList *list = NULL; list = g_slist_append(list, "first"); list = g_slist_append(list, "second"); return 0; } Reproducible: Always Steps to Reproduce: 1. Compile the source 2. run "gdb a.out", and step to the "return 0;" statement using GDB "next" command, then type "print list". Actual Results: (gdb) p list $1 = (GSList *) 0x804be80 Expected Results: (gdb) p list $1 = 0x804be80 = {0x804852c, 0x8048532} Note that actual addresses can be different.
$ emerge --info Portage 2.1.8.3 (default/linux/x86/10.0, gcc-4.4.3, glibc-2.11.2-r0, 2.6.28-gentoo-r5 i686) ================================================================= System uname: Linux-2.6.28-gentoo-r5-i686-Intel-R-_Core-TM-2_Quad_CPU_Q9400_@_2.66GHz-with-gentoo-1.12.13 Timestamp of tree: Wed, 25 Aug 2010 04:00:01 +0000 distcc 3.1 i686-pc-linux-gnu [disabled] ccache version 2.4 [enabled] app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r2, 3.1.2-r3 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.1.2, 4.3.4, 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b sys-devel/make: 3.81 virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -ggdb" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/openfire/resources/security/ /usr/share/X11/xkb /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests ccache distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://ftp.kaist.ac.kr/pub/gentoo http://gentoo.gg3.net/ http://ftp.gentoo.or.kr http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="ko_KR.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en ko" MAKEOPTS="-j8" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/gentoo-kr /usr/portage/local" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl acpi alsa bash-completion berkdb branding bzip2 cairo cjk cli consolekit cracklib crypt cups cxx dbus device-mapper dri emacs encode esd fam firefox flac fortran gdbm gif gnome gpm gstreamer gtk hal iconv jpeg kpathsea libnotify mad mikmod mmx mmx2 modules mp3 mpeg mudflap ncurses nls nptl nptlonly nvidia ogg opengl openmp pam pcre pdf perl png policykit ppds pppd python qt3support readline reflection samba sdl session spell spl sqlite sse sse2 ssl svg sysfs tcpd tiff truetype unicode vorbis x86 xml xorg zlib" ALSA_CARDS="intel8x0 intel8x0m hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en ko" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
if you do `strace -o log gdb ...`, can you see it accessing any of the auto-load paths ?
(In reply to comment #2) > if you do `strace -o log gdb ...`, can you see it accessing any of the > auto-load paths ? > Well, I finally found what was wrong from strace output. GDB did try to find the auto-load .py files in /usr/share/gdb, but the path was wrong. If it has dependency to /usr/lib/libXXX.so, it tries to load /usr/share/gdb/auto-load/usr/lib/libXXX.so-gdb.py. However, all library packages seems to install their own auto-load .py files in /usr/share/gdb/*.py. Here's the output that you might get interested: $ ls -l /usr/share/gdb/auto-load/ total 8 -rwxr-xr-x 1 root root 190 Jul 5 13:54 libglib-2.0.so.0.2200.5-gdb.py* -rwxr-xr-x 1 root root 193 Jul 5 13:54 libgobject-2.0.so.0.2200.5-gdb.py* $ #... $ strace -o log gdb a.out # loading a.out that has dependency to / linked to libglib..so $ grep -w auto-load log open("/usr/share/gdb/auto-load/home/cinsk/src/gdb/a.out-gdb.py", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/share/gdb/auto-load/lib/ld-2.11.2.so-gdb.py", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/share/gdb/auto-load/usr/lib/libglib-2.0.so.0.2200.5-gdb.py", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/share/gdb/auto-load/lib/libc-2.11.2.so-gdb.py", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
upstream documentation says this is expected behavior: http://sourceware.org/gdb/current/onlinedocs/gdb/objfile_002dgdb_002epy-file.html#objfile_002dgdb_002epy-file "gdb looks for a file named objfile-gdb.py, where objfile is the object file's real name, formed by ensuring that the file name is absolute ... then gdb will look for a file named data-directory/python/auto-load/real-name ... and real-name is the object file's real name, as described above" further, the only files installed on my system shows correct behavior: $ find /usr/share/gdb/auto-load/ -type f /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.1/32/libstdc++.so.6.0.14-gdb.py /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.1/libstdc++.so.6.0.14-gdb.py /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.0/32/libstdc++.so.6.0.14-gdb.py /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.0/libstdc++.so.6.0.14-gdb.py so please file bugs for each package that installs a .py file into /usr/share/gdb/auto-load/ and does not use the full path. or, if those packages arent actually in the tree, open bugs with the relevant upstream projects. looks like dev-libs/glib is broken.
