Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Stephane Carrez <Stephane.Carrez@worldnet.fr>
Cc: 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	[thread overview]
Message-ID: <38D74A9E.A85ED8EC@cygnus.com> (raw)
In-Reply-To: <38D68C56.856CB00C@worldnet.fr>

Stephane Carrez wrote:
> 
> 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));
> 

As far as I know, the dwarf2 and elf information are both ment to be
self contained.  There shouldn't be any need to refer to some arbitrary
bfd table to determine what is going on.  If the info says that an
address is 16 bits for a given section then it sounds like GDB should
just believe it.

As JimK suggested:
> 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?

Rather than diging values out of archures I think the possibility of:
	cu_header.address_size < elf-header.address_size
should be documented as being just as legetimate (sarcasm :-) as:
	cu_header.address_size > elf-header.address_size
and the check either replaced or removed.

	Andrew
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] Another utils.c patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000319174817.ZM17637@ocotillo.lan>
References: <1000319072047.ZM14883@ocotillo.lan> <kevinb@cygnus.com>
X-SW-Source: 2000-q1/msg00786.html
Content-length: 2222

On Mar 19, 12:20am, Kevin Buettner wrote:
> Subject: [PATCH RFA] Another utils.c patch
> This fixes another bug uncovered by running the testsuite for the
> IA-64...  may I check this one in?
> 
> 	* utils.c (floatformat_from_doublest): 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/19 07:12:00
> @@ -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
> +                  + ((fmt->totalsize % FLOATFORMAT_CHAR_BIT) == 0 ? 0 : 1));
>    if (dfrom == 0)
>      return;			/* Result is zero */
>    if (dfrom != dfrom)		/* Result is NaN */
> 
>-- End of excerpt from Kevin Buettner

I withdraw the patch above in favor of the one below.  (The patch above
is not as concise as the one below.  But they should both produce the
same results.)

	* utils.c (floatformat_from_doublest): 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/19 17:36:49
@@ -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 */


       reply	other threads:[~2000-04-01  0:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <38D4DCB0.88313CB2@worldnet.fr>
     [not found] ` <38D5B6E0.50FF6A5E@cygnus.com>
     [not found]   ` <38D68C56.856CB00C@worldnet.fr>
2000-04-01  0:00     ` Andrew Cagney [this message]
     [not found]       ` <38D7E6BC.79543EBA@worldnet.fr>
2000-03-27 12:23         ` Jim Blandy
     [not found]           ` <38E06721.6D3A08CD@cygnus.com>
     [not found]             ` <npsnx91szl.fsf@zwingli.cygnus.com>
2000-04-01  0:00               ` Andrew Cagney
     [not found]         ` <npem8w42bg.fsf@zwingli.cygnus.com>
2000-04-01  0:00           ` Fernando Nasser
2000-04-01  0:00 Stephane Carrez
     [not found] ` <38BB5463.D6E5B75C@cygnus.com>
     [not found]   ` <38C0D9D9.70987863@worldnet.fr>
     [not found]     ` <38C225F3.9E236A55@cygnus.com>
2000-03-28  8:24       ` Jim Blandy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38D74A9E.A85ED8EC@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=Stephane.Carrez@worldnet.fr \
    --cc=gdb-patches@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox