Re: HAVE_POLL is not enough - RFA

[Elena Zannoni <ezannoni@cygnus.com>]

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 <jimb@zwingli.cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
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: <npbt498jse.fsf@zwingli.cygnus.com>
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 <jimb@zwingli.cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
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: <npaejt8jnp.fsf@zwingli.cygnus.com>
References: <200003162241.RAA19616@zwingli.cygnus.com> <1000316225504.ZM3009@ocotillo.lan> <npsnxp8ix6.fsf@zwingli.cygnus.com> <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 <Stephane.Carrez@worldnet.fr>
To: Andrew Cagney <ac131313@cygnus.com>
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 <jimb@zwingli.cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
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: <np8zzd8ja7.fsf@zwingli.cygnus.com>
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  <eliz@is.elta.co.il>
> 
> 	* 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 <jimb@zwingli.cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
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: <np7lex8j1u.fsf@zwingli.cygnus.com>
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 <kevinb@cygnus.com>
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;
 	}