From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: jimb@cygnus.com Cc: eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com Subject: Re: RFA: minor watchpoint code cleanup Date: Tue, 21 Mar 2000 15:57:00 -0000 Message-ID: <200003212357.e2LNvIq05590@delius.kettenis.local> References: <200003180006.TAA26919@zwingli.cygnus.com> <200003190944.EAA07454@indy.delorie.com> <200003192255.e2JMtcs00643@delius.kettenis.local> <200003200958.EAA09356@indy.delorie.com> <200003211817.NAA12429@indy.delorie.com> X-SW-Source: 2000-03/msg00450.html Message-ID: <20000321155700.pE-c5uOaSXGeAS21HQE4HwjcDJbgZkmr1b6NbPUrW94@z> From: Jim Blandy Date: 21 Mar 2000 18:33:30 -0500 > The reason is that IMHO we should avoid making a variable (`size') > serve two puproses at the same time. Good suggestion --- done. I'm just waiting for Mark's approval. Approved. Mark >From ac131313@cygnus.com Tue Mar 21 15:58:00 2000 From: Andrew Cagney To: GDB Discussion , GDB Patches Subject: [MAINT] More additions Date: Tue, 21 Mar 2000 15:58:00 -0000 Message-id: <38D80C7E.BF2217E8@cygnus.com> X-SW-Source: 2000-03/msg00451.html Content-length: 537 Hello, Michael and Jim are going to share breakpoint code between themselves: breakpoint.c Michael Snyder msnyder@cygnus.com Jim Blandy jimb@cygnus.com Jonathan Larmour's just managed to exceed his quota of good patch submissions :-). He's happy to join the write aver approval list: Jonathan Larmour jlarmour@redhat.co.uk David has stepped forward as the SPARC/Solaris and target maintainer: sparc target David Taylor taylor@cygnus.com Solaris/SPARC native & host David Taylor taylor@cygnus.com enjoy, Andrew >From ac131313@cygnus.com Tue Mar 21 16:10:00 2000 From: Andrew Cagney To: Daniel Berlin Cc: jtc@redback.com, gdb-patches@sourceware.cygnus.com Subject: Re: RFA: i386/nbsd.mt, i386nbsd-nat.c Date: Tue, 21 Mar 2000 16:10:00 -0000 Message-id: <38D80F23.799B5F41@cygnus.com> References: X-SW-Source: 2000-03/msg00452.html Content-length: 516 Daniel Berlin wrote: > > Actually, i have patches to make FreeBSD build native just fine. > I merged the patches freebsd uses against 4.18 into the current gdb. > It fails some shared lib tests, but past that, it's fine. > I can submit them if you like. The problem I have with the FreeBSD patches is that they have never been assigned to the FSF by the original author. I'd have otherwize done the same thing (they are also pretty scrappy) :-( Many of the NetBSD changes have the same problem. sorry, Andrew >From shebs@apple.com Tue Mar 21 17:48:00 2000 From: Stan Shebs To: Andrew Cagney Cc: Michael Snyder , gdb-patches@sourceware.cygnus.com Subject: Re: gdb.texinfo broken? Date: Tue, 21 Mar 2000 17:48:00 -0000 Message-id: <38D82684.89633B0B@apple.com> References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com> <38D7C977.FA3@cygnus.com> <5mitygglxs.fsf@jtc.redbacknetworks.com> <38D7FDD1.D54DE1D8@cygnus.com> X-SW-Source: 2000-03/msg00453.html Content-length: 483 Andrew Cagney wrote: > > "J.T. Conklin" wrote: > > > It looks like the changes to the directory entry require the latest > > makeinfo. I tried to use makeinfo from texinfo-3.2 and it failed, > > makeinfo from texinfo-4.0 works. > > >From memory, the possibility of requiring texinfo 4.0 as part of > building GDB 5 was considered and rejected :-( Yeah, I have to revert - tried it on one of Apple's MkLinux systems, which claims to have texinfo 3.9, and it fell down too. Stan >From jtc@redback.com Tue Mar 21 19:07:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb-patches@sourceware.cygnus.com Subject: RFA: call-ar-st.exp, relax patterns Date: Tue, 21 Mar 2000 19:07:00 -0000 Message-id: <5mog87g0sx.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-03/msg00454.html Content-length: 8945 I submit the enclosed patch for approval. As I mentioned some months ago ( http://sourceware.cygnus.com/ml/gdb/1999-q3/msg00162.html ), the default pty attributes on NetBSD systems has tabs expanding to spaces but some of the tests explicitly check for tabs. I fixed some of the tests then, but didn't have time to go through all of the failures. This change relaxes more of expect patterns in call-ar-st.exp. --jtc 2000-03-21 J.T. Conklin * gdb.base/call-ar-st.exp: relax patterns matching tab characters. Index: call-ar-st.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.base/call-ar-st.exp,v retrieving revision 1.1.1.7 diff -c -3 -p -r1.1.1.7 call-ar-st.exp *** call-ar-st.exp 1999/08/23 22:37:37 1.1.1.7 --- call-ar-st.exp 2000/03/22 02:59:09 *************** gdb_expect { *** 366,372 **** if {![target_info exists gdb,skip_float_tests]} { send_gdb "print print_small_structs(*struct1, *struct2, *struct3, *struct4, *flags, *flags_combo, *three_char, *five_char, *int_char_combo, *d1, *d2, *d3, *f1, *f2, *f3)\n" gdb_expect { ! -re ".*alpha\[\t\r\n \]+gamma\[\t\r\n \]+epsilon\[\t\r\n \]+alpha\[\t\r\n \]+gamma\[\t\r\n \]+epsilon\[\t\r\n \]+ch1: y\tch2: n\[\t\r\n \]+Contents of three_char_t:\[\t\r\n \]+a\tb\tc\[\t\r\n \]+Contents of five_char_t:\[\t\r\n \]+l\tm\tn\to\tp\[\t\r\n \]+Contents of int_char_combo_t:\[\t\r\n \]+123.*z\[\t\r\n \]+Sum of the 4 struct values and seed :\[\t\r\n \]+52\[\t\r\n \]+Contents of struct1:\[\t\r\n \]+6.*0\[\t\r\n \]+Contents of struct2:\[\t\r\n \]+10.*0\[\t\r\n \]+Contents of struct3:\[\t\r\n \]+12.*0\[\t\r\n \]+Contents of one_double_t:\[\t\r\n \]+10.500000\[\t\r\n \]+Contents of one_double_t:.*-3.340000\[\t\r\n \]+Contents of one_double_t:.*675.091230\[\t\r\n \]+Contents of two_floats_t:.*45.234001.*43.599998\[\t\r\n \]+Contents of two_floats_t:.*78.010002.*122.099998\[\t\r\n \]+Contents of two_floats_t:.*-1232.344971.*-199.210007\[\t\r\n \]+.*$gdb_prompt $" { pass "print print_small_structs" } -re ".*$gdb_prompt $" { fail "print print_small_structs" } --- 366,372 ---- if {![target_info exists gdb,skip_float_tests]} { send_gdb "print print_small_structs(*struct1, *struct2, *struct3, *struct4, *flags, *flags_combo, *three_char, *five_char, *int_char_combo, *d1, *d2, *d3, *f1, *f2, *f3)\n" gdb_expect { ! -re ".*alpha\[\t\r\n \]+gamma\[\t\r\n \]+epsilon\[\t\r\n \]+alpha\[\t\r\n \]+gamma\[\t\r\n \]+epsilon\[\t\r\n \]+ch1: y.*ch2: n\[\t\r\n \]+Contents of three_char_t:\[\t\r\n \]+a.*b.*c\[\t\r\n \]+Contents of five_char_t:\[\t\r\n \]+l.*m.*n.*o.*p\[\t\r\n \]+Contents of int_char_combo_t:\[\t\r\n \]+123.*z\[\t\r\n \]+Sum of the 4 struct values and seed :\[\t\r\n \]+52\[\t\r\n \]+Contents of struct1:\[\t\r\n \]+6.*0\[\t\r\n \]+Contents of struct2:\[\t\r\n \]+10.*0\[\t\r\n \]+Contents of struct3:\[\t\r\n \]+12.*0\[\t\r\n \]+Contents of one_double_t:\[\t\r\n \]+10.500000\[\t\r\n \]+Contents of one_double_t:.*-3.340000\[\t\r\n \]+Contents of one_double_t:.*675.091230\[\t\r\n \]+Contents of two_floats_t:.*45.234001.*43.599998\[\t\r\n \]+Contents of two_floats_t:.*78.010002.*122.099998\[\t\r\n \]+Contents of two_floats_t:.*-1232.344971.*-199.210007\[\t\r\n \]+.*$gdb_prompt $" { pass "print print_small_structs" } -re ".*$gdb_prompt $" { fail "print print_small_structs" } *************** if {![target_info exists gdb,skip_float_ *** 461,467 **** setup_xfail "sparc*-*-solaris*" send_gdb "print print_small_structs(struct1, struct2, struct3, struct4, flags, flags_combo, three_char, five_char, int_char_combo, d1, d2, d3, f1, f2, f3)\n" gdb_expect { ! -re ".*alpha${ws}gamma${ws}epsilon${ws}alpha${ws}gamma${ws}epsilon${ws}ch1: y\tch2: n${ws}Contents of three_char_t:${ws}a\tb\tc${ws}Contents of five_char_t:${ws}l\tm\tn\to\tp${ws}Contents of int_char_combo_t:${ws}123.*z${ws}Sum of the 4 struct values and seed :${ws}52${ws}Contents of struct1:${ws}6.*0${ws}Contents of struct2:${ws}10.*0${ws}Contents of struct3:${ws}12.*0${ws}Contents of one_double_t:${ws}10.500000${ws}Contents of one_double_t:${ws}-3.340000${ws}Contents of one_double_t:${ws}675.091230${ws}Contents of two_floats_t:${ws}45.234001.*43.599998${ws}Contents of two_floats_t:${ws}78.010002.*122.099998${ws}Contents of two_floats_t:${ws}-1232.344971.*-199.210007${ws}.*$gdb_prompt $" { pass "print print_small_structs from print_long_arg_list" } -re ".*$gdb_prompt $" { fail "print print_small_structs from print_long_arg_list" } --- 461,467 ---- setup_xfail "sparc*-*-solaris*" send_gdb "print print_small_structs(struct1, struct2, struct3, struct4, flags, flags_combo, three_char, five_char, int_char_combo, d1, d2, d3, f1, f2, f3)\n" gdb_expect { ! -re ".*alpha${ws}gamma${ws}epsilon${ws}alpha${ws}gamma${ws}epsilon${ws}ch1: y.*ch2: n${ws}Contents of three_char_t:${ws}a.*b.*c${ws}Contents of five_char_t:${ws}l.*m.*n.*o.*p${ws}Contents of int_char_combo_t:${ws}123.*z${ws}Sum of the 4 struct values and seed :${ws}52${ws}Contents of struct1:${ws}6.*0${ws}Contents of struct2:${ws}10.*0${ws}Contents of struct3:${ws}12.*0${ws}Contents of one_double_t:${ws}10.500000${ws}Contents of one_double_t:${ws}-3.340000${ws}Contents of one_double_t:${ws}675.091230${ws}Contents of two_floats_t:${ws}45.234001.*43.599998${ws}Contents of two_floats_t:${ws}78.010002.*122.099998${ws}Contents of two_floats_t:${ws}-1232.344971.*-199.210007${ws}.*$gdb_prompt $" { pass "print print_small_structs from print_long_arg_list" } -re ".*$gdb_prompt $" { fail "print print_small_structs from print_long_arg_list" } *************** init_bit_flags_combo \\(bit_flags_combo= *** 491,497 **** #call print_bit_flags_combo(*bit_flags_combo) send_gdb "print print_bit_flags_combo(*bit_flags_combo)\n" gdb_expect { ! -re ".*alpha.*gamma.*epsilon.*ch1: y\tch2: n.*$gdb_prompt $" { pass "print print_bit_flags_combo from init_bit_flags_combo" } -re ".*$gdb_prompt $" { fail "print print_bit_flags_combo from init_bit_flags_combo" } --- 491,497 ---- #call print_bit_flags_combo(*bit_flags_combo) send_gdb "print print_bit_flags_combo(*bit_flags_combo)\n" gdb_expect { ! -re ".*alpha.*gamma.*epsilon.*ch1: y.*ch2: n.*$gdb_prompt $" { pass "print print_bit_flags_combo from init_bit_flags_combo" } -re ".*$gdb_prompt $" { fail "print print_bit_flags_combo from init_bit_flags_combo" } *************** if {$hp_aCC_compiler} {setup_xfail "hppa *** 518,524 **** if {![target_info exists gdb,skip_float_tests]} { send_gdb "print print_long_arg_list(a, b, c, d, e, f, *struct1, *struct2, *struct3, *struct4, *flags, *flags_combo, *three_char, *five_char, *int_char_combo, *d1, *d2, *d3, *f1, *f2, *f3)\n" gdb_expect { ! -re ".*double : 22.220000.*double : 33.333000.*int : 0.*int : -25.*int : 100.*int : 2345.*alpha.*gamma.*epsilon.*ch1: y\tch2: n.*Contents of three_char_t:.*x\ty\tz.*Contents of five_char_t:.*h\te\tl\tl\to.*Contents of int_char_combo_t:.*123\tz.*Sum of the 4 struct values and seed :.*52.*Contents of struct1:.*6\[ \]+0.*Contents of struct2:.*10\[ \]+0.*Contents of struct3:.*12.*0.*Contents of one_double_t:\[ \n\r\t\]+1.111110\[ \n\r\t\]+Contents of one_double_t:\[ \n\r\t\]+-345.340000\[ \n\r\t\]+Contents of one_double_t:\[ \n\r\t\]+546464.200000\[ \n\r\t\]+Contents of two_floats_t:\[ \n\r\t\]+0.234000\t453.100006\[ \n\r\t\]+Contents of two_floats_t:\[ \n\r\t\]+78.345001\t23.090000\[ \n\r\t\]+Contents of two_floats_t:\[ \n\r\t\]+-2.345000\t1.000000.*$gdb_prompt $" { pass "print print_long_arg_list" } -re ".*$gdb_prompt $" { fail "print print_long_arg_list" } --- 518,524 ---- if {![target_info exists gdb,skip_float_tests]} { send_gdb "print print_long_arg_list(a, b, c, d, e, f, *struct1, *struct2, *struct3, *struct4, *flags, *flags_combo, *three_char, *five_char, *int_char_combo, *d1, *d2, *d3, *f1, *f2, *f3)\n" gdb_expect { ! -re ".*double : 22.220000.*double : 33.333000.*int : 0.*int : -25.*int : 100.*int : 2345.*alpha.*gamma.*epsilon.*ch1: y.*ch2: n.*Contents of three_char_t:.*x.*y.*z.*Contents of five_char_t:.*h.*e.*l.*l.*o.*Contents of int_char_combo_t:.*123.*z.*Sum of the 4 struct values and seed :.*52.*Contents of struct1:.*6\[ \]+0.*Contents of struct2:.*10\[ \]+0.*Contents of struct3:.*12.*0.*Contents of one_double_t:\[ \n\r\t\]+1.111110\[ \n\r\t\]+Contents of one_double_t:\[ \n\r\t\]+-345.340000\[ \n\r\t\]+Contents of one_double_t:\[ \n\r\t\]+546464.200000\[ \n\r\t\]+Contents of two_floats_t:\[ \n\r\t\]+0.234000.*453.100006\[ \n\r\t\]+Contents of two_floats_t:\[ \n\r\t\]+78.345001.*23.090000\[ \n\r\t\]+Contents of two_floats_t:\[ \n\r\t\]+-2.345000.*1.000000.*$gdb_prompt $" { pass "print print_long_arg_list" } -re ".*$gdb_prompt $" { fail "print print_long_arg_list" } -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Tue Mar 21 20:21:00 2000 From: Andrew Cagney To: Jimmy Guo Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Initialization of hpux_threads Date: Tue, 21 Mar 2000 20:21:00 -0000 Message-id: <38D849A1.F5F706A@cygnus.com> References: X-SW-Source: 2000-03/msg00455.html Content-length: 1125 Jimmy Guo wrote: > > I was looking at an old source tree and didn't see its 'revival'. > Yes it is some setup to solve the kinds of problem you mentioned. > But any other usage of it will only introduce multiple calls to > a _initialize_* routine. > > The initializer in hpux-thread.c is just one of these cases. They're > mostly fixed as of today's tree except for a remaining one - > remote-nrom.c. Thanks, I've applied the attatched. Andrew Wed Mar 22 15:09:34 2000 Andrew Cagney * configure.in (CONFIG_INITS): Do not append remote-nrom.c Index: configure.in =================================================================== RCS file: /cvs/src/src/gdb/configure.in,v retrieving revision 1.12 diff -p -r1.12 configure.in *** configure.in 2000/03/20 06:41:24 1.12 --- configure.in 2000/03/22 04:15:36 *************** esac]) *** 447,453 **** if test "${enable_netrom}" = "yes"; then CONFIG_OBS="${CONFIG_OBS} remote-nrom.o" CONFIG_SRCS="${CONFIG_SRCS} remote-nrom.c" - CONFIG_INITS="${CONFIG_INITS} remote-nrom.c" fi AC_ARG_ENABLE(build-warnings, --- 447,452 ---- >From ac131313@cygnus.com Tue Mar 21 20:25:00 2000 From: Andrew Cagney To: GDB Patches Cc: GDB Discussion Subject: [Maint] Second testsuite maintainer Date: Tue, 21 Mar 2000 20:25:00 -0000 Message-id: <38D84B37.B90E15AB@cygnus.com> X-SW-Source: 2000-03/msg00456.html Content-length: 282 Another addition: Add Fernando to list of testsuite maintainers. testsuite Stan Shebs shebs@apple.com Fernando Nasser fnasser@cygnus.com hp tests (gdb.hp) *Jimmy Guo adl-debugger-wdb-merge-guru@cup.hp.com Java tests (gdb.java) Anthony Green green@cygnus.com Andrew >From ac131313@cygnus.com Tue Mar 21 21:38:00 2000 From: Andrew Cagney To: Michael Snyder Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Document the ThreadInfo remote protocol queries Date: Tue, 21 Mar 2000 21:38:00 -0000 Message-id: <38D85C2F.FF89881D@cygnus.com> References: <200003202316.PAA07888@cleaver.cygnus.com> <38D6FCE2.EBD9830F@cygnus.com> <38D7C38C.6CB0@cygnus.com> X-SW-Source: 2000-03/msg00457.html Content-length: 2117 Michael Snyder wrote: > > An additional note on these versions of thread queries. While > > significantly better than the ``qL'' packet these commands still have > > problems. I'll add notes expanding on this. Briefly, however: > > > > o Per the query packet spec, they should be > > prefixed with a UCASE letter if they > > are to be official GDB packets. > > > > o The ``sThread..'' command assumes > > that the GDB protocol is reliable > > which it is not. GDB can re-issue > > a ``sThread'' request and this can > > lead to GDB and the target falling > > out of sync. > > How about if the 'sThread' request were to be suffixed with > the last thread ID received? I was thinking of deprecating fThreadInfo and sThreadInfo and having gdb try: qThreadInfo qThreadInfo, Where sentinal could be index (counting from zero) for next threads, or anything else. Given ``sThreadInfo'' is in the field, we can't change it. > > with regard to ``qfThreadExtraInfo''. As far as I know its not been > > deployed in the field. Is there any reason to not name it correctly > > from the start (``qThreadExtraInfo'')? > > Only that it conflicts with the tracepoint messages, > which all begin with qT (see tracepoint.c). I don't think that is a problem. The protocol requires: @tab @code{q}@var{query} @tab Request info about @var{query}. In general @value{GDBN} @var{query}'s have a leading upper case letter. Custom vendor queries should use a company prefix (in lower case) ex: @samp{qfsf.var}. @var{query} may optionally be followed by a @samp{,} or @samp{;} separated list. Stubs must ensure that they match the full @var{query} name. The last sentence is ment to ensure that the target's query handling code matches using something like: strcmp (packet, "qThreadInfo") instead of packet[0] == 'q' && packet[1] == 'T' && packet[7] == 'I' Should ``C'' also be suceeded by something like ``qThread''? Is ``C'' still used? Andrew >From eliz@delorie.com Wed Mar 22 00:58:00 2000 From: Eli Zaretskii To: Andrew Cagney Cc: Mark Kettenis , gdb-patches@sourceware.cygnus.com Subject: Re: Linux sigtramp detection code moved to its proper place Date: Wed, 22 Mar 2000 00:58:00 -0000 Message-id: <200003220858.DAA12990@indy.delorie.com> References: <200003201529.KAA10589@indy.delorie.com> <38D73C78.4B2B3562@cygnus.com> X-SW-Source: 2000-03/msg00458.html Content-length: 2641 > Is there anything that the nightly snapshots (short term) and/or > testsuite (medium/long term) can do to ensure that the relevant > djgpp files are always up-to-date? As a matter of fact, there is. I have todo items for the following issues: - The file config/djgpp/fnchange.lst needs to be updated to include the exact version in the file names it maps. Specifically, that file consists of lines which look like this: gdb-0321/foo/bar/long-name-foo.c gdb-0321/foo/bar/short-foo.c (When DJTAR sees this line, it renames the file whose name is on the left to what's on the right.) The "gdb-0312" part should be replaced with the actual name of the directory which the distribution creates when unpacked, and that name includes the version of the snapshot/release. What I was thinking was to provide a template whose lines will say this: gdb-@VER@/foo/bar/long-name-foo.c gdb-@VER@/foo/bar/short-foo.c and run Sed on it inside the commands used to tar the distribution, to replace that with the actual version (taken from the Makefile, for example). - If the long names which clash after 8+3 truncation are to stay with us for Quite A While (tm), it might make sense to have some script or program that will update fnchange.lst whenever a new file is added that clashes with some other file name, but is not yet covered in fnchange.lst. Assuming that the files which get added are not required for the DJGPP build (since those must *never* clash with other file names), what we need is to add an entry like this: gdb-@VER@/foo/bar/new-long-name-foo.bar When DJTAR sees such a line, it skips the named file. This looks like a job for a Perl script. Unfortunately, Perl for me is a read-only language. I could write a C program to do this, if this is acceptable, though. Comments and ideas are welcome. > As a suggestion from left field, I've wondered if gdb.base/selftest.exp > should be moved to gdb.wb/selftest.exp (wb == white box) so that people > can freely add additional white box tests to GDB. Checking consistency > between config/djgpp/ and the GDB sources could be part of > that testsuite. Does that mean that you always run the test suite before preparing the snapshots? If so, how do you know whether a certain new failure is grave enough to prevent you from making the snapshot? I mean, if the test for consistency in config/djgpp/ were added, and it failed, how would you know that this is not some minor regression (which I assume do happen in other parts of GDB)? >From eliz@delorie.com Wed Mar 22 01:30:00 2000 From: Eli Zaretskii To: msnyder@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Running the inferior from breakpoint commands Date: Wed, 22 Mar 2000 01:30:00 -0000 Message-id: <200003220930.EAA13024@indy.delorie.com> References: <200003120759.CAA24402@indy.delorie.com> <200003151624.LAA01228@indy.delorie.com> <38D7F31D.1827@cygnus.com> X-SW-Source: 2000-03/msg00459.html Content-length: 2020 > Any > other commands in the command list are ignored, after > a command that resumes execution. > > Note the last sentence. So despite the fact that the > testsuite seems to imply that this should work, it is > not expected to. I have no idea what that test is > doing in there. The commands-on-breakpoint behavior > is NOT intended to be recursive. Yes, somebody already pointed out that this appears to be a documented limitation. Unfortunately, this info came after I already did the changes and posted them; my original question when I first discovered the problem remained unanswered... (I did look in the manual, but since the snippet you cited isn't indexed, I didn't find it. [Yes, I will submit a manual change to add an index entry.]) To me, the fact that the test suite tried to do this was a sign that it was supposed to work. As an aside: is there any place I can find the list of tests which fail, and on what systems do they fail? > If you seriously want to undertake this project, we can > work on a list of criteria that should be tested (things > that can go wrong). I will put it on my todo (thanks for the list of things to test; some of them were already tested, I just didn't report it). I would like at least to probe the issues, to get a feeling how badly broken is what I did ;-). > On top of that, I have grave concerns about being able > to correctly save and restore all of the internal > debugger state necessary to make this work (the > infrun execution state, the expression chain, etc.) Err... I'm not sure this should be of concern here (but perhaps I don't see the subtle issues clearly enough): if the breakpoint commands change any of these global entities, I think the user expects the changes to be visible after these commands are processed. For example, if the commands delete the breakpoint where you stopped, the user will expect the breakpoint to remain deleted after that (the changes I submitted do handle this specific case). Am I missing something? >From kettenis@wins.uva.nl Wed Mar 22 01:49:00 2000 From: Mark Kettenis To: gdb-patches@sourceware.cygnus.com Cc: jtc@redback.com Subject: [PATCH] Restructuring i386-tdep.c:i386_extract_return_value() Date: Wed, 22 Mar 2000 01:49:00 -0000 Message-id: <200003220949.e2M9nl001746@delius.kettenis.local> X-SW-Source: 2000-03/msg00460.html Content-length: 6153 Hi, I checked in the attached patch. This is one of the patches I discussed two weeks ago, which makes i386_extract_return_value() do the right thing for most of the supported i386 targets. Some targets (for example those that use tm-i386v.h) still redefine EXTRACT_RETURN_VALUE, so they don't take advantage of this improvement. I'll deal with that later. Mark 2000-03-22 Mark Kettenis * config/i386/tm-i386aix.h (I386_AIX_TARGET): Remove. * config/i386/tm-linux.h (LOW_RETURN_REGNUM, HIGH_RETURN_REGNUM): Remove * i386-tdep.c (LOW_RETURN_REGNUM, HIGH_RETURN_REGNUM): New defines. (i386_extract_return_value): Rewritten. Correctly support all floating-point types and large integer types on targets that use the standard i386 GDB register layout and return floating-point values in the FPU. Index: config/i386/tm-i386aix.h =================================================================== RCS file: /cvs/src/src/gdb/config/i386/tm-i386aix.h,v retrieving revision 1.2 diff -u -p -r1.2 tm-i386aix.h --- config/i386/tm-i386aix.h 2000/03/02 15:44:27 1.2 +++ config/i386/tm-i386aix.h 2000/03/22 09:41:10 @@ -30,14 +30,6 @@ #define I386 1 #endif -/* FIXME: kettenis/2000-03-02: This is used in - i386-tdep.c:i386_extract_return_value(), and will be remove once - I've fixed that. Meanwhile don't use it for any other purpose - please! */ -#ifndef I386_AIX_TARGET -#define I386_AIX_TARGET 1 -#endif - /* AIX/i386 has FPU support. However, the native configuration (which is the only supported configuration) doesn't make the FPU control registers available. Override the appropriate symbols such that Index: config/i386/tm-linux.h =================================================================== RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v retrieving revision 1.4 diff -u -p -r1.4 tm-linux.h --- config/i386/tm-linux.h 2000/03/16 22:46:30 1.4 +++ config/i386/tm-linux.h 2000/03/22 09:41:10 @@ -30,9 +30,6 @@ #include "i386/tm-i386.h" #include "tm-linux.h" -#define LOW_RETURN_REGNUM 0 /* holds low four bytes of result */ -#define HIGH_RETURN_REGNUM 2 /* holds high four bytes of result */ - /* This should probably move to tm-i386.h. */ #define TARGET_LONG_DOUBLE_BIT 80 Index: i386-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/i386-tdep.c,v retrieving revision 1.7 diff -u -p -r1.7 i386-tdep.c --- i386-tdep.c 2000/03/16 22:46:26 1.7 +++ i386-tdep.c 2000/03/22 09:41:10 @@ -698,56 +698,66 @@ get_longjmp_target (pc) #endif /* GET_LONGJMP_TARGET */ +/* These registers are used for returning integers (and on some + targets also for returning `struct' and `union' values when their + size and alignment match an integer type. */ +#define LOW_RETURN_REGNUM 0 /* %eax */ +#define HIGH_RETURN_REGNUM 2 /* %edx */ + +/* Extract from an array REGBUF containing the (raw) register state, a + function return value of TYPE, and copy that, in virtual format, + into VALBUF. */ + void -i386_extract_return_value (type, regbuf, valbuf) - struct type *type; - char regbuf[REGISTER_BYTES]; - char *valbuf; +i386_extract_return_value (struct type *type, char *regbuf, char *valbuf) { - /* On AIX, i386 GNU/Linux and DJGPP, floating point values are - returned in floating point registers. */ - /* FIXME: cagney/2000-02-29: This function needs to be rewritten - using multi-arch. Please don't keep adding to this #ifdef - spaghetti. */ -#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET) || defined(I386_DJGPP_TARGET) + int len = TYPE_LENGTH (type); + if (TYPE_CODE_FLT == TYPE_CODE (type)) { - double d; - /* 387 %st(0), gcc uses this */ - floatformat_to_double (&floatformat_i387_ext, -#if defined(FPDATA_REGNUM) - ®buf[REGISTER_BYTE (FPDATA_REGNUM)], -#else /* !FPDATA_REGNUM */ - ®buf[REGISTER_BYTE (FP0_REGNUM)], -#endif /* FPDATA_REGNUM */ + if (NUM_FREGS == 0) + { + warning ("Cannot find floating-point return value."); + memset (valbuf, 0, len); + } - &d); - store_floating (valbuf, TYPE_LENGTH (type), d); + /* Floating-point return values can be found in %st(0). */ + if (len == TARGET_LONG_DOUBLE_BIT / TARGET_CHAR_BIT + && TARGET_LONG_DOUBLE_FORMAT == &floatformat_i387_ext) + { + /* Copy straight over, but take care of the padding. */ + memcpy (valbuf, ®buf[REGISTER_BYTE (FP0_REGNUM)], + FPU_REG_RAW_SIZE); + memset (valbuf + FPU_REG_RAW_SIZE, 0, len - FPU_REG_RAW_SIZE); + } + else + { + /* Convert the extended floating-point number found in + %st(0) to the desired type. This is probably not exactly + how it would happen on the target itself, but it is the + best we can do. */ + DOUBLEST val; + floatformat_to_doublest (&floatformat_i387_ext, + ®buf[REGISTER_BYTE (FP0_REGNUM)], &val); + store_floating (valbuf, TYPE_LENGTH (type), val); + } } else -#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET || I386_DJGPP_TARGET */ { -#if defined(LOW_RETURN_REGNUM) - int len = TYPE_LENGTH (type); int low_size = REGISTER_RAW_SIZE (LOW_RETURN_REGNUM); int high_size = REGISTER_RAW_SIZE (HIGH_RETURN_REGNUM); if (len <= low_size) - memcpy (valbuf, regbuf + REGISTER_BYTE (LOW_RETURN_REGNUM), len); + memcpy (valbuf, ®buf[REGISTER_BYTE (LOW_RETURN_REGNUM)], len); else if (len <= (low_size + high_size)) { memcpy (valbuf, - regbuf + REGISTER_BYTE (LOW_RETURN_REGNUM), - low_size); + ®buf[REGISTER_BYTE (LOW_RETURN_REGNUM)], low_size); memcpy (valbuf + low_size, - regbuf + REGISTER_BYTE (HIGH_RETURN_REGNUM), - len - low_size); + ®buf[REGISTER_BYTE (HIGH_RETURN_REGNUM)], len - low_size); } else - error ("GDB bug: i386-tdep.c (i386_extract_return_value): Don't know how to find a return value %d bytes long", len); -#else /* !LOW_RETURN_REGNUM */ - memcpy (valbuf, regbuf, TYPE_LENGTH (type)); -#endif /* LOW_RETURN_REGNUM */ + internal_error ("Cannot extract return value of %d bytes long.", len); } } >From eliz@delorie.com Wed Mar 22 02:32:00 2000 From: Eli Zaretskii To: jtc@redback.com Cc: msnyder@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: gdb.texinfo broken? Date: Wed, 22 Mar 2000 02:32:00 -0000 Message-id: <200003221032.FAA13070@indy.delorie.com> References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com> <38D7C977.FA3@cygnus.com> <5mitygglxs.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-03/msg00461.html Content-length: 488 > It looks like the changes to the directory entry require the latest > makeinfo. I tried to use makeinfo from texinfo-3.2 and it failed, > makeinfo from texinfo-4.0 works. What directory entry? If you mean @direntry and @dircategory, then they were introduced in Texinfo 3.8, so they are not the problem. I have several old versions of Texinfo on my machine, so will look into these problems ASAP (since it might be my fault: the error messages mention some of the lines I changed). >From ac131313@cygnus.com Wed Mar 22 03:23:00 2000 From: Andrew Cagney To: Eli Zaretskii Cc: Mark Kettenis , gdb-patches@sourceware.cygnus.com Subject: Re: Linux sigtramp detection code moved to its proper place Date: Wed, 22 Mar 2000 03:23:00 -0000 Message-id: <38D8ACDE.DA82F9E6@cygnus.com> References: <200003201529.KAA10589@indy.delorie.com> <38D73C78.4B2B3562@cygnus.com> <200003220858.DAA12990@indy.delorie.com> X-SW-Source: 2000-03/msg00462.html Content-length: 1013 Eli Zaretskii wrote: > > As a suggestion from left field, I've wondered if gdb.base/selftest.exp > > should be moved to gdb.wb/selftest.exp (wb == white box) so that people > > can freely add additional white box tests to GDB. Checking consistency > > between config/djgpp/ and the GDB sources could be part of > > that testsuite. > > Does that mean that you always run the test suite before preparing the > snapshots? If so, how do you know whether a certain new failure is > grave enough to prevent you from making the snapshot? I mean, if the > test for consistency in config/djgpp/ were added, and it > failed, how would you know that this is not some minor regression > (which I assume do happen in other parts of GDB)? No a snapshot is just that. No guarentee that it will even build :-/ The reason for suggesting a check in the testsuite was that someone adding a new file would hopefully run the testsuite after adding their badly named file and notice the failure. Andrew >From fnasser@redhat.com Wed Mar 22 05:09:00 2000 From: Fernando Nasser To: GDB Patches Subject: Re: [Maint] Second testsuite maintainer Date: Wed, 22 Mar 2000 05:09:00 -0000 Message-id: <38D8C5BA.20C4B77@redhat.com> References: <38D84B37.B90E15AB@cygnus.com> X-SW-Source: 2000-03/msg00463.html Content-length: 772 Are you still going from the backlog from the Linux conference? :-) Ben said it was OK and that he met the RedHat mkting people from the North of Australia... Andrew Cagney wrote: > > Another addition: > > Add Fernando to list of testsuite maintainers. > > testsuite Stan Shebs shebs@apple.com > Fernando Nasser fnasser@cygnus.com > hp tests (gdb.hp) *Jimmy Guo adl-debugger-wdb-merge-guru@cup.hp.com > Java tests (gdb.java) Anthony Green green@cygnus.com > > Andrew -- Fernando Nasser Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From fnasser@redhat.com Wed Mar 22 05:11:00 2000 From: Fernando Nasser To: GDB Patches Subject: Re: [Maint] Second testsuite maintainer Date: Wed, 22 Mar 2000 05:11:00 -0000 Message-id: <38D8C648.3FE00B1C@redhat.com> References: <38D84B37.B90E15AB@cygnus.com> <38D8C5BA.20C4B77@redhat.com> X-SW-Source: 2000-03/msg00464.html Content-length: 307 Sorry folks. That was a personal message and I pressed the wrong button by mistake. :-( -- Fernando Nasser Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From eliz@delorie.com Wed Mar 22 08:55:00 2000 From: Eli Zaretskii To: Michael Snyder Cc: jtc@redback.com (J.T. Conklin), gdb-patches@sourceware.cygnus.com Subject: Re: gdb.texinfo broken? Date: Wed, 22 Mar 2000 08:55:00 -0000 Message-id: <200003221655.LAA14175@indy.delorie.com> References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com> <5mitygglxs.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-03/msg00465.html Content-length: 4870 < 38D7C977.FA3@cygnus.com > < 5mitygglxs.fsf@jtc.redbacknetworks.com > > >>>>> "Michael" == Michael Snyder writes: > Michael> %] msnyder<2>% make gdb.info > Michael> makeinfo -I > Michael> /cleaver/blade/msnyder/sourceware/src/gdb/doc/../../readline/doc -I > Michael> /cleaver/blade/msnyder/sourceware/src/gdb/doc -o ./gdb.info gdb.texinfo > Michael> Making info file `./gdb.info' from `gdb.texinfo'. > Michael> gdb.texinfo:113: No matching `@end ifnottex'. > Michael> gdb.texinfo:156: Unmatched `@end'. > > It looks like the changes to the directory entry require the latest > makeinfo. I tried to use makeinfo from texinfo-3.2 and it failed, > makeinfo from texinfo-4.0 works. Okay, I think I know what's going on with gdb.texinfo and old versions of Texinfo. First, I'm guessing that Michael Snyder didn't "cvs up annotate.texi". The old version was written as a separate manual, so it had its own Top node etc. The new gdb.texinfo @include's annotate.texi, so Michael gets error messages about multiple Top nodes etc.. When I introduced the changes into gdb.texinfo to include the Annotations chapter, I changed annotate.texi accordingly, to avoid all these problems. This leaves us with two error messages cited above: gdb.texinfo:113: No matching `@end ifnottex'. gdb.texinfo:156: Unmatched `@end'. These come from Texinfo 3.11 and later (I tried 3.12; I don't have 3.11 on my disk), which is where @ifnottex was introduced. Texinfo 3.9 and earlier doesn't grok @ifnottex at all, and Texinfo 4.0 converts the file without any problems. The problem with @ifnottex in Texinfo 3.12 are actually a bug/misfeature in that version: conditionals such as @ifnottex cannot span node boundaries. Here's a ChangeLog entry from the latest Texinfo distribution: Sun Nov 29 17:12:35 1998 Karl Berry [...] * makeinfo/insertion.c (discard_insertions): Let any conditional cross node boundary. (So the @top node can be wrapped in @ifnottex, for example.) This was done during the (long) pretest of Texinfo 4.0. Since we decided not to depend on Texinfo 4.0, it seems we have 2 alternatives: - Toss @ifnottex and go back to using @ifinfo. This will disallow producing the manual in the HTML format (only possible with Texinfo 4.0). - Duplicate the offending Top node, once wrapped with @ifinfo, the other time wrapped with @ifhtml. This works for me with Texinfo 3.12 and 4.0. The patch for this alternative is below. I recommend to use the second alternative, even though it's kludgey. Note that if we use @ifnottex, we need to require Texinfo 3.11 or later; Texinfo 3.9 will not work. --- gdb/doc/gdb.t~2 Wed Mar 22 12:49:54 2000 +++ gdb/doc/gdb.texinfo Wed Mar 22 18:02:48 2000 @@ -110,7 +110,7 @@ @end titlepage @page -@ifnottex +@ifinfo @node Top @top Debugging with @value{GDBN} @@ -153,7 +153,52 @@ * Index:: Index @end menu -@end ifnottex +@end ifinfo + +@ifhtml +@node Top +@top Debugging with @value{GDBN} + +This file describes @value{GDBN}, the @sc{gnu} symbolic debugger. + +This is the @value{EDITION} Edition, @value{DATE}, for @value{GDBN} Version +@value{GDBVN}. + +Copyright (C) 1988-1999 Free Software Foundation, Inc. +@menu +* Summary:: Summary of @value{GDBN} +* Sample Session:: A sample @value{GDBN} session + +* Invocation:: Getting in and out of @value{GDBN} +* Commands:: @value{GDBN} commands +* Running:: Running programs under @value{GDBN} +* Stopping:: Stopping and continuing +* Stack:: Examining the stack +* Source:: Examining source files +* Data:: Examining data + +* Languages:: Using @value{GDBN} with different languages + +* Symbols:: Examining the symbol table +* Altering:: Altering execution +* GDB Files:: @value{GDBN} files +* Targets:: Specifying a debugging target +* Configurations:: Configuration-specific information +* Controlling GDB:: Controlling @value{GDBN} +* Sequences:: Canned sequences of commands +* Emacs:: Using @value{GDBN} under @sc{gnu} Emacs +* Annotations:: @value{GDBN}'s annotations interface. + +* GDB Bugs:: Reporting bugs in @value{GDBN} +* Formatting Documentation:: How to format and print @value{GDBN} documentation + +* Command Line Editing:: Command Line Editing +* Using History Interactively:: Using History Interactively +* Installing GDB:: Installing GDB +* Index:: Index +@end menu + +@end ifhtml @node Summary @unnumbered Summary of @value{GDBN} >From eliz@delorie.com Wed Mar 22 10:10:00 2000 From: Eli Zaretskii To: Jim Blandy Cc: hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Problems with hardware watchpoint on ia32. Date: Wed, 22 Mar 2000 10:10:00 -0000 Message-id: <200003221806.NAA14225@indy.delorie.com> References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091210.HAA19857@indy.delorie.com> X-SW-Source: 2000-03/msg00466.html Content-length: 724 > Eli's test of the value's type is incorrect if the watch expression > contains a structure comparison, like (foo == bar) || (something > else), where foo and bar are structures. In that case, there will be > a value of type "struct", not at the end of the value list, but which > should be watched in its entirety. Errr... do you have an actual example program where this happens? I seem to be unable to reproduce the problem, at least in a C program: whenever I say "watch foo == bar" (where foo and bar are structs), GDB curses thusly: Structure has no component named operator==. Am I missing something? In case it matters, I tested this with a DJGPP-compiled program; DJGPP by default uses COFF debugging info. >From msnyder@cygnus.com Wed Mar 22 10:11:00 2000 From: Michael Snyder To: Andrew Cagney Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Document the ThreadInfo remote protocol queries Date: Wed, 22 Mar 2000 10:11:00 -0000 Message-id: <38D90CE6.4D18@cygnus.com> References: <200003202316.PAA07888@cleaver.cygnus.com> <38D6FCE2.EBD9830F@cygnus.com> <38D7C38C.6CB0@cygnus.com> <38D85C2F.FF89881D@cygnus.com> X-SW-Source: 2000-03/msg00467.html Content-length: 130 Andrew Cagney wrote: > Should ``C'' also be suceeded by something like ``qThread''? Is ``C'' > still used? 'qC' is still used. >From msnyder@cygnus.com Wed Mar 22 10:20:00 2000 From: Michael Snyder To: Eli Zaretskii Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Running the inferior from breakpoint commands Date: Wed, 22 Mar 2000 10:20:00 -0000 Message-id: <38D90EEC.1566@cygnus.com> References: <200003120759.CAA24402@indy.delorie.com> <200003151624.LAA01228@indy.delorie.com> <38D7F31D.1827@cygnus.com> <200003220930.EAA13024@indy.delorie.com> X-SW-Source: 2000-03/msg00468.html Content-length: 2019 Eli Zaretskii wrote: > (I did look in the manual, but since the snippet you cited isn't > indexed, I didn't find it. [Yes, I will submit a manual change to add > an index entry.]) http://sourceware.cygnus.com/gdb/onlinedocs/gdb_6.html#SEC34 four or five paragraphs down. > To me, the fact that the test suite tried to do this was a sign that > it was supposed to work. Not a very reliable guide, I'm afraid. That test was added in 1995, but as far as I know it did not work even then. Perhaps no one knew that it didn't. > As an aside: is there any place I can find the list of tests which > fail, and on what systems do they fail? I'm afraid not. Such a list would change daily. > > If you seriously want to undertake this project, we can > > work on a list of criteria that should be tested (things > > that can go wrong). > > I will put it on my todo (thanks for the list of things to test; Remember it was just a partial list off the top of my head. I'm sure there are lots more issues to consider. > > On top of that, I have grave concerns about being able > > to correctly save and restore all of the internal > > debugger state necessary to make this work (the > > infrun execution state, the expression chain, etc.) > > Err... I'm not sure this should be of concern here (but perhaps I > don't see the subtle issues clearly enough): if the breakpoint > commands change any of these global entities, I think the user expects > the changes to be visible after these commands are processed. For > example, if the commands delete the breakpoint where you stopped, the > user will expect the breakpoint to remain deleted after that (the > changes I submitted do handle this specific case). Am I missing > something? I'm not talking about anything user-visible -- I'm talking about GDB's internal state. All the variables with which it keeps track of what it's doing and what the child program is doing. I don't have anything specific in mind, I just know there is a lot to think about. Michael >From dima@Chg.RU Wed Mar 22 11:48:00 2000 From: Dmitry Sivachenko To: gdb-patches@sourceware.cygnus.com Subject: typo in gdb.texinfo Date: Wed, 22 Mar 2000 11:48:00 -0000 Message-id: <200003221948.WAA31796@netserv1.chg.ru> X-SW-Source: 2000-03/msg00469.html Content-length: 1030 Please swap these two lines in the @menu. This is how these chapters actually appear in the manual. Thank you in advance, Dima. --- gdb.1.4.texinfo Wed Mar 22 22:45:32 2000 +++ gdb.1.4.texinfo.new Wed Mar 22 22:44:43 2000 @@ -142,13 +142,13 @@ * Controlling GDB:: Controlling @value{GDBN} * Sequences:: Canned sequences of commands * Emacs:: Using @value{GDBN} under @sc{gnu} Emacs -* Annotations:: @value{GDBN}'s annotations interface. +* Annotations:: @value{GDBN}'s annotations interface * GDB Bugs:: Reporting bugs in @value{GDBN} -* Formatting Documentation:: How to format and print @value{GDBN} documentation * Command Line Editing:: Command Line Editing * Using History Interactively:: Using History Interactively +* Formatting Documentation:: How to format and print @value{GDBN} documentation * Installing GDB:: Installing GDB * Index:: Index @end menu >From assign@gnu.org Wed Mar 22 12:14:00 2000 From: assignments To: gdb-patches@sourceware.cygnus.com Subject: GDB assigns/disclaims Date: Wed, 22 Mar 2000 12:14:00 -0000 Message-id: <200003222013.PAA12928@delysid.gnu.org> X-SW-Source: 2000-03/msg00470.html Content-length: 1183 The following disclaimers and/or assignments concerning GDB have recently been added to the file copyright.list here at the Free Software Foundation. If you have any questions or corrections, please send them to my general work address, 3diff@gnu.org. Thanks! Brian Youmans Assignments Clerk GDB David Whedon US 1975 2000-02-25 Assigns past and future changes. (ser-tcp.c, command.[ch], top.c, commands.exp, gdbint.texinfo) dwhedon@gordian.com GDB Gordian 2000-03-01 Disclaims changes by David Whedon in the past and for one year. GDB Andreas Jaeger Germany 1969 2000-02-16 Assigns past and future changes. aj@suse.de GDB Serge V. Vakulenko Russia 1966 2000-01-31 Assigns past and future changes. (patch for remote debugging of Atmel AVR microcontrollers via the serial port) vak@cronyx.ru GDB Techniche Universita:t Mu:nchen, Institute for Real-Time Computer Systems 2000-02-17 Disclaims changes by Gunter Magin and Linux BDM device driver by Michael Schraut and Gunter Magin. Georg.Faerber@rcs.ei.tum.de (Georg Fa:rber) >From msnyder@cygnus.com Wed Mar 22 12:41:00 2000 From: Michael Snyder To: Eli Zaretskii Cc: Jim Blandy , hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Problems with hardware watchpoint on ia32. Date: Wed, 22 Mar 2000 12:41:00 -0000 Message-id: <38D92F29.A3D@cygnus.com> References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091210.HAA19857@indy.delorie.com> <200003221806.NAA14225@indy.delorie.com> X-SW-Source: 2000-03/msg00471.html Content-length: 759 Eli Zaretskii wrote: > > > Eli's test of the value's type is incorrect if the watch expression > > contains a structure comparison, like (foo == bar) || (something > > else), where foo and bar are structures. In that case, there will be > > a value of type "struct", not at the end of the value list, but which > > should be watched in its entirety. > > Errr... do you have an actual example program where this happens? > > I seem to be unable to reproduce the problem, at least in a C program: > whenever I say "watch foo == bar" (where foo and bar are structs), GDB > curses thusly: > > Structure has no component named operator==. Argh... gdb does not seem to know that struct compare is permitted. I'll publish a patch. Michael Snyder >From msnyder@cygnus.com Wed Mar 22 12:43:00 2000 From: Michael Snyder To: gdb-patches@sourceware.cygnus.com Subject: [PATCH]: Allow struct compare in expressions. Date: Wed, 22 Mar 2000 12:43:00 -0000 Message-id: <200003222043.MAA10512@cleaver.cygnus.com> X-SW-Source: 2000-03/msg00472.html Content-length: 4627 The following change allows GDB to evaluate (and set watchpoints on) expressions of the form (a == b) and (a != b), where a and b are simple C structs or unions. It would be possible to extend this further by allowing simple binary comparison for classes that don't have an operator== method: I leave that as an exercise for someone else. Jim Blandy, David Taylor, I think both of your approvals is required. 2000-03-22 Michael Snyder * eval.c (evaluate_subexp_standard): allow for simple comparison of structures, in the absense of C++ method symbols. * symtab.c (total_number_of_methods): make public, for use above. * symtab.h (total_number_of_methods): publish prototype. Index: ChangeLog =================================================================== RCS file: /cvs/src/src/gdb/ChangeLog,v retrieving revision 1.163 diff -c -r1.163 ChangeLog *** ChangeLog 2000/03/22 09:45:01 1.163 --- ChangeLog 2000/03/22 20:38:33 *************** *** 1,3 **** --- 1,10 ---- + 2000-03-22 Michael Snyder + + * eval.c (evaluate_subexp_standard): allow for simple comparison + of structures, in the absense of C++ method symbols. + * symtab.c (total_number_of_methods): make public, for use above. + * symtab.h (total_number_of_methods): publish prototype. + 2000-03-22 Mark Kettenis * config/i386/tm-i386aix.h (I386_AIX_TARGET): Remove. Index: eval.c =================================================================== RCS file: /cvs/src/src/gdb/eval.c,v retrieving revision 1.2 diff -c -r1.2 eval.c *** eval.c 2000/03/14 17:01:04 1.2 --- eval.c 2000/03/22 20:38:34 *************** *** 1448,1454 **** arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside); if (noside == EVAL_SKIP) goto nosideret; ! if (binop_user_defined_p (op, arg1, arg2)) { return value_x_binop (arg1, arg2, op, OP_NULL, noside); } --- 1448,1459 ---- arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside); if (noside == EVAL_SKIP) goto nosideret; ! ! /* NOTE: because BINOP_EQUAL is a legal operaton for ! C structs (as opposed to C++ classes), revert to ! simple value comparison if the type has no methods. */ ! if (binop_user_defined_p (op, arg1, arg2) && ! total_number_of_methods (arg1->type) > 0) { return value_x_binop (arg1, arg2, op, OP_NULL, noside); } *************** *** 1463,1469 **** arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside); if (noside == EVAL_SKIP) goto nosideret; ! if (binop_user_defined_p (op, arg1, arg2)) { return value_x_binop (arg1, arg2, op, OP_NULL, noside); } --- 1468,1479 ---- arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside); if (noside == EVAL_SKIP) goto nosideret; ! ! /* NOTE: because BINOP_NOTEQUAL is a legal operaton for ! C structs (as opposed to C++ classes), revert to ! simple value comparison if the type has no methods. */ ! if (binop_user_defined_p (op, arg1, arg2) && ! total_number_of_methods (arg1->type) > 0) { return value_x_binop (arg1, arg2, op, OP_NULL, noside); } Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.2 diff -c -r1.2 symtab.c *** symtab.c 2000/02/08 04:39:02 1.2 --- symtab.c 2000/03/22 20:38:34 *************** *** 2217,2225 **** reader because the type of the baseclass might still be stubbed when the definition of the derived class is parsed. */ ! static int total_number_of_methods PARAMS ((struct type * type)); ! ! static int total_number_of_methods (type) struct type *type; { --- 2217,2223 ---- reader because the type of the baseclass might still be stubbed when the definition of the derived class is parsed. */ ! int total_number_of_methods (type) struct type *type; { Index: symtab.h =================================================================== RCS file: /cvs/src/src/gdb/symtab.h,v retrieving revision 1.4 diff -c -r1.4 symtab.h *** symtab.h 2000/03/21 22:37:42 1.4 --- symtab.h 2000/03/22 20:38:34 *************** *** 1462,1467 **** --- 1462,1472 ---- extern int in_prologue PARAMS ((CORE_ADDR pc, CORE_ADDR func_start)); + /* Number of method symbols for TYPE + (and all its base classes) */ + extern int + total_number_of_methods PARAMS ((struct type * type)); + extern struct symbol * fixup_symbol_section PARAMS ((struct symbol *, struct objfile *)); >From gkm@cygnus.com Wed Mar 22 12:45:00 2000 From: gkm@cygnus.com (glen mccready) To: Elena Zannoni , gdb-patches@sourceware.cygnus.com Cc: Fernando Nasser , Chris Faylor Subject: sim/arm/wrapper.c fix. Date: Wed, 22 Mar 2000 12:45:00 -0000 Message-id: <200003222045.MAA03959@cygint.cygnus.com> X-SW-Source: 2000-03/msg00473.html Content-length: 1457 Index: ChangeLog =================================================================== RCS file: /cvs/cvsfiles/devo/sim/arm/ChangeLog,v retrieving revision 1.77 diff -c -b -r1.77 ChangeLog *** ChangeLog 1998/09/14 17:04:36 1.77 --- ChangeLog 2000/03/22 20:27:15 *************** *** 1,3 **** --- 1,7 ---- + Wed Mar 22 15:24:21 2000 glen mccready + + * wrapper.c (sim_open,sim_close): Copy into myname, free myname + Mon Sep 14 09:00:05 1998 Nick Clifton * wrapper.c (sim_open): Set endianness according to BFD or command Index: wrapper.c =================================================================== RCS file: /cvs/cvsfiles/devo/sim/arm/wrapper.c,v retrieving revision 1.24 diff -c -b -r1.24 wrapper.c *** wrapper.c 1998/09/14 17:04:36 1.24 --- wrapper.c 2000/03/22 20:27:15 *************** *** 347,353 **** char **argv; { sim_kind = kind; ! myname = argv[0]; sim_callback = ptr; /* Decide upon the endian-ness of the processor. --- 347,354 ---- char **argv; { sim_kind = kind; ! if (myname) free(myname); ! myname = xstrdup(argv[0]); sim_callback = ptr; /* Decide upon the endian-ness of the processor. *************** *** 405,411 **** SIM_DESC sd; int quitting; { ! /* nothing to do */ } SIM_RC --- 406,413 ---- SIM_DESC sd; int quitting; { ! if (myname) free(myname); ! myname = 0; } SIM_RC >From Peter.Schauer@regent.e-technik.tu-muenchen.de Wed Mar 22 12:57:00 2000 From: "Peter.Schauer" To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] printcmd.c: Truncate output width of p/a and x/a if necessary Date: Wed, 22 Mar 2000 12:57:00 -0000 Message-id: <200003222057.VAA24195@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-03/msg00474.html Content-length: 1272 FYI, I checked in the attached patch. It gets rid of the gdb.base/long_long.exp: x/a &oct testsuite failure on Solaris 2.7 sparc. For more information see http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00555.html 2000-03-22 Peter Schauer * printcmd.c (print_scalar_formatted): Truncate addresses to the size of a target pointer before passing them to print_address. Index: printcmd.c =================================================================== RCS file: /cvs/src/src/gdb/printcmd.c,v retrieving revision 1.1.1.8 diff -u -p -r1.1.1.8 printcmd.c --- printcmd.c 2000/02/05 07:29:47 1.1.1.8 +++ printcmd.c 2000/03/22 20:48:31 @@ -443,7 +443,14 @@ print_scalar_formatted (valaddr, type, f break; case 'a': - print_address (unpack_pointer (type, valaddr), stream); + { + /* Truncate address to the size of a target pointer, avoiding + shifts larger or equal than the width of a CORE_ADDR. */ + CORE_ADDR addr = unpack_pointer (type, valaddr); + if (TARGET_PTR_BIT < (sizeof (CORE_ADDR) * HOST_CHAR_BIT)) + addr &= ((CORE_ADDR) 1 << TARGET_PTR_BIT) - 1; + print_address (addr, stream); + } break; case 'c': -- Peter Schauer pes@regent.e-technik.tu-muenchen.de >From taylor@cygnus.com Wed Mar 22 12:58:00 2000 From: David Taylor To: Michael Snyder Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: Allow struct compare in expressions. Date: Wed, 22 Mar 2000 12:58:00 -0000 Message-id: <200003222057.PAA23063@texas.cygnus.com> X-SW-Source: 2000-03/msg00476.html Content-length: 5148 From: Michael Snyder Date: Wed, 22 Mar 2000 12:43:56 -0800 (PST) The following change allows GDB to evaluate (and set watchpoints on) expressions of the form (a == b) and (a != b), where a and b are simple C structs or unions. It would be possible to extend this further by allowing simple binary comparison for classes that don't have an operator== method: I leave that as an exercise for someone else. Jim Blandy, David Taylor, I think both of your approvals is required. 2000-03-22 Michael Snyder * eval.c (evaluate_subexp_standard): allow for simple comparison of structures, in the absense of C++ method symbols. * symtab.c (total_number_of_methods): make public, for use above. * symtab.h (total_number_of_methods): publish prototype. Approved. Index: ChangeLog =================================================================== RCS file: /cvs/src/src/gdb/ChangeLog,v retrieving revision 1.163 diff -c -r1.163 ChangeLog *** ChangeLog 2000/03/22 09:45:01 1.163 --- ChangeLog 2000/03/22 20:38:33 *************** *** 1,3 **** --- 1,10 ---- + 2000-03-22 Michael Snyder + + * eval.c (evaluate_subexp_standard): allow for simple comparison + of structures, in the absense of C++ method symbols. + * symtab.c (total_number_of_methods): make public, for use above. + * symtab.h (total_number_of_methods): publish prototype. + 2000-03-22 Mark Kettenis * config/i386/tm-i386aix.h (I386_AIX_TARGET): Remove. Index: eval.c =================================================================== RCS file: /cvs/src/src/gdb/eval.c,v retrieving revision 1.2 diff -c -r1.2 eval.c *** eval.c 2000/03/14 17:01:04 1.2 --- eval.c 2000/03/22 20:38:34 *************** *** 1448,1454 **** arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside); if (noside == EVAL_SKIP) goto nosideret; ! if (binop_user_defined_p (op, arg1, arg2)) { return value_x_binop (arg1, arg2, op, OP_NULL, noside); } --- 1448,1459 ---- arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside); if (noside == EVAL_SKIP) goto nosideret; ! ! /* NOTE: because BINOP_EQUAL is a legal operaton for ! C structs (as opposed to C++ classes), revert to ! simple value comparison if the type has no methods. */ ! if (binop_user_defined_p (op, arg1, arg2) && ! total_number_of_methods (arg1->type) > 0) { return value_x_binop (arg1, arg2, op, OP_NULL, noside); } *************** *** 1463,1469 **** arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside); if (noside == EVAL_SKIP) goto nosideret; ! if (binop_user_defined_p (op, arg1, arg2)) { return value_x_binop (arg1, arg2, op, OP_NULL, noside); } --- 1468,1479 ---- arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside); if (noside == EVAL_SKIP) goto nosideret; ! ! /* NOTE: because BINOP_NOTEQUAL is a legal operaton for ! C structs (as opposed to C++ classes), revert to ! simple value comparison if the type has no methods. */ ! if (binop_user_defined_p (op, arg1, arg2) && ! total_number_of_methods (arg1->type) > 0) { return value_x_binop (arg1, arg2, op, OP_NULL, noside); } Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.2 diff -c -r1.2 symtab.c *** symtab.c 2000/02/08 04:39:02 1.2 --- symtab.c 2000/03/22 20:38:34 *************** *** 2217,2225 **** reader because the type of the baseclass might still be stubbed when the definition of the derived class is parsed. */ ! static int total_number_of_methods PARAMS ((struct type * type)); ! ! static int total_number_of_methods (type) struct type *type; { --- 2217,2223 ---- reader because the type of the baseclass might still be stubbed when the definition of the derived class is parsed. */ ! int total_number_of_methods (type) struct type *type; { Index: symtab.h =================================================================== RCS file: /cvs/src/src/gdb/symtab.h,v retrieving revision 1.4 diff -c -r1.4 symtab.h *** symtab.h 2000/03/21 22:37:42 1.4 --- symtab.h 2000/03/22 20:38:34 *************** *** 1462,1467 **** --- 1462,1472 ---- extern int in_prologue PARAMS ((CORE_ADDR pc, CORE_ADDR func_start)); + /* Number of method symbols for TYPE + (and all its base classes) */ + extern int + total_number_of_methods PARAMS ((struct type * type)); + extern struct symbol * fixup_symbol_section PARAMS ((struct symbol *, struct objfile *));