From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: Andrew Cagney Cc: Philippe De Muyter , Elena Zannoni , gdb-patches@sourceware.cygnus.com Subject: Re: HAVE_POLL is not enough - RFA Date: Mon, 20 Mar 2000 12:17:00 -0000 Message-id: <14550.34627.565003.944170@kwikemart.cygnus.com> References: <200003181028.LAA30913@mail.macqel.be> <38D5BE1D.7BB02C99@cygnus.com> X-SW-Source: 2000-03/msg00384.html Agree with Andrew, either of his two suggestions is acceptable. Elena Andrew Cagney writes: > Philippe De Muyter wrote: > > > > I implemented the runtime poll/select selection. The patch seems huge because > > of the indentation changes caused by replacing > > #if HAVE_POLL > > some_code > > #else > > some_other_code > > #endif > > > > by > > > > #if HAVE_POLL > > if (!use_select) > > { > > some_code > > } > > else > > #endif > > { > > some_other_code > > } > > Um, to wear the hat of the style police (... :-) I'd suggest instead > codeing it as: > > if (use_poll) > { > #if HAVE_POLL > ... > #else > internal_error (...); > #endif > } > else > { > } > > or even as a psuedo object with a bunch of methods: > > some_struct.what_are_we_doing (args); > > Andrew >From jimb@zwingli.cygnus.com Mon Mar 20 12:32:00 2000 From: Jim Blandy To: Kevin Buettner Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] symfile.c bounds check Date: Mon, 20 Mar 2000 12:32:00 -0000 Message-id: References: <1000318223035.ZM11861@ocotillo.lan> X-SW-Source: 2000-03/msg00385.html Content-length: 1282 Yes, please do. > I was seeing rather severe problems (gdb coredumps; test suite > wouldn't run at all) on linux/ppc after my recent solib.c changes. > The following patch fixes these problems. (Also, since this is happening, > MAX_SECTIONS needs to be even bigger. We probably just ought to > redesign struct section_addr_info so that it can be dynamically sized.) > > May I check this in? > > * symfile.c (syms_from_objfile): Added bounds check prior to > accessing ``other'' array in a section_addr_info struct. > > Index: symfile.c > =================================================================== > RCS file: /cvs/src/src/gdb/symfile.c,v > retrieving revision 1.2 > diff -u -p -r1.2 symfile.c > --- symfile.c 2000/03/15 19:43:57 1.2 > +++ symfile.c 2000/03/18 22:18:53 > @@ -738,7 +790,9 @@ syms_from_objfile (objfile, addrs, mainl > else if (strcmp (s->the_bfd_section->name, ".bss") == 0) > s_addr = addrs->bss_addr; > else > - for (i = 0; !s_addr && addrs->other[i].name; i++) > + for (i = 0; > + !s_addr && i < MAX_SECTIONS && addrs->other[i].name; > + i++) > if (strcmp (s->the_bfd_section->name, addrs->other[i].name) == 0) > s_addr = addrs->other[i].addr; /* end added for gdb/13815 */ > > > >From jimb@zwingli.cygnus.com Mon Mar 20 12:35:00 2000 From: Jim Blandy To: Mark Kettenis Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Linux sigtramp detection code moved to its proper place Date: Mon, 20 Mar 2000 12:35:00 -0000 Message-id: References: <200003162241.RAA19616@zwingli.cygnus.com> <1000316225504.ZM3009@ocotillo.lan> <200003192311.e2JNBI900709@delius.kettenis.local> X-SW-Source: 2000-03/msg00386.html Content-length: 245 > I'm sorry --- this is obviously a tdep issue. Does the following > change look better? > > Sure! But could you please add i386-linux-tdep.c to the CVS > repository? I haven't committed any of this change. I'll commit all of it now. >From Stephane.Carrez@worldnet.fr Mon Mar 20 12:37:00 2000 From: Stephane Carrez To: Andrew Cagney Cc: gdb-patches@sourceware.cygnus.com Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2 Date: Mon, 20 Mar 2000 12:37:00 -0000 Message-id: <38D68C56.856CB00C@worldnet.fr> References: <38D4DCB0.88313CB2@worldnet.fr> <38D5B6E0.50FF6A5E@cygnus.com> X-SW-Source: 2000-03/msg00387.html Content-length: 2464 Hi Andrew, Andrew Cagney wrote: > > Stephane Carrez wrote: > > > > Hi! > > > > One part of the patch for dwarf2 correction with 16-bit target has > > been lost. If you are still not convinced by the fix, have a look > > at gas/dwarf2dbg.c in out_set_addr() where we obtain the address > > size in a good way. > > > > Can you integrate it? > > FYI, > > My reading of the thread from when this patch was last posted is that it > wasn't clear that this was a bug and the change was the correct thing to > do. > For me, it's a bug. The address size specified in dwarf2 is 16 and because we use arch_size which corresponds to the ELF32/ELF64 size, gdb stops reading with an error (dwarf2read.c:983): if (address_size < address_significant_size) { error ("Dwarf Error: bad address size (%ld) in compilation unit header (offset 0x%lx + 11).", (long) cu_header.addr_size, (long) (beg_of_comp_unit - dwarf_info_buffer)); The 'bfd_arch_bits_per_address (bfd)' function was defined for that. It really returns the size of target address and not the size of ELF file format. Here is how we get the address size in GAS (gas/dwarf2dbg.c:307): bytes_per_address = bfd_arch_bits_per_address (stdoutput) / 8; I would expect gdb to do the same. > I'm not sure that there is a GDB bug - GDB appears to have been given > wrong information. Yes. It is using the wrong information. > > Is there any reason why s->arch_size isn't 16 in your case? I can't change 'arch_size' in my port to make it 16. This would mean defining and using some ELF16. The arch_size member is filled in bfd/elfcode.h:1530 with the ARCH_SIZE define. This ARCH_SIZE define is either 32 or 64 and controls the reading/writing of the ELF sections (header, symbols and so on). I can't define some ELF16 for two reasons: first because Motorola spec says to use ELF32, and second because it means that some symbols and debugging sections would be limited to 64K which I don't want. So, the best thing is to fix GDB and have it use the good source of info:-) Stephane ----------------------------------------------------------------------- Home Office E-mail: stcarrez@worldnet.fr Stephane.Carrez@sun.com WWW: http://home.worldnet.fr/stcarrez http://www.sun.com Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel 92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines France >From jimb@zwingli.cygnus.com Mon Mar 20 12:43:00 2000 From: Jim Blandy To: Eli Zaretskii Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] "OVERLAY ON" does not exist. Date: Mon, 20 Mar 2000 12:43:00 -0000 Message-id: References: <200003191218.HAA08362@indy.delorie.com> X-SW-Source: 2000-03/msg00388.html Content-length: 1213 > Caught this small glitch while running the test suite. > > Okay to commit? Sure. But I think it should mention both ways to turn it on: Overlay debugging not enabled. Use either the `overlay auto' or the `overlay manual' command. > > 2000-03-16 Eli Zaretskii > > * symfile.c (map_overlay_command, unmap_overlay_command): Fix > error message: there's no "overlay on" command. > > --- gdb/symfile.c~0 Thu Feb 3 06:35:14 2000 > +++ gdb/symfile.c Thu Mar 16 22:57:26 2000 > @@ -2912,7 +2912,7 @@ > asection *bfdsec; > > if (!overlay_debugging) > - error ("Overlay debugging not enabled. Use the 'OVERLAY ON' command."); > + error ("Overlay debugging not enabled. Use the 'OVERLAY AUTO' command."); > > if (args == 0 || *args == 0) > error ("Argument required: name of an overlay section"); > @@ -2962,7 +2962,7 @@ > struct obj_section *sec; > > if (!overlay_debugging) > - error ("Overlay debugging not enabled. Use the 'OVERLAY ON' command."); > + error ("Overlay debugging not enabled. Use the 'OVERLAY AUTO' command."); > > if (args == 0 || *args == 0) > error ("Argument required: name of an overlay section"); > >From jimb@zwingli.cygnus.com Mon Mar 20 12:48:00 2000 From: Jim Blandy To: Eli Zaretskii Cc: kettenis@wins.uva.nl, gdb-patches@sourceware.cygnus.com Subject: Re: RFA: minor watchpoint code cleanup Date: Mon, 20 Mar 2000 12:48:00 -0000 Message-id: References: <200003180006.TAA26919@zwingli.cygnus.com> <200003190944.EAA07454@indy.delorie.com> <200003192255.e2JMtcs00643@delius.kettenis.local> <200003200958.EAA09356@indy.delorie.com> X-SW-Source: 2000-03/msg00389.html Content-length: 64 Yes, yes, but does anyone have comments on my little patch? :) >From kevinb@cygnus.com Mon Mar 20 14:22:00 2000 From: Kevin Buettner To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] utils.c changes Date: Mon, 20 Mar 2000 14:22:00 -0000 Message-id: <1000320222159.ZM19650@ocotillo.lan> X-SW-Source: 2000-03/msg00390.html Content-length: 1593 I've just committed the patch below. (Thanks to David Taylor for promptly reviewing these changes.) * utils.c (floatformat_from_doublest): Don't assume that a long will be exactly 32 bits in length. Also... make sure space that we're writing the float to is completely initialized to zeroes, even when the number of bits in the float is not evenly divisible by FLOATFORMAT_CHAR_BIT. Index: utils.c =================================================================== RCS file: /cvs/src/src/gdb/utils.c,v retrieving revision 1.4 diff -u -p -r1.4 utils.c --- utils.c 2000/03/04 02:23:06 1.4 +++ utils.c 2000/03/20 21:18:42 @@ -2722,7 +2722,8 @@ floatformat_from_doublest (fmt, from, to unsigned char *uto = (unsigned char *) to; memcpy (&dfrom, from, sizeof (dfrom)); - memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT); + memset (uto, 0, (fmt->totalsize + FLOATFORMAT_CHAR_BIT - 1) + / FLOATFORMAT_CHAR_BIT); if (dfrom == 0) return; /* Result is zero */ if (dfrom != dfrom) /* Result is NaN */ @@ -2771,7 +2772,7 @@ floatformat_from_doublest (fmt, from, to mant_bits = mant_bits_left < 32 ? mant_bits_left : 32; mant *= 4294967296.0; - mant_long = (unsigned long) mant; + mant_long = ((unsigned long) mant) & 0xffffffffL; mant -= mant_long; /* If the integer bit is implicit, then we need to discard it. @@ -2782,6 +2783,7 @@ floatformat_from_doublest (fmt, from, to && fmt->intbit == floatformat_intbit_no) { mant_long <<= 1; + mant_long &= 0xffffffffL; mant_bits -= 1; }