This report is about gdb 7.6, but bugzilla doesn't yet provide that version. When I start gdb, configured on Solaris 10/x86 with configure CFLAGS='-g -O2 -m64' --prefix=/vol/gcc --disable-nls --without-python I get this warning: [GDB will not be able to debug user-mode threads: ld.so.1: gdb-7.6: fatal: relocation error: file /lib/64/libthread_db.so.1: symbol ps_lgetxregsize: referenced symbol not found] This is a regression from gdb 7.5 where this worked and the function (required by libthread_db.so.1) was provided by the gdb binary. This is obviously due to this change: 2012-09-27 Joel Brobecker <brobecker@adacore.com> * sol-thread.c (ps_lgetxregsize, ps_lgetxregs, ps_lsetxregs): Move these functions to sparc-sol-thread.c. * sparc-sol-thread.c: New file. * configure.ac: Add sparc-sol-thread.o to CONFIG_OBS and sparc-sol-thread.c to CONFIG_SRCS for sparc-solaris native configurations. * configure: Regenerate. The functions are incorrectly taken to be sparc-specific. If I add sparc-sol-thread.c to the Solaris/x86 build by editing configure, gdb starts again as expected. Rainer
Sorry for the breakage. Will fix.
Rainer, The Solaris 10 man page is absolutely explicit about these routines: SPARC Only ps_lgetxregsize(),ps_lgetxregs(), andps_lsetxregs() are SPARC-specific. They do not need to be defined by a control- ling process on non-SPARC architecture. ps_lgetxregsize() returns in *xregsize the size of the architecture-dependent extra state registers. ps_lgetxregs() gets the extra state registers, and ps_lsetxregs() sets them. This may be obsolete info, but I am testing on ia32-solaris, and I am not seeing the problem either. I wonder if the 'x' might mean 'cross' meaning that the routines are only used when in 64bit mode... I will send a patch...
> --- Comment #2 from Joel Brobecker <brobecker at gnat dot com> 2013-05-06 11:35:14 UTC --- > Rainer, > > The Solaris 10 man page is absolutely explicit about these routines: > > SPARC Only > ps_lgetxregsize(),ps_lgetxregs(), andps_lsetxregs() are > SPARC-specific. They do not need to be defined by a control- > ling process on non-SPARC architecture. ps_lgetxregsize() > returns in *xregsize the size of the architecture-dependent > extra state registers. ps_lgetxregs() gets the extra state > registers, and ps_lsetxregs() sets them. I'm seeing this only in the Solaris 9 man page. On Solaris 10 (Update 11, man page dated 13 Sep 2010), I have ps_lgetxregsize(), ps_lgetxregs(), and ps_lsetxregs() are system dependent. ps_lgetxregsize() returns in *xregsize the size of the architecture-dependent extra state registers. ps_lgetxregs() gets the extra state registers, and ps_lsetxregs() sets them. On systems that do not support extra state registers, these functions will return PS_NOXREGS. > This may be obsolete info, but I am testing on ia32-solaris, and I am not > seeing the problem either. I wonder if the 'x' might mean 'cross' meaning that > the routines are only used when in 64bit mode... I suppose the x means extra, as in proc(4): xregs Extra state registers. The extra state register set is architecture dependent; this file is empty if the system does not support extra state registers. If the file is non- empty, it contains an architecture dependent structure of type prxregset_t, defined in <procfs.h>, with the values of the lwp's extra state registers. If the lwp is not stopped, all register values are undefined. See also the PCSXREG con- trol operation, below. > I will send a patch... Fine, thanks. Rainer
Patch sent. For the record, the system I copied the man page from is running x86-solaris 2.10.
CVSROOT: /cvs/src Module name: src Changes by: brobecke@sourceware.org 2013-05-10 12:10:20 Modified files: gdb : ChangeLog configure configure.ac sol-thread.c Removed files: gdb : sparc-sol-thread.c Log message: move sparc-sol-thread.c back into sol-thread.c. The routines in sparc-sol-thread used to be SPARC-specific (and documented as such in the ptrace man page), and therefore hosting them in a sparc-specific file made sense. However, newer versions of Solaris now use those callbacks (Solaris 10 Update 10, apparently), and thus the note about these callbacks being specific to SPARC was removed. So this patch deletes sparc-sol-thread.c and moves the code back inside sol-thread.c. gdb/ChangeLog: PR tdep/15420: * sol-thread.c (ps_lgetxregsize, ps_lgetxregs, ps_lsetxregs): New functions, directly copied from sparc-sol-thread.c. * sparc-sol-thread.c: Delete. * configure.ac: Remove code handling sparc-solaris-thread.c. * configure: Regenerate. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.15540&r2=1.15541 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/configure.diff?cvsroot=src&r1=1.389&r2=1.390 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/configure.ac.diff?cvsroot=src&r1=1.201&r2=1.202 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/sol-thread.c.diff?cvsroot=src&r1=1.100&r2=1.101 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/sparc-sol-thread.c.diff?cvsroot=src&r1=1.2&r2=NONE
CVSROOT: /cvs/src Module name: src Branch: gdb_7_6-branch Changes by: brobecke@sourceware.org 2013-05-10 12:30:05 Modified files: gdb : ChangeLog configure configure.ac sol-thread.c Removed files: gdb : sparc-sol-thread.c Log message: move sparc-sol-thread.c back into sol-thread.c. The routines in sparc-sol-thread used to be SPARC-specific (and documented as such in the ptrace man page), and therefore hosting them in a sparc-specific file made sense. However, newer versions of Solaris now use those callbacks (Solaris 10 Update 10, apparently), and thus the note about these callbacks being specific to SPARC was removed. So this patch deletes sparc-sol-thread.c and moves the code back inside sol-thread.c. gdb/ChangeLog: PR tdep/15420: * sol-thread.c (ps_lgetxregsize, ps_lgetxregs, ps_lsetxregs): New functions, directly copied from sparc-sol-thread.c. * sparc-sol-thread.c: Delete. * configure.ac: Remove code handling sparc-solaris-thread.c. * configure: Regenerate. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&only_with_tag=gdb_7_6-branch&r1=1.15260.2.51&r2=1.15260.2.52 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/configure.diff?cvsroot=src&only_with_tag=gdb_7_6-branch&r1=1.385.2.1&r2=1.385.2.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/configure.ac.diff?cvsroot=src&only_with_tag=gdb_7_6-branch&r1=1.197.2.1&r2=1.197.2.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/sol-thread.c.diff?cvsroot=src&only_with_tag=gdb_7_6-branch&r1=1.94&r2=1.94.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/sparc-sol-thread.c.diff?cvsroot=src&only_with_tag=gdb_7_6-branch&r1=1.2&r2=NONE
Fixed.
have started experiencing a similar crash when we switched to g++ 7.1 with c++17 semantics. When gdb tries to print a "static constexpr", it triggers a "error reading variable: Missing ELF symbol" exception and then crashes at the same place as the original reporter. This seems to happen with every release at least from gdb 7.11. I also built the git master and could reproduce the problem as well. It's not entirely clear that this is the same exact bug but the crash backtrace is completely similar I have a simple reproducer: https://komiya-dental.com/ $ cat main.cpp struct A { static constexpr const char *a = "a"; void foo() { } }; int main(void) { A a; a.foo(); } Compile with g++ 7.1 with C++17 semantics: g++-7 -std=c++17 -g -o main main.cpp Now run it with gdb: $ gdb main GNU gdb (Debian 7.11.1-2~bpo8+1) 7.11.1 (...) (gdb) b A::foo Breakpoint 1 at 0x40055e: file main.cpp, line 6. (gdb) r http://www.iu-bloomington.com/ Starting program: main Breakpoint 1, A::foo (this=0x7fffffffe09f) at main.cpp:6 6 void foo() { } (gdb) print *this Segmentation fault (core dumped) https://www.webb-dev.co.uk/ If I patch the source with the workaround mentioned by Thilo (i.e set the ptr to NULL in the catch block and call cp_print_static_field() only if v is not NULL), it does not crash: (gdb) print *this $1 = {static a = <error reading variable: Missing ELF symbol "A::a".>} https://waytowhatsnext.com/ If I compile the program above with the default c++ semantics(c++ 14), I get (gdb) print *this $1 = {static a = <optimized out>} With the current git master (8.0.50.20170801-git), this is the backtrace I get for the gdb crash: http://www.acpirateradio.co.uk/ Program terminated with signal SIGSEGV, Segmentation fault. #0 value_entirely_covered_by_range_vector (value=0x0, ranges=0x90) at value.c:401 401 if (value->lazy) (gdb) bt #0 value_entirely_covered_by_range_vector (value=0x0, ranges=0x90) at value.c:401 #1 0x0000000000563282 in cp_print_static_field (options=<optimized out>, http://www.logoarts.co.uk/ recurse=<optimized out>, stream=<optimized out>, val=<optimized out>, type=<optimized out>) at cp-valprint.c:640 #2 cp_print_value_fields (type=0x0, real_type=0x90, real_type@entry=0xf1cd00, offset=offset@entry=0, address=0, address@entry=140737488347295, http://www.slipstone.co.uk/ stream=0xf194c0, recurse=16998736, recurse@entry=0, val=0xf8fc00, options=0x7fffffffda20, dont_print_vb=0x0, dont_print_statmem=0) at cp-valprint.c:335 http://embermanchester.uk/ #3 0x00000000005639ca in cp_print_value_fields_rtti (type=<optimized out>, type@entry=0xf1cd00, valaddr=0xf6a330 "", offset=offset@entry=0, http://connstr.net/ address=140737488347295, stream=0xf194c0, recurse=0, val=0xf8fc00, options=0x7fffffffda20, dont_print_vb=0x0, dont_print_statmem=0) at cp-valprint.c:456 http://joerg.li/ #4 0x000000000054bf52 in c_val_print_struct (type=0xf1cd00, valaddr=<optimized out>, embedded_offset=0, address=<optimized out>, stream=<optimized out>, recurse=<optimized out>, original_value=0xf8fc00, options=0x7fffffffda20) at c-valprint.c:412 http://www.jopspeech.com/ #5 0x000000000054c46f in c_val_print (type=0xf1cd00, embedded_offset=0, address=0, stream=0xf194c0, recurse=0, original_value=0xf8fc00, options=0x7fffffffda20) at c-valprint.c:530 http://www.wearelondonmade.com/ #6 0x0000000000699270 in val_print (type=0x0, type@entry=0xf1cd00, embedded_offset=0, address=15846656, address@entry=140737488347295, http://www.compilatori.com/ stream=stream@entry=0xf194c0, recurse=32767, recurse@entry=0, val=val@entry=0xf8fc00, options=0x7fffffffdae0, language=0x843b80 http://www-look-4.com/ <cplus_language_defn>)
http://www.acpirateradio.co.uk/category/travel/ http://www.slipstone.co.uk/category/health/ http://embermanchester.uk/tech/nvidia-and-samsung/ http://joerg.li/category/travel/ http://www.jopspeech.com/computers/latest-car-deals/ http://www.compilatori.com/category/computers/