From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: "Rudy Folden" , Subject: Re: [RFA] Change malloc to xmalloc Date: Tue, 23 Jan 2001 14:59:00 -0000 Message-id: <1010123225905.ZM31728@ocotillo.lan> References: <000501c08589$bc0a9dc0$3b1110ac@wirespeed.com> X-SW-Source: 2001-01/msg00217.html On Jan 23, 4:13pm, Rudy Folden wrote: > Changed calls within gdb from malloc to xmalloc. Of course, the file > utils.c can not be changed since it implements xmalloc via a call to mmalloc > which in turn calls the real malloc. I'm wondering if the NEED_DECLARATION_MALLOC stuff from defs.h ought to be left alone, but moved to utils.c (which is the only place from which malloc() is actually called). [...] > --- 962,968 ---- > #ifndef MALLOC_INCOMPATIBLE > > #ifdef NEED_DECLARATION_MALLOC > ! extern PTR xmalloc (); > #endif > > #ifdef NEED_DECLARATION_REALLOC Also, when you change something with PTR in it, just change the ``PTR'' to ``void *''. [...] > Index: stuff.c > =================================================================== > RCS file: /cvs/src/src/gdb/stuff.c,v > retrieving revision 1.2 I think you should leave stuff.c alone. It's a stand-alone program that doesn't link in utils.c. (Actually, I think stuff.c ought to be marked obsolete and eventually deleted.) [...] > *** valprint.c 2000/12/15 01:01:50 1.9 > --- valprint.c 2001/01/23 21:01:45 > *************** print_decimal_chars (struct ui_file *str > *** 886,892 **** > * as the base 16 number, which is 2 digits per byte. > */ > decimal_len = len * 2 * 2; > ! digits = (unsigned char *) malloc (decimal_len); > if (digits == NULL) > error ("Can't allocate memory for conversion to decimal."); > > --- 886,892 ---- > * as the base 16 number, which is 2 digits per byte. > */ > decimal_len = len * 2 * 2; > ! digits = (unsigned char *) xmalloc (decimal_len); > if (digits == NULL) > error ("Can't allocate memory for conversion to decimal."); Again, while you're at it, I think the typecast can go away. > Index: config/pa/xm-hppah.h > =================================================================== > RCS file: /cvs/src/src/gdb/config/pa/xm-hppah.h,v > retrieving revision 1.2 > diff -c -3 -p -r1.2 xm-hppah.h > *** xm-hppah.h 2000/05/28 01:12:37 1.2 > --- xm-hppah.h 2001/01/23 21:01:47 > *************** > *** 40,46 **** > > #define MALLOC_INCOMPATIBLE > > ! extern void *malloc (size_t); > > extern void *realloc (void *, size_t); > > --- 40,46 ---- > > #define MALLOC_INCOMPATIBLE > > ! extern void *xmalloc (size_t); > > extern void *realloc (void *, size_t); We shouldn't need to declare xmalloc() here at all. (Nor realloc() either.) >From jimb@zwingli.cygnus.com Tue Jan 23 16:21:00 2001 From: Jim Blandy To: gdb-patches@sources.redhat.com Subject: [PATCH]: Read `const' and `volatile' in Dwarf 2 info Date: Tue, 23 Jan 2001 16:21:00 -0000 Message-id: <200101240021.TAA25079@zwingli.cygnus.com> X-SW-Source: 2001-01/msg00218.html Content-length: 1869 2001-01-23 Jim Blandy * dwarf2read.c (read_tag_const_type, read_tag_volatile_type): Implement these correctly, using make_cv_type. Index: dwarf2read.c =================================================================== RCS file: /cvs/src/src/gdb/dwarf2read.c,v retrieving revision 1.20 diff -c -r1.20 dwarf2read.c *** dwarf2read.c 2000/12/15 01:01:46 1.20 --- dwarf2read.c 2001/01/24 00:15:35 *************** *** 2653,2678 **** read_tag_const_type (struct die_info *die, struct objfile *objfile, const struct comp_unit_head *cu_header) { if (die->type) { return; } ! complain (&dwarf2_const_ignored); ! die->type = die_type (die, objfile, cu_header); } static void read_tag_volatile_type (struct die_info *die, struct objfile *objfile, const struct comp_unit_head *cu_header) { if (die->type) { return; } ! complain (&dwarf2_volatile_ignored); ! die->type = die_type (die, objfile, cu_header); } /* Extract all information from a DW_TAG_string_type DIE and add to --- 2653,2682 ---- read_tag_const_type (struct die_info *die, struct objfile *objfile, const struct comp_unit_head *cu_header) { + struct type *base_type; + if (die->type) { return; } ! base_type = die_type (die, objfile, cu_header); ! die->type = make_cv_type (1, TYPE_VOLATILE (base_type), base_type, 0); } static void read_tag_volatile_type (struct die_info *die, struct objfile *objfile, const struct comp_unit_head *cu_header) { + struct type *base_type; + if (die->type) { return; } ! base_type = die_type (die, objfile, cu_header); ! die->type = make_cv_type (TYPE_CONST (base_type), 1, base_type, 0); } /* Extract all information from a DW_TAG_string_type DIE and add to >From jtc@redback.com Tue Jan 23 16:30:00 2001 From: jtc@redback.com (J.T. Conklin) To: gdb-patches@sourceware.cygnus.com Subject: [PATCH]: memory region attribute nits Date: Tue, 23 Jan 2001 16:30:00 -0000 Message-id: <5md7dd6bcd.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00219.html Content-length: 2487 It was brought to my attention that today's checkin of memory region attribute support broke builds on some targets because their memory transfer functions had not been updated. Many appologies for this oversight. While I try to build GDB on many architectures, most are embedded targets. This change has now been committed. --jtc 2001-01-23 J.T. Conklin * lin-lwp.c (lin_lwp_xfer_memory): Add attrib argument. * thread-db.c (thread_db_xfer_memory): Likewise. Index: thread-db.c =================================================================== RCS file: /cvs/src/src/gdb/thread-db.c,v retrieving revision 1.3 diff -c -r1.3 thread-db.c *** thread-db.c 2000/12/27 21:37:57 1.3 --- thread-db.c 2001/01/24 00:25:54 *************** *** 753,758 **** --- 753,759 ---- static int thread_db_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write, + struct mem_attrib *attrib, struct target_ops *target) { struct cleanup *old_chain = save_inferior_pid (); *************** *** 768,774 **** inferior_pid = lwp_from_thread (inferior_pid); } ! xfer = target_beneath->to_xfer_memory (memaddr, myaddr, len, write, target); do_cleanups (old_chain); return xfer; --- 769,775 ---- inferior_pid = lwp_from_thread (inferior_pid); } ! xfer = target_beneath->to_xfer_memory (memaddr, myaddr, len, write, attrib, target); do_cleanups (old_chain); return xfer; Index: lin-lwp.c =================================================================== RCS file: /cvs/src/src/gdb/lin-lwp.c,v retrieving revision 1.4 diff -c -r1.4 lin-lwp.c *** lin-lwp.c 2000/12/15 01:01:48 1.4 --- lin-lwp.c 2001/01/24 00:25:56 *************** *** 935,940 **** --- 935,941 ---- static int lin_lwp_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write, + struct mem_attrib *attrib, struct target_ops *target) { struct cleanup *old_chain = save_inferior_pid (); *************** *** 943,949 **** if (is_lwp (inferior_pid)) inferior_pid = GET_LWP (inferior_pid); ! xfer = child_xfer_memory (memaddr, myaddr, len, write, target); do_cleanups (old_chain); return xfer; --- 944,950 ---- if (is_lwp (inferior_pid)) inferior_pid = GET_LWP (inferior_pid); ! xfer = child_xfer_memory (memaddr, myaddr, len, write, attrib, target); do_cleanups (old_chain); return xfer; -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Tue Jan 23 19:59:00 2001 From: Andrew Cagney To: Gabriel Dos Reis Cc: gdb-patches@sources.redhat.com, dosreis@cmla.ens-cachan.fr, bkoz@redhat.com, SID Discussion Subject: Re: DejaGnu PATCH to lib/dg.exp: enhance support for "exotic" dir-names Date: Tue, 23 Jan 2001 19:59:00 -0000 Message-id: <3A6E5292.FF7C054@cygnus.com> References: X-SW-Source: 2001-01/msg00220.html Content-length: 479 GDB's main concern is that any changes made to src/dejagnu don't break the GDB testsuite. Have you done a before/after run of the GDB testsuite to confirm that the results don't change? Given you're playing with file names, someone will probably need to check this on both unix and cygwin. Don't forget that anything committed to src/dejagnu and not also sent to the official maintainer may be lost if the official dejagnu is ever merged back into this old snapshot. Andrew >From ac131313@cygnus.com Wed Jan 24 00:00:00 2001 From: Andrew Cagney To: jtc@redback.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: memory region attribute nits Date: Wed, 24 Jan 2001 00:00:00 -0000 Message-id: <3A6E8749.2935E8AA@cygnus.com> References: <5md7dd6bcd.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00222.html Content-length: 977 J.T., A ramble, As an unofficial guideline, I'd be most worried about the targets I've listed as buildable in the MAINTAINERS file. If there is a target that is known to not build then I personally think it is questionable to expect you to get your changes right for that target. As an example the SOFTWARE_SINGLE_STEP patch builds for all the targets listed in MAINTAINERS (it is how I found the sparc64 problem - just got to test it). As for other targets, I _think_ I got things right. However, like everyone else, I'm only human and so may well have got something wrong :-/ In the future, this problem - being able to reliably make global changes - is likely to become more of an issue. We don't want to let GDB's development get bogged down because people fear the consequences of making even simple mechanical changes. Things like -Werror and listing buildable targets in MAINTAINERS are all part of my secret agenda to make the process more tractable. Andrew >From ac131313@cygnus.com Wed Jan 24 00:00:00 2001 From: Andrew Cagney To: Kevin Buettner Cc: Rudy Folden , gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] Change malloc to xmalloc Date: Wed, 24 Jan 2001 00:00:00 -0000 Message-id: <3A6E6872.87E20FC@cygnus.com> References: <000501c08589$bc0a9dc0$3b1110ac@wirespeed.com> <1010123225905.ZM31728@ocotillo.lan> X-SW-Source: 2001-01/msg00221.html Content-length: 828 Kevin Buettner wrote: > Also, when you change something with PTR in it, just change the ``PTR'' > to ``void *''. It depends. There are a uses of PTR lurking in GDB where the function being declared/defined needs to match something in an external header. Something todo with mmalloc() from memory. > [...] > > Index: stuff.c > > =================================================================== > > RCS file: /cvs/src/src/gdb/stuff.c,v > > retrieving revision 1.2 > > I think you should leave stuff.c alone. It's a stand-alone program > that doesn't link in utils.c. (Actually, I think stuff.c ought > to be marked obsolete and eventually deleted.) Hmm, yes, that has been proposed before (by someone called KevinB? :-). This should be added to the 5.1 TODO list so that it does actually happen :-) enjoy, Andrew >From ac131313@cygnus.com Wed Jan 24 04:09:00 2001 From: Andrew Cagney To: jtc@redback.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: fix netbsd/ns32k target Date: Wed, 24 Jan 2001 04:09:00 -0000 Message-id: <3A6EA1F9.3B2F7B66@cygnus.com> References: <5melxvibju.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00223.html Content-length: 2089 "J.T. Conklin" wrote: > > I will be committing the enclosed patch. This should fix the problems > that Andrew encountered while building a ns32k-netbsd GDB on a FreeBSD > host. Thanks! > The first was the FRAME_FIND_SAVED_REGS macro in config/ns32k/tm-umax.h > mysteriously disappeared in May 1999. As I mentioned last week, there > was no ChangeLog entry, and because at that time the Cygnus repository > was the master repository, I am unable to determine in what change this > occured. But since neither the umax nor any target that inherits from > it (like netbsd/ns32k) can build without it, I can only assume that it's > removal was inadvertant. This patch restores the value to what it was > before. You can be fairly sure it was me that made the change, I'll dig up the details when I've more bandwith available (I'm moving hemispheres). It would have occured during one of the multi-arch passes and yes it should have had a ChangeLog entry so must have slipped through :-( One thing I remember though. Right at the start of the multi-arch process I made a list of targets I could build. Even at the start I couldn't find a buildable ns32k target. My notes read: ns32k-netbsd native solib.c:37: a.out.h: No such file or directory ns32k-pc532-mach3 native nm-m3.h:24: mach.h: No such file or directory so even before I broke it, it was already broken :-( > The other was that I jumped the gun and moved shared library support > objects from NATDEPFILES to TDEPFILES for all NetBSD targets after > the same had been done for GNU/Linux targets. This turned out to be > a mistake. Since shared library support has not yet been made host > independent, it was impossible to build cross debuggers for NetBSD > targets on some hosts. I've a feeling that you weren't the only one. Unless the host dependency in the shared library code is fixed (that #include and its consequenses) a few other *-elf targets will also need to revert that change. Thanks again for fixing that target. Don't forget to update MAINTAINERS to indicate that it does build. Andrew >From aoliva@redhat.com Wed Jan 24 05:16:00 2001 From: Alexandre Oliva To: gdb-patches@sources.redhat.com Subject: SH sim: implemented time() syscall Date: Wed, 24 Jan 2001 05:16:00 -0000 Message-id: X-SW-Source: 2001-01/msg00224.html Content-length: 49 I'm checking this in, approved by Ben Elliston.