From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Jimmy Guo Cc: gdb-patches@sourceware.cygnus.com Subject: Re: regression analysis: gdb.sum postprocessing script Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DBB807.F97D968D@cygnus.com> References: X-SW-Source: 2000-q1/msg00993.html Jimmy Guo wrote: > > Here is a Perl script I wrote to postprocess one or more gdb.sum files > and provide a complete dejagnu test outcome summary (or diff if more > than one gdb.sum files are given). It's most useful if you want to have > a complete view of regression status between two source trees and/or if > you set up your testing to run multiple passes (to see how a test point > behaves in different passes), however you can use it just on one test > run's gdb.sum file and play around with the options to get test outcome > presented in a much organized and useful way than going through the flat > gdb.sum file. > > I don't know if this is useful to keep around in the repository ... > Sure it is. Just a question: is this being assigned and can be distributed under the GPL? If Stan agrees, I would like to incorporate it (IP issues sorted, of course). -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: gdb-patches@sourceware.cygnus.com Subject: Re: dlclose() Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <200002161953.OAA07411@devserv.devel.redhat.com> <200002200521.AAA29598@devserv.devel.redhat.com> <88nurn$e4d$1@cronkite.cygnus.com> <88qer9$lbd$1@cronkite.cygnus.com> X-SW-Source: 2000-q1/msg00297.html Content-length: 1055 > We've already seen at least one recent case where a test suite run prior > to an overly optimistic check-in would probably have saved people from > breakage. Hard to argue when you put it that way :-). Here are test results for x86 linux (Red Hat Linux 6.1) and SunOS4, respectively. In both cases they were the same with and without the http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00251.html patch. I think the larger issue regarding the testsuite still needs attention/rethinking, but obviously I'm not in a very strong negotiating position just now :-). So I won't elaborate just now (I'm in enough trouble as it is). Linux: # of expected passes 6357 # of unexpected failures 12 # of expected failures 200 SunOS4: # of expected passes 6409 # of unexpected failures 28 # of unexpected successes 1 # of expected failures 171 # of unresolved testcases 5 # of unsupported tests 1 /home/kingdon/src/gdb/testsuite/../../gdb/gdb version 20000204 -nx >From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb-patches@sourceware.cygnus.com Subject: PATCH: handle NAK packets sent by remote stub. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5mya8zqhbg.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00080.html Content-length: 1999 This patch wasn't lost, but rather deferred for further thought just before the 4.18 branch/release. The putpkt_binary() function doesn't specifically handle the NAK ('-') character after a packet has been transmitted. It's treated as a junk character and ignored. As a result, in the case of packet corruption, GDB waits remote_timeout seconds to re-try the packet even though the target has told GDB that the packet needs to be retransmitted. The enclosed patch handles Nak, so the packet is retransmitted immediately. The one concern that I remember was the risk of spurious NAKs from the target interfering with the proper operation remote protocol. This is a possibility, but in my opinion it's no more so than spurious ACKs. Without ACKs and NAKs being framed/checksummed, the remote protocol is simply vulnerable to communication errors. We've had this change in our local GDBs for about a year. It has caused no problems that I'm aware of. I submitted this patch before I started archiving my outbound mail. So this time, the ChangeLog is new. --jtc 2000-02-05 J.T. Conklin * remote.c (putpkt_binary): Handle NAK from target stub. Index: remote.c =================================================================== RCS file: /home/jtc/CVSROOT/gdb/gdb/remote.c,v retrieving revision 1.1.1.28 retrieving revision 1.19 diff -c -r1.1.1.28 -r1.19 *** remote.c 2000/02/04 21:24:02 1.1.1.28 --- remote.c 2000/02/04 23:52:40 1.19 *************** *** 3730,3735 **** --- 3721,3727 ---- switch (ch) { case '+': + case '-': case SERIAL_TIMEOUT: case '$': if (started_error_output) *************** *** 3746,3751 **** --- 3738,3746 ---- if (remote_debug) fprintf_unfiltered (gdb_stdlog, "Ack\n"); return 1; + case '-': + if (remote_debug) + fprintf_unfiltered (gdb_stdlog, "Nak\n"); case SERIAL_TIMEOUT: tcount++; if (tcount > 3) -- J.T. Conklin RedBack Networks >From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb-patches@sourceware.cygnus.com Subject: PATCH: remote stub store single register command error return value Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5m7lgjrxfy.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00078.html Content-length: 4207 Another pending patch: "As pointed out on the gdb list earlier today, some of the sample stubs return "P01" when the 'store single register' command (P) fails. This does not conform to the remote protocol spec, which states that values of the form "ENN" are to be used for reporting errors. GDB does not currently check return value of register store commands, If this is fixed, it should check for "OK" instead of "ENN". As before, ChangeLog is from original submission, the patch itself has been regenerated relative to the 20000204 snapshot. --jtc 1999-10-18 J.T. Conklin * m32r-stub.c, sparcl-stub.c, sparclet-stub.c (handle_exception): Return E01 instead of P01 when 'P' command fails. Index: m32r-stub.c =================================================================== RCS file: /home/jtc/CVSROOT/gdb/gdb/m32r-stub.c,v retrieving revision 1.1.1.5 retrieving revision 1.7 diff -c -r1.1.1.5 -r1.7 *** m32r-stub.c 1999/10/01 08:13:13 1.1.1.5 --- m32r-stub.c 2000/02/03 19:44:48 1.7 *************** *** 425,431 **** strcpy (remcomOutBuffer, "OK"); break; } ! strcpy (remcomOutBuffer, "P01"); break; } case 'G': /* set the value of the CPU registers - return OK */ --- 425,431 ---- strcpy (remcomOutBuffer, "OK"); break; } ! strcpy (remcomOutBuffer, "E01"); break; } case 'G': /* set the value of the CPU registers - return OK */ Index: sparcl-stub.c =================================================================== RCS file: /home/jtc/CVSROOT/gdb/gdb/sparcl-stub.c,v retrieving revision 1.1.1.4 retrieving revision 1.9 diff -c -r1.1.1.4 -r1.9 *** sparcl-stub.c 1999/09/09 19:12:15 1.1.1.4 --- sparcl-stub.c 2000/02/06 00:16:36 1.9 *************** *** 50,55 **** --- 50,56 ---- * * g return the value of the CPU registers hex data or ENN * G set the value of the CPU registers OK or ENN + * P set the value of a single CPU register OK or ENN * * mAA..AA,LLLL Read LLLL bytes at address AA..AA hex data or ENN * MAA..AA,LLLL: Write LLLL bytes at address AA.AA OK or ENN *************** *** 831,837 **** hex2mem (ptr, (char *)®isters[regno], 4, 0); else { ! strcpy (remcomOutBuffer, "P01"); break; } } --- 832,838 ---- hex2mem (ptr, (char *)®isters[regno], 4, 0); else { ! strcpy (remcomOutBuffer, "E01"); break; } } Index: sparclet-stub.c =================================================================== RCS file: /home/jtc/CVSROOT/gdb/gdb/sparclet-stub.c,v retrieving revision 1.1.1.4 diff -c -r1.1.1.4 sparclet-stub.c *** sparclet-stub.c 1999/09/09 19:12:16 1.1.1.4 --- sparclet-stub.c 2000/02/06 00:15:10 *************** *** 50,56 **** * * g return the value of the CPU registers hex data or ENN * G set the value of the CPU registers OK or ENN ! * P set the value of a single CPU register OK or P01 (???) * * mAA..AA,LLLL Read LLLL bytes at address AA..AA hex data or ENN * MAA..AA,LLLL: Write LLLL bytes at address AA.AA OK or ENN --- 50,56 ---- * * g return the value of the CPU registers hex data or ENN * G set the value of the CPU registers OK or ENN ! * P set the value of a single CPU register OK or ENN * * mAA..AA,LLLL Read LLLL bytes at address AA..AA hex data or ENN * MAA..AA,LLLL: Write LLLL bytes at address AA.AA OK or ENN *************** *** 938,944 **** hex2mem (ptr, (char *)®isters[regno], 4, 0); else { ! strcpy (remcomOutBuffer, "P01"); break; } } --- 938,944 ---- hex2mem (ptr, (char *)®isters[regno], 4, 0); else { ! strcpy (remcomOutBuffer, "E01"); break; } } -- J.T. Conklin RedBack Networks >From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000 From: Elena Zannoni To: gdb-patches@sourceware.cygnus.com Subject: MI updates Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <14532.14584.823970.23945@kwikemart.cygnus.com> X-SW-Source: 2000-q1/msg00549.html Content-length: 1382 Hi, I just cleaned the testsuite for MI, updated the gdbmi.texinfo file to reflect the latest changes to the MI disasssembly command, and checked in an implementation of the -data-write-registers-values command. Elena gdb/mi/ChangeLog-mi: 2000-03-06 Elena Zannoni * mi-cmds.h: Export mi_cmd_data_write_register_values. * mi-cmds.c (mi_cmds): Implement data-write-register-values with mi_cmd_data_write_register_values. * mi-main.c (mi_cmd_data_write_register_values): New function. Write a value into a register. 2000-03-06 Elena Zannoni * mi-cmds.h: * gdbmi.texinfo: Update data-disassemble documentation. gdb/testsuite/gdb.mi/ChangeLog-mi: 2000-03-06 Elena Zannoni * mi-disassemble.exp: Don't assume numbers for the offset values. They can be different depending on the architecture. * mi-watch.exp (test_watchpoint_triggering): In same cases the type can be 'hw wathcpoint' not just 'watchpoint'. Adjust for that. * basics.c (callee4): Make the function return something, otherwise the return value is undefined. 2000-03-06 Elena Zannoni * mi-basics.exp: Comment out test for a still unimplemented operation. * mi-disassemble.exp: Rewrite most of the tests to conform to new disassemble interface. >From toddpw@windriver.com Sat Apr 01 00:00:00 2000 From: Todd Whitesel To: ac131313@cygnus.com (Andrew Cagney) Cc: phdm@macqel.be (Philippe De Muyter), gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com) Subject: Re: PATCH/RFA: regerror link error Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003280329.TAA16525@alabama.wrs.com> References: <38DFFFF1.A2BD1D4E@cygnus.com> X-SW-Source: 2000-q1/msg01075.html Content-length: 344 > > * gnu-regex.c (regerror): Function renamed from `__regerror'. > > The change is fine. It's already in the official glibc. The -exact- change?? Is 'regerror' part of the defined API? I sure hope so. (If it's not, then removing the underscores means a new potential namespace conflict.) -- Todd Whitesel toddpw @ windriver.com >From msnyder@cygnus.com Sat Apr 01 00:00:00 2000 From: Michael Snyder To: Dmitry Sivachenko Cc: gdb-patches@sourceware.cygnus.com Subject: Re: typo in gdb.texinfo Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38CFE64A.2BBB@cygnus.com> References: <200003151932.WAA39200@netserv1.chg.ru> X-SW-Source: 2000-q1/msg00722.html Content-length: 954 Dmitry Sivachenko wrote: > > There is no value for GDBINIT! > Consider this fix: > > --dima > > --- gdb.texinfo.orig Wed Mar 15 22:31:16 2000 > +++ gdb.texinfo Wed Mar 15 22:31:32 2000 > @@ -10611,7 +10611,7 @@ > @cindex floating point, MIPS remote > If your target board does not support the MIPS floating point > coprocessor, you should use the command @samp{set mipsfpu none} (if you > -need this, you may wish to put the command in your @value{GDBINIT} > +need this, you may wish to put the command in your @file{.gdbinit} > file). This tells @value{GDBN} how to find the return value of > functions which return floating point values. It also allows > @value{GDBN} to avoid saving the floating point registers when calling I think the purpose of having GDBINIT be a variable is because it has a different filename on windows/CYGWIN. Isn't it called "gdb.ini" or something? If the variable truly isn't defined, it probably should be. >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Patches Subject: [patch] doc/Makefile.in - create destdir Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DB12B5.C2DE8F11@cygnus.com> X-SW-Source: 2000-q1/msg00979.html Content-length: 764 FYI, I've applied the below. Per Eli's note, the Makefile was assuming that the directory was already there. Andrew Fri Mar 24 17:56:48 2000 Andrew Cagney * Makefile.in (install-info): Create $(infodir) before installing files. Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/doc/Makefile.in,v retrieving revision 1.2 diff -p -r1.2 Makefile.in *** Makefile.in 2000/02/16 04:44:55 1.2 --- Makefile.in 2000/03/24 06:57:58 *************** all-doc: info dvi ps *** 103,108 **** --- 103,109 ---- diststuff: info install-info: info + $(SHELL) $(srcdir)/../../mkinstalldirs $(infodir) for i in *.info* ; do \ $(INSTALL_DATA) $$i $(infodir)/$$i ; \ done >From Peter.Schauer@regent.e-technik.tu-muenchen.de Sat Apr 01 00:00:00 2000 From: "Peter.Schauer" To: gdb-patches@sourceware.cygnus.com Subject: RFD: printcmd.c: Changing output width of p/a and x/a Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003072113.WAA26267@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-q1/msg00555.html Content-length: 2174 Due to a recent BFD change, a CORE_ADDR is now an unsigned long long with 64 Bits on Solaris 2.7 sparc and causes a testsuite regression in long_long.exp: (gdb) x/a &oct 0xffbef848: 0xffffffffa72ee539 (gdb) FAIL: gdb.base/long_long.exp: x/a &oct printcmd.c:print_scalar_formatted calls print_address with the result from unpack_pointer. As the `examine type' passed to unpack_pointer is signed, we get sign extension to 64 bits when printing the address value. The solution is simple, just truncate the core address like we truncate values around line 404 in printcmd.c But how much truncation should be done to meet user expectations ? I have a feeling that we should truncate to TARGET_PTR_BIT (which would get rid of the testsuite regression without causing new ones). On the other hand this would be inconsistent with the truncation of values, which is done with the type length of the value. Would you expect (gdb) p/a (char)-1 to yield $1 = 0xff (truncation to length of value, will cause testsuite regressions, which have to be adressed by changing the expect patterns) or $1 = 0xffffffff (truncation to size of pointer) Here is a patch to truncate to the size of a pointer, please let me know if you want this to be changed to truncate to the length of the value. 2000-03-07 Peter Schauer * printcmd.c (print_scalar_formatted): Truncate addresses to the size of a target pointer before passing them to print_address. *** ./printcmd.c.orig Sun Mar 5 17:35:36 2000 --- ./printcmd.c Tue Mar 7 19:59:46 2000 *************** *** 443,449 **** break; case 'a': ! print_address (unpack_pointer (type, valaddr), stream); break; case 'c': --- 443,455 ---- break; case 'a': ! { ! /* Truncate address to the size of a target pointer. */ ! 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 jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000 From: Jim Blandy To: Jim Kingdon Cc: toddpw@windriver.com, hjl@lucon.org, kettenis@wins.uva.nl, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: A revised patch for dlclose Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <200003080849.AAA18417@alabama.wrs.com> <200003081441.JAA02876@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00602.html Content-length: 448 > > If each DSO was given its own obstack, it would be pretty easy. > > This is largely a solved problem (via objfiles). > [...] > There are a few loose ends in freeing, but it is the tangled logic in > find_solib that is tripping us up more than the freeing. Yes, that's right. I've pretty much come to the same conclusion as JimK --- I think there are ways to repartition find_solib's responsibilities that will make this logic a lot simpler. >From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000 From: Jim Blandy To: Andrew Cagney Cc: Stephane Carrez , gdb-patches@sourceware.cygnus.com, Jim Blandy Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <38B2F3D3.54CF0AF0@worldnet.fr> <38BB5463.D6E5B75C@cygnus.com> <38C0D9D9.70987863@worldnet.fr> <38C225F3.9E236A55@cygnus.com> X-SW-Source: 2000-q1/msg01083.html Content-length: 1629 > > elf16 is not a good idea. I think we must not mix the size of cpu > > address with the format of ELF files. The ELF file can be larger than > > 64K and we might need indexes larger than 16-bit. > > When I say ``elf16'', I was thinking of an elf object file that has 16 > bit addresses. I'm not sure what other consequences such a move would > have. > > Is there any reason why s->arch_size isn't 16 in your case? s->arch_size is not an especially meaningful field. It exists only to indicate whether you've got an ELF32 or ELF64 format file. I think inventing a new ELF16 file format is a bad idea. There are a zillion things to take into account. It's much simpler to just use ELF32, and only link things into the lower 64k, which is what we've done with other 16-bit processors in the past. If you want to know the actual processor address size, there's a different BFD field whose job is to provide that information. That's bfd_arch_bits_per_address, which Stephane suggested we use instead. In general, the change that has dwarf2read checking the ELF backend data has just been a pain from day one. I remember fixing related dependency problems, people on the binutils list saying "This looks really wrong," and so on. GDB shouldn't be using internal BFD headers, and consulting internal ELF BFD data structures. I also buy Jim Kingdon's argument that it shouldn't be necessary to mask off the upper bits. The data in the ELF file should be correct. I'm going to revert the change which introduced address_significant_size in the first place. If this causes problems, then we'll fix the bug correctly. >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] go32-nat.o prerequisites in gdb/Makefile.in Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003161028.FAA01889@indy.delorie.com> X-SW-Source: 2000-q1/msg00737.html Content-length: 1174 I committed the following (for references see the message here: http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00522.html ) 2000-03-04 Eli Zaretskii * Makefile.in (go32-nat.o): Add prerequisites. (ALLDEPFILES): Add go32-nat.c. --- gdb/Makefile.i~1 Sat Mar 4 18:26:36 2000 +++ gdb/Makefile.in Sat Mar 4 19:09:54 2000 @@ -1067,7 +1067,7 @@ convex-tdep.c convex-xdep.c \ core-sol2.c core-regset.c core-aout.c corelow.c \ dcache.c delta68-nat.c dpx2-nat.c dstread.c exec.c fork-child.c \ - gould-tdep.c gould-xdep.c h8300-tdep.c h8500-tdep.c \ + go32-nat.c gould-tdep.c gould-xdep.c h8300-tdep.c h8500-tdep.c \ hp300ux-nat.c hppa-tdep.c hppab-nat.c hppah-nat.c \ hp-psymtab-read.c hp-symtab-read.c \ i386-tdep.c i386b-nat.c i386mach-nat.c i386v-nat.c i386-linux-nat.c \ @@ -1356,6 +1356,9 @@ $(gdbtypes_h) language.h objfiles.h symfile.h $(symtab_h) target.h \ $(value_h) gdb_string.h +go32-nat.o: go32-nat.c $(defs_h) $(inferior_h) gdb_wait.h $(gdbcore_h) \ + $(command_h) $(floatformat_h) target.h + gnu-nat.o: process_reply_S.h exc_request_S.h notify_S.h msg_reply_S.h \ exc_request_U.h msg_U.h gnu-nat.h >From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000 From: Elena Zannoni To: "Philippe De Muyter" Cc: eliz@is.elta.co.il, ezannoni@cygnus.com, ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: HAVE_POLL is not enough - RFA Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <14550.34053.54053.454075@kwikemart.cygnus.com> References: <200003182226.RAA07052@indy.delorie.com> <200003182300.AAA32279@mail.macqel.be> X-SW-Source: 2000-q1/msg00820.html Content-length: 1467 Philippe, I didn't commit your suggested change below, yet. Can you submit that as part of your patch, now that Eli's changes are in? Thanks Elena Philippe De Muyter writes: > Eli Zaretskii wrote : > > * event-loop.c (top-level) [NO_FD_SET]: Deprecate this branch. > > Print an error at compile time if we are to use select, but FD_SET > > is not available. > > (SELECT_MASK, NBBY, FD_SETSIZE, NFDBITS, MASK_SIZE): Define only > > if HAVE_POLL is not defined and NO_FD_SET *is* defined. > > (create_file_handler) [!HAVE_POLL]: Use FD_SET and FD_CLR. > > (delete_file_handler) [!HAVE_POLL]: Use FD_CLR and FD_ISSET. > > (gdb_wait_for_event) [!HAVE_POLL]: Copy fd_set sets directly > > instead of using memcpy and memset. Use FD_ISSET. > > > > +#ifdef NO_FD_SET > > +/* All this stuff below is not required if select is used as God(tm) > > + intended, with the FD_* macros. Are there any implementations of > > + select which don't have FD_SET and other standard FD_* macros? I > > + don't think there are, but if I'm wrong, we need to catch them. */ > > +#error FD_SET must be defined if select function is to be used! > > I agree completely that your change is the right thing, but it misses > the following sequence : > > #if HAVE_SYS_SELECT_H > #include > #endif > > that is needed a.o. on AIX (See e.g. the sources of bash, screen, mc, uucp, > ncurses, inetutils, cvs or emacs) > > Philippe >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: gdb-patches@sourceware.cygnus.com Cc: ezannoni@cygnus.com Subject: Re: [PATCH] GDB command-line switches and annotations docs Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003120754.CAA24393@indy.delorie.com> References: <14537.5048.99180.910863@kwikemart.cygnus.com> <200003101809.NAA22092@indy.delorie.com> <14537.18119.116000.442262@kwikemart.cygnus.com> X-SW-Source: 2000-q1/msg00654.html Content-length: 681 > I admit I haven't documented the event loop machinery at all (that > should actually go in the internal manual). I thoroughly commented the > code though, if that's any excuse :-). > > I wasn't going to document the existance of target 'async' either, > because that's also supposed to go away, and be absorbed into a new > and improved target 'remote'. There are still a bunch of loose ends to > finish before that's going to happen. So I am not sure what the best > course of action is. If it would help, I could add a note telling that the event loop is still not fully asynchronous, with a FIXME comment that the note should be removed when the target side is done. Okay? >From Peter.Schauer@regent.e-technik.tu-muenchen.de Sat Apr 01 00:00:00 2000 From: "Peter.Schauer" To: gdb-patches@sourceware.cygnus.com Subject: Severe regression in corefile.exp with Solaris 2.7 sparc + hack Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003072113.WAA26253@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-q1/msg00554.html Content-length: 3090 This change: 2000-02-25 Alexandre Oliva * config.bfd: Enable 64 bit support for GNU/Linux/sparc. * config.bfd: Enable 64 bit support for Solaris7+/sparc. causes a severe regression in corefile.exp on Solaris 2.7 sparc, which should definitely be fixed before the 5.0 release. Due to the BFD change, a CORE_ADDR is now an unsigned long long with 64 Bits. When casting 32 bit pointers to a CORE_ADDR in solib.c, the sign bit of the pointer gets extended, resulting in a very large adress. This is not a problem when accessing the inferior via procfs (because the address gets truncated back to 32 bits in the procfs interface), but it causes failures when trying to retrieve the shared library info from corefile BFDs. I have no idea how to solve this cleanly, and offer a crude hack only. Perhaps `someone' will have a cleaner solution for this problem. 2000-03-07 Peter Schauer * solib.c (solib_addr_bits_remove) New function to mask off unwanted address bits. (find_solib): Use it. *** gdb/solib.c.orig Wed Nov 17 03:30:28 1999 --- gdb/solib.c Tue Mar 07 16:38:39 2000 *************** *** 974,979 **** --- 974,991 ---- in . */ + /* FIXME: When GDB is configured for some 32-bit targets (e.g. Solaris 2.7 + sparc), BFD is configured to handle 64-bit targets, so CORE_ADDR is + 64 bits. We may have to mask off sign extension bits from addresses to + get the right address when accessing the core file BFD via read_memory. */ + static CORE_ADDR + solib_addr_bits_remove (CORE_ADDR addr) + { + if (TARGET_PTR_BIT <= 32) + addr &= 0xffffffff; + return addr; + } + static struct so_list * find_solib (so_list_ptr) struct so_list *so_list_ptr; /* Last lm or NULL for first one */ *************** *** 1045,1051 **** } so_list_next = new; ! read_memory ((CORE_ADDR) lm, (char *) &(new->lm), sizeof (struct link_map)); /* For SVR4 versions, the first entry in the link map is for the inferior executable, so we must ignore it. For some versions of --- 1057,1063 ---- } so_list_next = new; ! read_memory (solib_addr_bits_remove ((CORE_ADDR) lm), (char *) &(new->lm), sizeof (struct link_map)); /* For SVR4 versions, the first entry in the link map is for the inferior executable, so we must ignore it. For some versions of *************** *** 1056,1063 **** { int errcode; char *buffer; ! target_read_string ((CORE_ADDR) LM_NAME (new), &buffer, ! MAX_PATH_SIZE - 1, &errcode); if (errcode != 0) { warning ("find_solib: Can't read pathname for load map: %s\n", --- 1068,1075 ---- { int errcode; char *buffer; ! target_read_string (solib_addr_bits_remove ((CORE_ADDR) LM_NAME (new)), ! &buffer, MAX_PATH_SIZE - 1, &errcode); if (errcode != 0) { warning ("find_solib: Can't read pathname for load map: %s\n", -- Peter Schauer pes@regent.e-technik.tu-muenchen.de >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Patches Subject: RFA Replace gdb/TODO with issues50 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DAED11.C314EA48@cygnus.com> X-SW-Source: 2000-q1/msg00975.html Content-length: 325 Hello, I'd like to propose that the file gdb/TODO be emptied and then refilled with a heavily edited version of: http://sourceware.cygnus.com/gdb/issues50.html To the best of my knowledge large chunks of the existing TODO file are either wrong or irrelevant. I think starting from scratch would be more useful. Andrew >From dan@cgsoftware.com Sat Apr 01 00:00:00 2000 From: Daniel Berlin To: Andrew Cagney Cc: Fernando Nasser , David Whedon , gdb-patches@sourceware.cygnus.com Subject: Re: [REPOST #2] patch: command deprecator Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <38DAA407.644AA5C1@cygnus.com> X-SW-Source: 2000-q1/msg00956.html Content-length: 342 > > None, sorry. This isn't a must have for GDB 5 so there isn't the > desperate rush. > If I lifted a page from the latest mills&boon and included in my own > book, would I be infringing on copyright? Depends on what your book is for. (I asked a lawyer before i opened my mouth, to make sure i don't stick my foot in it). > > Andrew >