From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Jim Blandy Cc: Stephane Carrez , Andrew Cagney , gdb-patches@sourceware.cygnus.com 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: <38DFBF66.137FC0A@cygnus.com> References: <38D4DCB0.88313CB2@worldnet.fr> <38D5B6E0.50FF6A5E@cygnus.com> <38D68C56.856CB00C@worldnet.fr> <38D74A9E.A85ED8EC@cygnus.com> <38D7E6BC.79543EBA@worldnet.fr> X-SW-Source: 2000-q1/msg01064.html Jim Blandy wrote: > > I've reached the same conclusion on a project I'm doing right now. I > think this test is bogus. > It seems that we have a consensus. Jim, will you do the honors and get Stephane patch in (thus removing the offending test)? -- 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 dan@cgsoftware.com Sat Apr 01 00:00:00 2000 From: dan@cgsoftware.com (Daniel Berlin) To: gdb-patches@sourceware.cygnus.com Subject: [RFA] Demangled minsym hash table broken Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: X-SW-Source: 2000-q1/msg01115.html Content-length: 839 I was trying to debug a bug report, and in the process, noticed that the demangled minsym hash table is broken (I noticed because we weren't finding a symbol we should have been able to find). Since add_minsym_to_hashtable only uses minsym_hash, and the code adding to the demangled minsym hashtable is using that function, the symbols never get the right hash value, because they need to use minsym_hash_iw. The lookups properly use that function. My fix is to add an extra parameter to add_minsym_to_hashtable so we can tell the function whether we are adding a mangled or demangled symbol, and thus, it can pick the right bucket. Also, i made it set the proper next as well (we need to set sym->demangled_hash_next if it's a demangled symbol). So up until now, the demangled symbol table was never working, as i had suspected. --Dan >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Michael Snyder Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Document the ThreadInfo remote protocol queries Date: Sat, 01 Apr 2000 00:00: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-q1/msg00896.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 ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: jtc@redback.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: list which remote protocol commands are required Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38D6F87E.9EE3E726@cygnus.com> References: <5md7opufwl.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00844.html Content-length: 543 "J.T. Conklin" wrote: > > I submit the enclosed patch for approval. The existing documentation > labled some remote protocol commands as optional, while in fact most > commands are. This patch removes the "optional" tag from the table > of commands, and explicitly lists the required commands. It's fine from my end. Stan? As an asside (again, Hi Stan :-). There was once put forward a proposal to move the protocol definition (an internal interface that the embedded user needs to know about) into its own chapter. Thoughts? Andrew >From msnyder@cygnus.com Sat Apr 01 00:00:00 2000 From: Michael Snyder To: Andrew Hobson Cc: gdb-patches@sourceware.cygnus.com Subject: Re: PATCH for alphaev56-dec-osf5.0: MERGEPID undefined Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A2DA3F.649E@cygnus.com> References: X-SW-Source: 2000-q1/msg00112.html Content-length: 1484 Yes, this is good. Can someone who's working today check it in? Andrew? JimB? Thanks, Michael Andrew Hobson wrote: > > I checked out gdb 5.0 from CVS today and found a minor compilation > issue. In procfs.c, I find: > > /* Provide default composite pid manipulation macros for systems that > don't have threads. */ > > #ifndef PIDGET > #define PIDGET(PID) (PID) > #define TIDGET(PID) (PID) > #define MERGEPID(PID, TID) (PID) > #endif > > ... but in defs.h I find: > > /* On some systems, PIDGET is defined to extract the inferior pid from > an internal pid that has the thread id and pid in seperate bit > fields. If not defined, then just use the entire internal pid as > the actual pid. */ > > #ifndef PIDGET > #define PIDGET(PID) (PID) > #define TIDGET(PID) 0 > #endif > > That leaves MERGEPID undefined. I'm not positive of the correct fix, > but the following patch solves the problem for me. > > Drew > > Index: defs.h > =================================================================== > RCS file: /cvs/src/src/gdb/defs.h,v > retrieving revision 1.1.1.31 > diff -u -p -r1.1.1.31 defs.h > --- defs.h 2000/02/05 07:29:41 1.1.1.31 > +++ defs.h 2000/02/09 20:52:56 > @@ -1218,6 +1218,7 @@ extern int use_windows; > #ifndef PIDGET > #define PIDGET(PID) (PID) > #define TIDGET(PID) 0 > +#define MERGEPID(PID, TID) (PID) > #endif > > /* If under Cygwin, provide backwards compatibility with older >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Patches Subject: [MAINT] J.T. NetBSD maintainer Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DE9D40.D6CD27B4@cygnus.com> X-SW-Source: 2000-q1/msg01039.html Content-length: 100 FYI, I've put J.T. down as the NetBSD maintainer. NetBSD J.T. Conklin jtc@redback.com Andrew >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: BINUTILS Patches , GDB Patches Subject: [PATCH-DEJAGNU] Force DMAP2 register when running d10v tests Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38ABC120.2BF81A6F@cygnus.com> X-SW-Source: 2000-q1/msg00219.html Content-length: 924 Hello, I don't see anyone objecting to the test. I'm just what the commit policy for this part of the repository is. enjoy, Andrew Thu Feb 17 20:24:21 2000 Andrew Cagney * baseboards/d10v.exp (gdb_init_command): Force register DMAP2 to 0x2000 so that the d10v VM matches the simulator. Index: baseboards/d10v.exp =================================================================== RCS file: /cvs/cvsfiles/devo/dejagnu/baseboards/d10v.exp,v retrieving revision 1.12 diff -p -r1.12 d10v.exp *** d10v.exp 1999/09/15 20:49:56 1.12 --- d10v.exp 2000/02/17 09:30:06 *************** set_board_info gcc,no_label_values 1 *** 54,56 **** --- 54,60 ---- # sizeof int != sizeof long. set_board_info gdb,short_int 1 + + # Some d10v:ts3 boards are in ts2-board compatibility mode after a reset. + # Force it into d10v:ts3 internal mode + set_board_info gdb_init_command "set \$dmap2 = 0x2000" >From kevinb@cygnus.com Sat Apr 01 00:00:00 2000 From: Kevin Buettner To: Andrew Cagney Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Shared library fixes for GNU/Linux/PPC port Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <1000225030334.ZM15636@ocotillo.lan> References: <1000225014927.ZM15386@ocotillo.lan> <38B5E8EB.22A8C2A0@cygnus.com> X-SW-Source: 2000-q1/msg00364.html Content-length: 2757 On Feb 25, 1:28pm, Andrew Cagney wrote: > > The differences between ppc_linux_memory_remove_breakpoint () and > > memory_remove_breakpoint () are minor. All that the former does > > that the latter does not is check to make sure that the breakpoint > > location actually contains a breakpoint (trap instruction) prior > > to attempting to write back the old contents. If it does contain > > a trap instruction, we allow the old contents to be written back. > > Otherwise, we silently do nothing. > > > > It seems to me that we ought to be using this version in > > mem-break.c for all other targets (using the mem-break.c > > facilities) too. The only downside that more traffic is generated > > for remote targets since we'll have an extra fetch of a memory > > word each time a breakpoint is removed. > > Rather than make this the default behavour (and introduce extra remote > traffic) would it be better to provide this behavour as a new type of > breakpoint? The shlib stuff could then insert a checking breakpoint. I'll have to study it some more. It sounds like a good idea, but I think we'll have to complicate the breakpoint machinery somewhat to insert these special breakpoints. (For this particular platform, we'd insert the special breakpoint when the address in question is in a PLT.) > I'd also be curious to know if this shlib mechanism is standard for > SVR4/PPC or just Linux. >From my reading of the SVR4/PPC ABI, it looks like it's standard. The following text is especially relevant: For the PowerPC, the procedure linkage table (the .plt section) is ^^ not initialized in the executable or shared object file. Instead, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the link editor simply reserves space for it and the dynamic linker initializes it and manages it according to its own, possibly implementation-dependent needs, subject to the following constraints: 1. The first 18 words (72 bytes) of the procedure linkage table are reserved for use by the dynamic linker. There shall be no branches from the executable or shared object into these first 18 words. 2. If the executable or shared object requires N procedure linkage table entries, the link editor shall reserve 3*N words (12*N bytes) following the 18 reserved words. The first 2*N of these words are the procedure linkage table entries themselves. The static linker directs calls to bytes (72 + (i-1)*8), for i between 1 and N inclusive. The remaining N words (4*N bytes) are reserved for use by the dynamic linker. Kevin >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Jim Blandy , Jimmy Guo , gdb-patches@sourceware.cygnus.com Subject: Re: 2nd try: (patch) hpjyg03: (buildsym|language).[ch] Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B0ABEF.8EDEAA53@cygnus.com> References: <38B0A4A0.D9109A9E@cygnus.com> X-SW-Source: 2000-q1/msg00265.html Content-length: 1693 Andrew Cagney wrote: > > Unfortunatly, there is no prototype for longest_local_hex_string() > visible in buildsym.c. I've ended up commiting the following. Oops! "language.h" depends on "expression.h". I've also checked in the attatched. sorry, Andrew ? 2diffs ? diffs ? old_wait.h ? %redact.run ? netscape.core ? new-gdbarch ? new-gdbarch.h ? new-gdbarch.c Index: ChangeLog =================================================================== RCS file: /cvs/src/src/gdb/ChangeLog,v retrieving revision 1.50 diff -p -r1.50 ChangeLog *** ChangeLog 2000/02/21 02:51:07 1.50 --- ChangeLog 2000/02/21 03:01:59 *************** *** 1,6 **** Mon Feb 21 12:50:57 2000 Andrew Cagney ! * buildsym.c: Include "language.h" for longest_local_hex_string_custom. Mon Feb 21 11:17:18 2000 Andrew Cagney --- 1,6 ---- Mon Feb 21 12:50:57 2000 Andrew Cagney ! * buildsym.c: Include "language.h" and "expression.h" for longest_local_hex_string_custom. Mon Feb 21 11:17:18 2000 Andrew Cagney Index: buildsym.c =================================================================== RCS file: /cvs/src/src/gdb/buildsym.c,v retrieving revision 1.3 diff -p -r1.3 buildsym.c *** buildsym.c 2000/02/21 02:51:07 1.3 --- buildsym.c 2000/02/21 03:02:02 *************** *** 34,39 **** --- 34,40 ---- #include "gdbtypes.h" #include "complaints.h" #include "gdb_string.h" + #include "expression.h" /* For "enum exp_opcode" used by... */ #include "language.h" /* For "longest_local_hex_string_custom" */ /* Ask buildsym.h to define the vars it normally declares `extern'. */ >From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: "Philippe De Muyter" Cc: gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com), dan@cgsoftware.com Subject: Re: regerror link error Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5m8zz8vviv.fsf@jtc.redbacknetworks.com> References: <200003242151.WAA07612@mail.macqel.be> X-SW-Source: 2000-q1/msg01006.html Content-length: 619 >>>>> "Philippe" == Philippe De Muyter writes: Philippe> makes the compilation of gdb fail on my system (m68k-motorola-sysv) : Philippe> [...] Philippe> Actually, I have found a __regerror, but no regerror. How Philippe> can we fix that ? I think the __regerror() function in gnu-regex.c needs to be renamed regerror(). All the other functions in that file are defined without leading double-underscores with a weak_alias() which I assume maps the two forms together in glibc. It certainly looks like the underscores aren't supposed to be there. --jtc -- J.T. Conklin RedBack Networks >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: gdb-patches@sourceware.cygnus.com Subject: [MAINT] Mail address correction Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003010050.e210opc00296@delius.kettenis.local> X-SW-Source: 2000-q1/msg00435.html Content-length: 1126 I noticed that the mail address listed in the MAINTAINERS file wasn't correct (it was missing one character). I changed it to my @gnu.org address since that's likely to be correct as long as my involvement with the GNU project continues, whereas my university address might become invalid if I ever manage to finish my Ph.D. :-). Mark 2000-03-01 Mark Kettenis * MAINTAINERS: Correct my own mail address. Index: MAINTAINERS =================================================================== RCS file: /cvs/src/src/gdb/MAINTAINERS,v retrieving revision 1.15 diff -u -p -r1.15 MAINTAINERS --- MAINTAINERS 2000/03/01 00:28:35 1.15 +++ MAINTAINERS 2000/03/01 00:42:15 @@ -57,7 +57,7 @@ MS Windows (N.T., CE, '00) host & native Chris Faylor cgf@cygnus.com GNU/Linux x86 native Jim Blandy jimb@cygnus.com GNU/Linux PPC native Kevin Buettner kevinb@cygnus.com -hurd native Mark Kettenis kettenis@wins.va.nl +hurd native Mark Kettenis kettenis@gnu.org macos host & native Stan Shebs shebs@apple.com hpux, hp pa native Jeff Law law@cygnus.com UnixWare Threads Nick Duffek nsd@cygnus.com >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] Fix `next'-ing out of a signal handler on Linux/i386 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003082237.e28Mbre06925@delius.kettenis.local> X-SW-Source: 2000-q1/msg00603.html Content-length: 2157 FYI, I committed the attached patch. It is now possible to use the `next' command to step out of a signal handler. Using `step' however is still broken. Making that work will probably require some changes to `infrun.c'. But I'm not sure exactly on how to fix it, and even if I find out, I'm not sure whether I should touch that file before the 5.0 release. Mark 2000-03-08 Mark Kettenis * i386-tdep.c (i386_linux_saved_pc_after_call): New function. * config/i386/tm-linux.h (SAVED_PC_AFTER_CALL): Define to call i386_linux_saved_pc_after_call. Index: i386-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/i386-tdep.c,v retrieving revision 1.5 diff -u -p -r1.5 i386-tdep.c --- i386-tdep.c 2000/03/04 23:37:33 1.5 +++ i386-tdep.c 2000/03/08 22:32:34 @@ -1024,6 +1024,17 @@ i386_linux_sigtramp_saved_sp (struct fra return read_memory_integer (addr + LINUX_SIGCONTEXT_SP_OFFSET, 4); } +/* Immediately after a function call, return the saved pc. */ + +CORE_ADDR +i386_linux_saved_pc_after_call (struct frame_info *frame) +{ + if (frame->signal_handler_caller) + return i386_linux_sigtramp_saved_pc (frame); + + return read_memory_integer (read_register (SP_REGNUM), 4); +} + #endif /* I386_LINUX_SIGTRAMP */ #ifdef STATIC_TRANSFORM_NAME Index: config/i386/tm-linux.h =================================================================== RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v retrieving revision 1.2 diff -u -p -r1.2 tm-linux.h --- config/i386/tm-linux.h 2000/03/04 23:37:33 1.2 +++ config/i386/tm-linux.h 2000/03/08 22:32:34 @@ -154,6 +154,10 @@ extern CORE_ADDR i386_linux_sigtramp_sav extern CORE_ADDR i386_linux_sigtramp_saved_sp (struct frame_info *); +#undef SAVED_PC_AFTER_CALL +#define SAVED_PC_AFTER_CALL(frame) i386_linux_saved_pc_after_call (frame) +extern CORE_ADDR i386_linux_saved_pc_after_call (struct frame_info *); + /* When we call a function in a shared library, and the PLT sends us into the dynamic linker to find the function's real address, we need to skip over the dynamic linker call. This function decides >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: Mark Kettenis Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Linux sigtramp detection code moved to its proper place Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003201529.KAA10589@indy.delorie.com> References: <200003201214.e2KCEYK00493@delius.kettenis.local> X-SW-Source: 2000-q1/msg00816.html Content-length: 414 > What would you suggest for a non-buggy Tar program to do, exactly? > > Simply overwrite the files, possibly asking confirmation from the > user. This shouldn't be a problem, since the DJGPP native port > doesn't need i386-linux-nat.c nor i386-linux-tdep.c. The users don't know whether these files are or aren't needed. So they might overwrite the wrong files, and mess up the build beyond any recognition. >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Jim Blandy Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Don't trim addresses in Dwarf debug info Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38E2B5C6.3451444B@cygnus.com> References: <200003281624.LAA23161@zwingli.cygnus.com> <38E12BD6.E6E357A4@cygnus.com> X-SW-Source: 2000-q1/msg01120.html Content-length: 996 Jim Blandy wrote: > > > > I've committed this: > > > > > > 2000-03-27 Jim Blandy > > > > > > * dwarf2read.c: Revert Andrew Cagney's change of Dec 15, 1997. > > > Don't include "bfd-elf.h". > > > (address_significant_size): Delete variable. > > > (dwarf2_build_psymtabs_hard): Don't set it, or check for > > > consistency between it and the Dwarf 2 compilation unit header > > > address size. > > > (read_address): Don't mask off bits above > > > address_significant_size. > > > * Makefile.in (dwarf2read.o): Don't depend on $(elf_bfd_h). > > > (elf_bfd_h): Remove variable; it's no longer used. > > > > Jim, have you confirmed this doesn't cause any regressions? > > It fixes problems for me, and it fixes the problems Stephane Carrez > reported. It might possibly cause regressions on 64-bit hosts, but > here's why I committed it anyway: What specific problems was it causing you? Andrew >From grante@visi.com Sat Apr 01 00:00:00 2000 From: Grant Edwards To: gdb-patches@sourceware.cygnus.com Subject: Re: Patch for RDI target code to allow user-specified devices Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000221142049.A31223@visi.com> References: <20000221141155.A31206@visi.com> X-SW-Source: 2000-q1/msg00285.html Content-length: 577 > The attached patch against 4.18 sources modifies the RDI target > unix comm code to allow users to specify any device they please > to be used for serial and/or parallel communication with the > target. NB: The patch was generated from 4.18 sources that already contained some other RDI patches. This patch is independant of the others, so it can be applied to clean 4.18 sources, but you'll see a notice about one of the hunks being offset. Not that you want to use the RDI target without those other patches... -- Grant Edwards grante@visi.com >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Patches Subject: [PATCH] MI - post comment Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B0EF83.A7F80182@cygnus.com> X-SW-Source: 2000-q1/msg00275.html Content-length: 137 Just FYI, This still won't appear for a day or so. I'll give people a day or so to chew on it first :-) nice day for it... Andrew >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Mark Kettenis Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Fix for target.c:do_target_signal_to_host() Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38AB1EAD.90CE4860@cygnus.com> References: <200002142116.e1ELGrL06391@delius.kettenis.local> <38A90F10.E61AF586@cygnus.com> <200002161532.e1GFWaf03903@delius.kettenis.local> X-SW-Source: 2000-q1/msg00206.html Content-length: 564 Mark Kettenis wrote: > While adding the comments I noticed that the function will return 32 > for TARGET_SIGNAL_REALTIME_32 even if it doesn't exist, and that (with > my patch) for the other RT signals the upper bound was checked, but > not the lower bound. Not likely to be very problematic, but this is > not right according to the comment at the top of the function. > > I also moved the TARGET_SIGNAL_REALTIME_32 case within the > default: where the other RT signals are handled. I think this > makes it easier to understand the code. Yes. Ok. Andrew >From kettenis@wins.uva.nl Sat Apr 01 00:00: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: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003220949.e2M9nl001746@delius.kettenis.local> X-SW-Source: 2000-q1/msg00899.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 fnasser@cygnus.com Sat Apr 01 00:00:00 2000 From: Fernando Nasser To: Scott Bambrough Cc: gdb-patches@sourceware.cygnus.com, jingham@cygnus.com Subject: Re: Patch for arm_push_arguments Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38CEA1FF.CEA9553@cygnus.com> References: <38CE9C8B.3EC5B7F1@netwinder.org> X-SW-Source: 2000-q1/msg00695.html Content-length: 712 Scott, I have to try it on a few targets, so I need a few days. I will try to run all the tests this week though. Thanks for doing this. Fernando Scott Bambrough wrote: > > Hi guys, > > * arm-tdep.c (arm_push_arguments): Correctly code for converting a > float argument from host format to a target double when preparing the > call frame for a function. > > This works for me. Can you try it out. If it works, let me know and I'll check > it in. > > Scott > -- 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 phdm@macqel.be Sat Apr 01 00:00:00 2000 From: "Philippe De Muyter" To: gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com), dan@cgsoftware.com Subject: regerror link error Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003242151.WAA07612@mail.macqel.be> X-SW-Source: 2000-q1/msg01000.html Content-length: 845 The following patch : 2000-03-22 Daniel Berlin * command.c (apropos_cmd_helper): New function, meat of the apropos command. (apropos_command): New apropos command to search command names/documentation for regular expressions. (_initialize_command): Add the apropos command. makes the compilation of gdb fail on my system (m68k-motorola-sysv) : gcc -g -O2 -W -Wall -o gdb main.o libgdb.a ../bfd/libbfd.a ../readline /libreadline.a ../opcodes/libopcodes.a ./../intl/libintl.a ../libiberty/libibert y.a -lncurses -lm ../libiberty/libiberty.a libgdb.a(command.o): In function `apropos_command': command.c:481: undefined reference to `regerror' collect2: ld returned 1 exit status Actually, I have found a __regerror, but no regerror. How can we fix that ? Philippe >From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000 From: Elena Zannoni To: Mark Kettenis Cc: ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: GDB-5 2000-03-03 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <14527.59027.494800.595466@kwikemart.cygnus.com> References: <38BFBD74.79263683@cygnus.com> <200003031556.e23FuCm00326@delius.kettenis.local> X-SW-Source: 2000-q1/msg00475.html Content-length: 3428 Mark, sigh, that's my fault. I made some changes to the MI disassemble interface and haven't had a chance to update the tests. I'll try to get to that before Monday. Elena Mark Kettenis writes: > Date: Sat, 04 Mar 2000 00:26:12 +1100 > From: Andrew Cagney > > MI tests > > The MI testsuite falls over (lots of dejagnu errors) when the MI wasn't > build. > > Even if I build MI, there are quite a few dejagnu errors: > > ERROR: Undefined command "-file-clear". > UNRESOLVED: gdb.mi/mi-basics.exp: file-clear operation > > FAIL: gdb.mi/mi-console.exp: Hello message (timeout) > ... > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble from pc assembly only > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main assembly only > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble range assembly only > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble callee2 assembly only > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble callee2 assembly mixed > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble range assembly mixed > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble callee2 assembly mixed > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble bogus arguments > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble wrong num of args (3) > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble wrong num of args (2) > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble wrong num of args (1) > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble from pc two lines - assembly only > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main 1 line - assembly only > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main zero lines - assembly only > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble lines bigger than range - assembly only > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble lines less than range - assembly only > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble from pc two lines - assembly mixed > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main 1 line - assembly mixed > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main zero lines - assembly mixed > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble lines bigger than range - assembly mixed > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble lines less than range - assembly mixed > ... > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble from pc assembly mixed > ... > FAIL: gdb.mi/mi-simplerun.exp: exec-finish (timeout) > FAIL: gdb.mi/mi-simplerun.exp: continue to end (1) > ... > FAIL: gdb.mi/mi-stack.exp: stack args listing 0 > ... > FAIL: gdb.mi/mi-stack.exp: stack args listing 1 > ... > FAIL: gdb.mi/mi-stack.exp: stack info-depth > ... > FAIL: gdb.mi/mi-stack.exp: stack info-depth 99 > ... > FAIL: gdb.mi/mi-var-child.exp: update all vars psnp->next->long_ptr (and 1.long_ptr) changed > ... > FAIL: gdb.mi/mi-var-cmd.exp: update all vars: changed FIXME > ... > FAIL: gdb.mi/mi-watch.exp: list of watchpoints > ... > FAIL: gdb.mi/mi-watch.exp: wp out of scope (2) > > > Here's the summary for i586-pc-linux-gnu: > > === gdb Summary === > > # of expected passes 6827 > # of unexpected failures 45 > # of expected failures 212 > # of unresolved testcases 1 > /mnt/hdb4/obj/src/gdb/testsuite/../../gdb/gdb version 20000204 -nx > > The majority of all those unexpected failures is because of the MI > problems. > > Mark >From nsd@cygnus.com Sat Apr 01 00:00:00 2000 From: nsd@cygnus.com To: john@feith.com Cc: cgf@cygnus.com, eliz@delorie.com, gdb-patches@sourceware.cygnus.com, jimb@cygnus.com, msnyder@cygnus.com Subject: Re: GDB 4.17 Patch for stack aligned i386 code Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003250054.AAA07709@nog.bosbc.com> References: <200003250030.TAA14328@jwlab.FEITH.COM> X-SW-Source: 2000-q1/msg01015.html Content-length: 314 >I'm not sure what I still have laying around other than a very old patch >for GCC. The idea is to handle a prologue which looks like: Thanks, that makes it clear. At the moment, I don't think my patch would handle that correctly. The "tightening up" that I mentioned earlier might do the trick, though. Nick >From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: "Peter.Schauer" Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Problem with gdb/objfiles.c and --with-mmalloc + fix Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <200002232157.WAA26169@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-q1/msg00382.html Content-length: 325 > I have used --with-mmalloc with GDB configure for a long time to get sort of > a poor man's purify. Unfortunately gdb/objfiles.c suffered some bitrot > during the last year, here is a fix: Looks like a straightforward bugfix to me. Maintainer is JimB (if objfiles.c is part of "generic symtabs") or Andrew/Stan (if not). >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: ac131313@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: GDB 5 2000-03-29 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003312306.SAA07143@indy.delorie.com> References: <38E17D2C.F7EB65B9@cygnus.com> X-SW-Source: 2000-q1/msg01141.html Content-length: 1747 > For the watchpoint patches, if at least some have been addressed, I'd > like to put the rest off. All of them are addressed now. See below. > Watch point related patches (Eli Zaretskii, Michael Snyder, ???) > > Eli writes: This doesn't include the watchpoint-related patches I sent > beginning with August or September, and mentioned them again three > weeks ago. Here again are the pointers to the relevant messages: > > Hardware breakpoints and watchpoints: patches > http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00173.html > > Re: Hardware breakpoints and watchpoints: patches > http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00204.html > > Re: Hardware breakpoints and watchpoints: patches > http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00200.html > > Hardware watchpoints for bitfields > http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00201.html Michael posted about a week ago several messages saying that my patches were checked in. The relevant messages are: http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00873.html http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00840.html So I'm quite happy with this (thanks, Michael!). > +MI documentation in GDB user guide. (Andrew Cagney, Elena Zannoni, > +Stan Shebs, anyone else?) > + > +> (Are there plans to make gdbmi.texi be part of the manual as well?) If no one objects, I can submit changes to incorporate gdbmi.texi into the manual. > +[PATCH] GDB command-line switches and annotations docs > + http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00639.html I believe this is already checked in (I commited these patches two weeks ago). See http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00739.html >From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: Eli Zaretskii Cc: ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] GDB command-line switches and annotations docs Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38CFF074.B275A986@apple.com> References: <14537.5048.99180.910863@kwikemart.cygnus.com> <200003101809.NAA22092@indy.delorie.com> <14537.18119.116000.442262@kwikemart.cygnus.com> <200003120754.CAA24393@indy.delorie.com> <14539.49127.700844.807495@kwikemart.cygnus.com> <200003151414.JAA01131@indy.delorie.com> X-SW-Source: 2000-q1/msg00729.html Content-length: 560 Eli Zaretskii wrote: > > > > 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? > > > > Perfect, thanks! > > I attach below the changes which address the above, and also what Stan > said about moving the Annotations chapter before the appendices. > These changes are to be applied _on top_ of those I sent in the > previous message. > > Is it okay to commit this and the previous patch? Go for it! Stan >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: RFA: NetBSD/i386 core dump support Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5msnxhqmiq.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00957.html Content-length: 2618 I submit the enclosed patch for approval. This change enables core dump support on NetBSD/i386 and adds floating point register support to fetch_core_registers(). 2000-03-23 J.T. Conklin * i386nbsd-nat.c (fetch_core_registers): Read fp registers. (i386nbsd_core_fns, _initialize_i386nbsd_nat): Added. Index: i386nbsd-nat.c =================================================================== RCS file: /cvs/src/src/gdb/i386nbsd-nat.c,v retrieving revision 1.1 diff -c -3 -p -r1.1 i386nbsd-nat.c *** i386nbsd-nat.c 2000/03/22 01:36:31 1.1 --- i386nbsd-nat.c 2000/03/23 23:35:03 *************** store_inferior_registers (regno) *** 152,158 **** struct md_core { struct reg intreg; ! struct fpreg freg; }; void --- 152,158 ---- struct md_core { struct reg intreg; ! struct env387 freg; }; void *************** fetch_core_registers (core_reg_sect, cor *** 167,172 **** /* integer registers */ memcpy (®isters[REGISTER_BYTE (0)], &core_reg->intreg, sizeof (struct reg)); /* floating point registers */ ! /* XXX */ } --- 167,209 ---- /* integer registers */ memcpy (®isters[REGISTER_BYTE (0)], &core_reg->intreg, sizeof (struct reg)); + /* floating point registers */ ! RF (FP0_REGNUM, core_reg->freg.regs[0]); ! RF (FP0_REGNUM + 1, core_reg->freg.regs[1]); ! RF (FP0_REGNUM + 2, core_reg->freg.regs[2]); ! RF (FP0_REGNUM + 3, core_reg->freg.regs[3]); ! RF (FP0_REGNUM + 4, core_reg->freg.regs[4]); ! RF (FP0_REGNUM + 5, core_reg->freg.regs[5]); ! RF (FP0_REGNUM + 6, core_reg->freg.regs[6]); ! RF (FP0_REGNUM + 7, core_reg->freg.regs[7]); ! ! RF (FCTRL_REGNUM, core_reg->freg.control); ! RF (FSTAT_REGNUM, core_reg->freg.status); ! RF (FTAG_REGNUM, core_reg->freg.tag); ! RF (FCS_REGNUM, core_reg->freg.code_seg); ! RF (FCOFF_REGNUM, core_reg->freg.eip); ! RF (FDS_REGNUM, core_reg->freg.operand_seg); ! RF (FDOFF_REGNUM, core_reg->freg.operand); ! RF (FOP_REGNUM, core_reg->freg.opcode); ! ! registers_fetched (); ! } ! ! /* Register that we are able to handle i386nbsd core file formats. ! FIXME: is this really bfd_target_unknown_flavour? */ ! ! static struct core_fns i386nbsd_core_fns = ! { ! bfd_target_unknown_flavour, /* core_flavour */ ! default_check_format, /* check_format */ ! default_core_sniffer, /* core_sniffer */ ! fetch_core_registers, /* core_read_registers */ ! NULL /* next */ ! }; ! ! void ! _initialize_i386nbsd_nat () ! { ! add_core_fns (&i386nbsd_core_fns); } -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Mark Kettenis Cc: gdb-patches@sourceware.cygnus.com Subject: Re: GDB-5 2000-03-03 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C08FC8.CF5D627D@cygnus.com> References: <38BFBD74.79263683@cygnus.com> <200003031714.e23HEC900400@delius.kettenis.local> X-SW-Source: 2000-q1/msg00495.html Content-length: 1683 Mark Kettenis wrote: > There are two issue's in the generic x86 code that I'd like to > address: I've added these to the ``Nice to have'' section. > The current code doesn't run on Linux 2.x (remember the message you > just sent to Tom): > > http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00294.html Added. > The FP control registers contain some really weird numbers since the > reserved bits aren't masked of. Patch: > > http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00375.html Added. > Signal tramplines aren't recognized. Patch: > > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00059.html Added. > Programs run under GDB have SIGCHLD masked. No patch yet. Added to ``nice to have''. Can be worked around. > This seems to happen on Solaris too. Note added. > This has been fixed: Yes, I noticed that. That's why I moved it to old problems :-) > The testsuite runs OK, but contains a very limited number of tests. I > recently discovered that the thread_db code doesn't handle threads > that exit. See the following URL for more info: > > http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00525.html > > I would consider this a pretty critical bug. I've added it (I can't comment on the seriousness of the specific bug). More serious is the lack of proper testing of the thread code. I'd rather see effort put into improving the testsuite ready for 5.1 than fixing bugs in 5.0. > Of course there is the issue of "which alpha release of glibc 2.1.3?". > Personally I (kingdon) am most worried about the one in Red Hat Linux > 6.2beta. > > There is an official glibc 2.1.3 release now. Thanks, Andrew >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Stephane Carrez Cc: 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: <38BB5463.D6E5B75C@cygnus.com> References: <38B2F3D3.54CF0AF0@worldnet.fr> X-SW-Source: 2000-q1/msg00412.html Content-length: 2194 Stephane Carrez wrote: > > Hi! > > The following patch fixes GDB dwarf-2 reader to support 16-bit address > targets. > > In 'dwarf2_build_psymtabs_hard' there was a hack to guess the size of the > target address. We were using the bfd 'elf_size_info::arch_size' member. > This corresponds to the ELF file arch size, not the target address size. > I suggest to use 'bfd_arch_bits_per_address' which really corresponds to > what we need. > > Then, in 'read_address', we just have to read 2-bytes addresses. > > I've been using this fix for a while with the 68HC11 port. > > Can you integrate it? > > Thanks, > Stephane > > 2000-02-22 Stephane Carrez > > * dwarf2read.c (dwarf2_build_psymtabs_hard): Use > bfd_arch_bits_per_address to get the size of addresses. FYI, I've applied this bit: > (read_address): Read 16-bits addresses. As for the change: > - address_significant_size = get_elf_backend_data (abfd)->s->arch_size / 8; > + address_significant_size = bfd_arch_bits_per_address (abfd) / 8; I'm not so sure. Does bfd_arch_bits_per_address() return 16 while the elf data arch_size indicate something else (elf32 vs elf16?) I've attatched some references to when a similar problem was discussed for a 64 bit target with 32 bit ELF binaries. Jim? Andrew http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00267.html http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00263.html Tue Feb 29 15:14:56 2000 Andrew Cagney From 2000-02-22 Stephane Carrez : * dwarf2read.c (read_address): Read 16-bits addresses. Index: dwarf2read.c =================================================================== RCS file: /cvs/src/src/gdb/dwarf2read.c,v retrieving revision 1.2 diff -p -r1.2 dwarf2read.c *** dwarf2read.c 2000/02/14 04:37:06 1.2 --- dwarf2read.c 2000/02/29 05:06:26 *************** read_address (abfd, buf) *** 3487,3492 **** --- 3487,3495 ---- switch (address_size) { + case 2: + retval = bfd_get_16 (abfd, (bfd_byte *) buf); + break; case 4: retval = bfd_get_32 (abfd, (bfd_byte *) buf); break; >From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: Andrew Cagney Cc: 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/msg00539.html Content-length: 1877 > 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. Strikes me as a bad idea. Or to put it another way, designing a hypothetical elf16 format seems like something you'd do only if you had pretty compelling reasons, not just to fix a GDB bug which can be fixed in much simpler ways. > Is there any reason why s->arch_size isn't 16 in your case? Hmm, that's an interesting question. Some uses of arch_size in BFD seem to decide alignment of pointers (in .got, .rela and other sections in bfd/elflink.c) but others seem to be based on elf32 vs. elf64 (.stabsstr section in bfd/elf.c). GDB doesn't seem to use arch_size beyond the one usage we are discussing. I didn't check binutils. I think it is possible that bfd/elflink.c should be referring to bfd_arch_bits_per_address. The whole address_significant_size code in dwarf2read.c strikes me as a rather ugly kludge to work around bugs elsewhere in the tool chain. If someone is supplying a 32 bit pointer to GDB on a 16 bit target, shouldn't the rest of the tool chain be responsible for making sure the high bits are zero rather than expecting GDB to mask it off? Granted there might be complications here, like there are cases on MIPS where we treat an address as signed rather than unsigned, but I'm also pretty clear on whether that is actually design or just a bug. I could be wrong/persuadable, of course, and perhaps someone has a better idea of all this (in which case I'd suggest commenting arch_size at bfd/elf-bfd.h and/or expanding comments at bfd_arch_bits_per_address in bfd/archures.c). Or to put it another way, specifically what went wrong on the 68HC11 if you didn't change dwarf2read.c? If it was just the "Dwarf Error: bad address size" error, what happens if you just comment out that check? >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Elena Zannoni Cc: nsd@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Patch: catch_errors() bug fixes and speedups Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B2FC43.DB202309@cygnus.com> References: <200002112031.UAA02868@nog.bosbc.com> <200002222010.UAA05801@nog.bosbc.com> <14514.63567.180178.977613@kwikemart.cygnus.com> X-SW-Source: 2000-q1/msg00308.html Content-length: 279 Elena Zannoni wrote: > > Looks great. Thanks Nick, for taking the time to fix this. > It can certainly go in, unless Andrew has some objections. Not likely. catch_errors() always was a nasty piece of work. This cleanup makes it cleaner, faster, simpler..... nice, Andrew >From hjl@lucon.org Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: Jim Kingdon Cc: toddpw@windriver.com, kettenis@wins.uva.nl, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Another revised patch for dlclose Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000308103740.A3530@lucon.org> References: <200003080849.AAA18417@alabama.wrs.com> <200003081441.JAA02876@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00599.html Content-length: 4624 On Wed, Mar 08, 2000 at 09:41:00AM -0500, Jim Kingdon wrote: > > 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. Here is a new patch. It seems to work with the testcase. Any comments? H.J. ---- 2000-03-08 H.J. Lu Inspired by patches from Sam Lantinga (slouken@devolution.com): * solib.c (solib_verify): New function. Unload the shared object when it is deleted and dump symbols from the unloaded shared object. * solib.h (SOLIB_VERIFY): New. Defined as solib_verify. * infrun.c (handle_inferior_event): Also call SOLIB_VERIFY () if it is defined when we hit the internal debug breakpoint for shared libraries in the dynamic linker. Index: solib.c =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/solib.c,v retrieving revision 1.1.1.4 retrieving revision 1.7 diff -u -p -r1.1.1.4 -r1.7 --- solib.c 2000/03/07 18:42:17 1.1.1.4 +++ solib.c 2000/03/08 18:36:11 1.7 @@ -950,6 +950,84 @@ open_symbol_file_object (arg) return 1; } #endif /* SVR4_SHARED_LIBS */ + +/* + +GLOBAL FUNCTION + + solib_verify -- check solib list consistency and dump symbols + from unloaded shared objects + +SYNOPSIS + + void solib_verify (void) + +DESCRIPTION + + This module is called whenever we hit a dynamic linker + breakpoint and allows us to check the consistency of our shared + object list and unload objects which are no longer valid in the + in the inferior. Without this, dynamic unlinking of objects + could crash us. This function should only be called when we + hit the internal debug breakpoint for shared libraries in the + dynamic linker. + + */ + +void +solib_verify (void) +{ +#ifdef SVR4_SHARED_LIBS + if (debug_base) + { + static int solib_unloading = 0; + + read_memory (debug_base, (char *) &debug_copy, + sizeof (struct r_debug)); + if (debug_copy.r_state == RT_DELETE) + solib_unloading = 1; + else if (solib_unloading && debug_copy.r_state == RT_CONSISTENT) + { + struct so_list *so = NULL, *next, *so_next, *saved; + + /* Get the current list of loaded shared libraries. */ + saved = so_list_head; + so_list_head = NULL; + while ((so = find_solib (so)) != NULL); + so = so_list_head; + so_list_head = saved; + + /* We compare the current list against what we have. */ + for (next = so_list_head; next; next = next->next) + { + for (so_next = so; so_next; so_next = so_next->next) + if (strcmp (so_next->so_name, next->so_name) == 0) + break; + + if (!so_next) + { + /* We didn't find it in the current list. Unload it. + Since the dynamic linker can only unload one + shared library at a time, we stop here. Also + free_objfile () will call clear_solib (). It will + clear everything for us. */ + free_objfile (next->objfile); + break; + } + } + + /* Free the current list of loaded shared libraries. */ + for (so_next = so; so_next; so_next = next) + { + next = so_next->next; + free (so_next); + } + + solib_unloading = 0; + } + } +#endif /* SVR4_SHARED_LIBS */ +} /* Index: solib.h =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/solib.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -p -r1.1.1.1 -r1.2 --- solib.h 1999/09/09 00:38:38 1.1.1.1 +++ solib.h 2000/03/07 21:55:11 1.2 @@ -37,6 +37,14 @@ clear_solib PARAMS ((void)); extern void solib_add PARAMS ((char *, int, struct target_ops *)); +/* Called to check solib list consistency and dump symbols from + unloaded shared objects. */ + +#define SOLIB_VERIFY() solib_verify () + +extern void +solib_verify PARAMS ((void)); + /* Function to be called when the inferior starts up, to discover the names of shared libraries that are dynamically linked, the base addresses to which they are linked, and sufficient information to read in their symbols Index: infrun.c =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/infrun.c,v retrieving revision 1.1.1.6 retrieving revision 1.2 diff -u -p -r1.1.1.6 -r1.2 --- infrun.c 2000/03/07 18:42:13 1.1.1.6 +++ infrun.c 2000/03/07 21:55:11 1.2 @@ -2416,6 +2416,9 @@ handle_inferior_event (struct execution_ /* Switch terminal for any messages produced by breakpoint_re_set. */ target_terminal_ours_for_output (); +#ifdef SOLIB_VERIFY + SOLIB_VERIFY (); +#endif SOLIB_ADD (NULL, 0, NULL); target_terminal_inferior (); } >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Jason Molenda Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Patch to change gdb's behavior for Makefile target 'diststuff' Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38AA26ED.DAC914DC@cygnus.com> References: <20000215200720.A20254@cygnus.com> X-SW-Source: 2000-q1/msg00171.html Content-length: 1603 Jason Molenda wrote: Approved. Andrew > I am trying to steal the binutils snapshot script. That script does > a 'make diststuff' at the top-level, which does all sorts of stuff. > Diststuff in gdb does a 'all-doc' in the doc/ subdirectory and the > Makefile there tries to run tex to generate some DVI files. > > I want gdb/Makefile.in to run 'diststuff' in the doc/ directory, and > I want 'diststuff' in the doc/ directory to just generate the info > files. > > This mirrors the binutils behavior. > > Jason > > Index: Makefile.in > =================================================================== > RCS file: /cvs/src/src/gdb/Makefile.in,v > retrieving revision 1.3 > diff -u -p -r1.3 Makefile.in > --- Makefile.in 2000/02/09 08:52:44 1.3 > +++ Makefile.in 2000/02/16 04:03:49 > @@ -872,7 +872,7 @@ do-maintainer-clean: > subdir_do > > diststuff: $(DISTSTUFF) > - cd doc; $(MAKE) $(MFLAGS) all-doc > + cd doc; $(MAKE) $(MFLAGS) diststuff > > subdir_do: force > @for i in $(DODIRS); do \ > Index: doc/Makefile.in > =================================================================== > RCS file: /cvs/src/src/gdb/doc/Makefile.in,v > retrieving revision 1.1.1.5 > diff -u -p -r1.1.1.5 Makefile.in > --- Makefile.in 2000/02/07 00:19:39 1.1.1.5 > +++ Makefile.in 2000/02/16 04:03:53 > @@ -100,6 +100,7 @@ dvi: gdb.dvi gdbint.dvi stabs.dvi refcar > ps: gdb.ps gdbint.ps stabs.ps refcard.ps > html: gdb_toc.html gdbint_toc.html stabs_toc.html > all-doc: info dvi ps > +diststuff: info > > install-info: info > for i in *.info* ; do \ >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: jtc@redback.com Cc: Kevin Buettner , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Minor change to gdb/doc/agentexpr.texi Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38AC8B93.6A1F0028@cygnus.com> References: <1000216043742.ZM2605@ocotillo.lan> <5mk8k3tv6h.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00235.html Content-length: 820 "J.T. Conklin" wrote: > > >>>>> "Kevin" == Kevin Buettner writes: > Kevin> I've just committed a minor change (see below) to > Kevin> gdb/doc/agentexpr.texi. Intel does not want us to use "Merced" > Kevin> in the gdb documentation. And when referring to their next > Kevin> generation architecture, we must use "IA-64". No other variant > Kevin> is acceptable. > > I have no problem with the change per se, but the implication that > some other party can dictate what is, and what is not, "acceptable" > to put in FSF manuals is disturbing. In this case, while I think it is important I dont think it is a concern. Where a tradmark name is used in a published document it should be used correctly. (Unless of course the FSF has some policy where it refuses to recognize trademarks.) Andrew >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: eliz@is.elta.co.il Cc: jimb@zwingli.cygnus.com, kevinb@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Linux sigtramp detection code moved to its proper place Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003201214.e2KCEYK00493@delius.kettenis.local> References: <200003162241.RAA19616@zwingli.cygnus.com> <1000316225504.ZM3009@ocotillo.lan> <200003182227.RAA07058@indy.delorie.com> <200003192248.e2JMm1H00626@delius.kettenis.local> <200003201002.FAA09374@indy.delorie.com> X-SW-Source: 2000-q1/msg00813.html Content-length: 1004 Date: Mon, 20 Mar 2000 05:02:58 -0500 (EST) From: Eli Zaretskii > How about i386linux-tdep.c, for example? > > Yuck, that's ugly! How is it uglier than i386gnu-nat.c? I want either i386-linux-nat.c and i386-linux-tdep.c or i386linux-nat.c and i386linux-tdep.c, but *not* a mixture of those. If I ever see the need for target dependent code for the Hurd/i386 it will end up in i386gnu-tdep.c (which isn't 8.3 unique either). > Is it really important that these Linux-specific files are correctly > extracted on MS-DOS? I believe your argument was about buggy tar > programs floating around, but I don't think it is too much too ask > people to fix their tar before trying to build GDB. What would you suggest for a non-buggy Tar program to do, exactly? Simply overwrite the files, possibly asking confirmation from the user. This shouldn't be a problem, since the DJGPP native port doesn't need i386-linux-nat.c nor i386-linux-tdep.c. Mark >From kevinb@cygnus.com Sat Apr 01 00:00:00 2000 From: Kevin Buettner To: gdb-patches@sourceware.cygnus.com Cc: Michael Snyder Subject: [PATCH RFA] linux-thread.c, lin-thread.c changes Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <1000324204825.ZM4807@ocotillo.lan> X-SW-Source: 2000-q1/msg00996.html Content-length: 2748 I request approval for committing the changes below. The lines that read #if TARGET_PTR_BIT > TARGET_INT_BIT cause a compilation error on linux/ia64 due to the fact that TARGET_PTR_BIT and TARGET_INT_BIT are computed at runtime for the IA-64 architecture. (When we get around to multi-arching the other linux ports, they'll have the same problem.) * linux-thread.c, lin-thread.c (save_inferior_pid, restore_inferior_pid): Don't do compile time comparison of TARGET_PTR_BIT and TARGET_INT_BIT. Index: linux-thread.c =================================================================== RCS file: /cvs/src/src/gdb/linux-thread.c,v retrieving revision 1.5 diff -u -p -r1.5 linux-thread.c --- linux-thread.c 2000/03/18 01:56:31 1.5 +++ linux-thread.c 2000/03/24 20:36:43 @@ -378,25 +378,22 @@ linuxthreads_find_trap (pid, stop) /* Cleanup stub for save_inferior_pid. */ static void -restore_inferior_pid (arg) - void *arg; +restore_inferior_pid (void *arg) { -#if TARGET_PTR_BIT > TARGET_INT_BIT - inferior_pid = (int) ((long) arg); -#else - inferior_pid = (int) arg; -#endif + int *saved_pid_ptr = arg; + inferior_pid = *saved_pid_ptr; + free (arg); } /* Register a cleanup to restore the value of inferior_pid. */ static struct cleanup * -save_inferior_pid () +save_inferior_pid (void) { -#if TARGET_PTR_BIT > TARGET_INT_BIT - return make_cleanup (restore_inferior_pid, (void *) ((long) inferior_pid)); -#else - return make_cleanup (restore_inferior_pid, (void *) inferior_pid); -#endif + int *saved_pid_ptr; + + saved_pid_ptr = xmalloc (sizeof (int)); + *saved_pid_ptr = inferior_pid; + return make_cleanup (restore_inferior_pid, saved_pid_ptr); } static void Index: lin-thread.c =================================================================== RCS file: /cvs/src/src/gdb/lin-thread.c,v retrieving revision 1.2 diff -u -p -r1.2 lin-thread.c --- lin-thread.c 2000/02/09 08:52:46 1.2 +++ lin-thread.c 2000/03/24 20:36:47 @@ -658,21 +658,19 @@ init_thread_db_library () static struct cleanup * save_inferior_pid (void) { -#if TARGET_PTR_BIT > TARGET_INT_BIT - return make_cleanup (restore_inferior_pid, (void *) ((long) inferior_pid)); -#else - return make_cleanup (restore_inferior_pid, (void *) inferior_pid); -#endif + int *saved_pid_ptr; + + saved_pid_ptr = xmalloc (sizeof (int)); + *saved_pid_ptr = inferior_pid; + return make_cleanup (restore_inferior_pid, saved_pid_ptr); } static void -restore_inferior_pid (void *saved_pid) +restore_inferior_pid (void *arg) { -#if TARGET_PTR_BIT > TARGET_INT_BIT - inferior_pid = (int) ((long) saved_pid); -#else - inferior_pid = (int) saved_pid; -#endif + int *saved_pid_ptr = arg; + inferior_pid = *saved_pid_ptr; + free (arg); } /*