From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: cogen@ll.mit.edu Cc: gnu-gdb-bug@moderators.isc.org, gdb@sourceware.cygnus.com Subject: Re: gdb seg violation during print command Date: Wed, 03 May 2000 10:59:00 -0000 Message-id: <200005031759.TAA18350@landau.wins.uva.nl> References: <200005031637.MAA25467@ll.mit.edu> X-SW-Source: 2000-05/msg00013.html From: David Cogen Date: 03 May 2000 12:39:31 -0400 I have a simple test case which demonstrates this problem. The following is a transcript. I trust I have included all necessary details? [ CC'd to gdb@sourceware.cygnus.com, the original message can be found in the bug-gdb mailing list archive ] Excellent! This is what I see on sparc-sun-solaris2.6 with a GDB compiled from the trunk (I don't have a build from the 5.0 branch lying around here right now). The test program was compiled with egcs-2.91.66. GNU gdb 20000204 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.6"... (gdb) b main Breakpoint 1 at 0x1a318: file test.cc, line 9. (gdb) r Starting program: /tmp/./test Breakpoint 1, main () at test.cc:9 9 { (gdb) p tteesstt11(1) Cannot resolve function tteesstt11 to any overloaded instance (gdb) No segfaults anymore, but the current behaviour seems to be wrong too. Any of the C++ guru's know what's happening here? Mark >From dan@cgsoftware.com Wed May 03 14:10:00 2000 From: Daniel Berlin To: Mark Kettenis Cc: dan@cgsoftware.com, gdb@sourceware.cygnus.com Subject: Re: gdb seg violation during print command Date: Wed, 03 May 2000 14:10:00 -0000 Message-id: References: <200005031637.MAA25467@ll.mit.edu> <200005031759.TAA18350@landau.wins.uva.nl> <200005032105.e43L5U300694@delius.kettenis.local> X-SW-Source: 2000-05/msg00014.html Content-length: 937 Mark Kettenis writes: > > > > What version of gdb is this really? IE when is it from? > (We've had 20000204 there forever). > > April 25. But I just tested it with a GDB compiled from sources > checked out of CVS half an our ago. No difference. Okay. And you said egcs 1.1.2, right? Please "set debug overload 1" and retry, and send me the results. I suspect the problem is that that version of egcs is marking types with the wrong sign in the debug info in certain cases, and the rank_one_type code isn't handling the specific case, and defaulting to saying it's an incompatible overload. I ran into this problem once before, and had patches to deal with these specific comparisons in rank_one_type, but i seem to have lost them during a file system screwup (I did them in early january). They were trivial, and i can redo them. But first, i need to make sure that's the problem. > > Mark >From dan@cgsoftware.com Wed May 03 14:22:00 2000 From: Daniel Berlin To: cogen@ll.mit.edu (David Cogen), Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: gdb seg violation during print command Date: Wed, 03 May 2000 14:22:00 -0000 Message-id: References: <200005031637.MAA25467@ll.mit.edu> X-SW-Source: 2000-05/msg00015.html Content-length: 2074 cogen@ll.mit.edu (David Cogen) writes: First off, your code is broken. You claim to return an int, but don't. This is what is causing the segfault in gdb. It's impossible for us to not believe the compiler when it says "this function returns an int". We expect it to return an int. In the newer gdb, what'll happen is you'll get no segfault, but a weird number returned, which will actually the address of the function, which is the last value we have around, i guess. > I have a simple test case which demonstrates this problem. The following is a > transcript. I trust I have included all necessary details? > > redsavina% uname -a > SunOS redsavina 5.7 Generic_106541-09 sun4u sparc SUNW,Ultra-Enterprise > redsavina% g++ --version > 2.95.2 > redsavina% gdb --version > GNU gdb 4.18 > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "sparc-sun-solaris2.4". > redsavina% cat test.cc > #include > > int tteesstt11 (int) > { > cerr << "\n"; > } > > int main () > { > } > > redsavina% g++ -g -o test test.cc > redsavina% gdb -n ./test > GNU gdb 4.18 > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "sparc-sun-solaris2.4"... > (gdb) break main > Breakpoint 1 at 0x1a8a0: file test.cc, line 9. > (gdb) r > Starting program: /data/redsavina0/cogen/l/astb/src/util/derive_message_stream_files/./test -input test.strm > > Breakpoint 1, main () at test.cc:9 > 9 { > (gdb) p tteesstt11(1) > Segmentation Fault (core dumped) > redsavina% >From kettenis@wins.uva.nl Wed May 03 15:43:00 2000 From: Mark Kettenis To: dan@cgsoftware.com Cc: dan@cgsoftware.com, gdb@sourceware.cygnus.com Subject: Re: gdb seg violation during print command Date: Wed, 03 May 2000 15:43:00 -0000 Message-id: <200005032243.e43Mh6F00788@delius.kettenis.local> References: <200005031637.MAA25467@ll.mit.edu> <200005031759.TAA18350@landau.wins.uva.nl> <200005032105.e43L5U300694@delius.kettenis.local> X-SW-Source: 2000-05/msg00016.html Content-length: 2533 Reply-To: dan@cgsoftware.com Cc: dan@cgsoftware.com, gdb@sourceware.cygnus.com From: Daniel Berlin Date: 03 May 2000 17:10:37 -0400 User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/21.1 (Canyonlands) Content-Type: text/plain; charset=us-ascii Mark Kettenis writes: > > > > What version of gdb is this really? IE when is it from? > (We've had 20000204 there forever). > > April 25. But I just tested it with a GDB compiled from sources > checked out of CVS half an our ago. No difference. Okay. And you said egcs 1.1.2, right? That's what it is according to the "Timeline" on gcc.gnu.org :-). Please "set debug overload 1" and retry, and send me the results. sh-2.03$ ./gdb /tmp/test GNU gdb 20000204 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.6"... Setting up the environment for debugging gdb. .gdbinit:5: Error in sourced command file: Function "internal_error" not defined. (gdb) set debug overload 1 (gdb) b main Breakpoint 1 at 0x1a318: file test.cc, line 9. (gdb) r Starting program: /tmp/test Breakpoint 1, main () at test.cc:9 9 { (gdb) p tteesstt1(1) Overloaded function instance tteesstt11(int) # of parms 0 ...Badness @ 0 : 100 Overload resolution champion is 0, ambiguous? 0 Cannot resolve function tteesstt11 to any overloaded instance (gdb) quit The program is running. Exit anyway? (y or n) y Does that tell you anything? I suspect the problem is that that version of egcs is marking types with the wrong sign in the debug info in certain cases, and the rank_one_type code isn't handling the specific case, and defaulting to saying it's an incompatible overload. I ran into this problem once before, and had patches to deal with these specific comparisons in rank_one_type, but i seem to have lost them during a file system screwup (I did them in early january). They were trivial, and i can redo them. Well, if you can easily fix this, go ahead. Otherwise it might be better to concentrate your effeorts on improving support for compilers that don't have this bug. Mark >From cogen@ll.mit.edu Thu May 04 09:59:00 2000 From: David Cogen To: dan@cgsoftware.com Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com Subject: Re: gdb seg violation during print command Date: Thu, 04 May 2000 09:59:00 -0000 Message-id: <200005041655.MAA10513@ll.mit.edu> References: X-SW-Source: 2000-05/msg00017.html Content-length: 874 > First off, your code is broken. You claim to return an int, but don't. > This is what is causing the segfault in gdb. > It's impossible for us to not believe the compiler when it says "this > function returns an int". We expect it to return an int. Sorry, that's not it. I have also tried the following: #include int tteesstt11 (int) { cerr << "\n"; return 4; } int main () { } print tteesstt11(1) from a breakpoint in main() still causes gdb to seg fault. Indeed, I have tried lots of forms for tteesstt11; they all seg fault. > In the newer gdb, what'll happen is you'll get no segfault, but a weird number > returned, which will actually the address of the function, which is > the last value we have around, i guess. Have you actually tried this or are you supposing? Where can I get the "newer" gdb? What version is the "newer" gdb? -- DavidC