Re: (patch) hpjyg23: gdbtypes.[ch] & values.c

Re: (patch) hpjyg23: gdbtypes.[ch] & values.c

[Andrew Cagney]

Jimmy Guo wrote:
> 

> >BFD64:  I'm not sure this is the right test. Should some characteristic
> >of the ABFD be tested instead?
> 
> Suggestion for a better alternative is appreciated.

Hmm, TARGET_PTR_BIT indicates the size of a target C-pointer but doesn't
help when it comes to the object file.

Checking through the BFD code it looks like there isn't anything to
determine the address size of the object file being loaded.  Sorry.

	Andrew
From ac131313@cygnus.com Tue Nov 16 12:20:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: binutils@sourceware.cygnus.com
Cc: Jimmy Guo <guo@cup.hp.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Test for 32/64 bit object file?
Date: Tue, 16 Nov 1999 12:20:00 -0000
Message-id: <3831BC80.31216A6A@cygnus.com>
X-SW-Source: 1999-q4/msg00267.html
Content-length: 172

Hello,

Is there a way of determining if an object file is 32 or 64 bit?  (eg
elf32/elf64, aout32 vs aout64).
Perhaphs bfd_arch_bits_per_address(ABFD) is correct?

	Andrew
From jimb@cygnus.com Tue Nov 16 13:06:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: jtc@redback.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: fp update for embedded x86 config
Date: Tue, 16 Nov 1999 13:06:00 -0000
Message-id: <npd7ta6t94.fsf@zwingli.cygnus.com>
References: <5m7ljntrg9.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00268.html
Content-length: 2802

In my vague and undetailed understanding, this patch is currently a
no-op, since tm-i386v.h defines its own registers.  And even if we
delete the register definitions from tm-i386v.h (which I think we
should), the behavior of the embedded target will be unchanged, since
tm-i386.h defines only the general purpose registers by default.  I
don't expect that to change in the future.

Am I missing something?  What are the details?  What's the intent?

> 1999-11-12  J.T. Conklin  <jtc@redback.com>
> 
> 	* config/i386/tm-embed.h: New file.
> 	* config/i386/embed.mt: Updated to use tm-embed.h.
> 
> Index: gdb/gdb/config/i386/embed.mt
> diff -c gdb/gdb/config/i386/embed.mt:1.1.1.1 gdb/gdb/config/i386/embed.mt:1.2
> *** gdb/gdb/config/i386/embed.mt:1.1.1.1	Tue Aug 17 16:52:14 1999
> --- gdb/gdb/config/i386/embed.mt	Fri Nov 12 11:48:31 1999
> ***************
> *** 1,3 ****
>   # Target: Embedded Intel 386 
>   TDEPFILES= i386-tdep.o i387-tdep.o
> ! TM_FILE= tm-i386v.h
> --- 1,3 ----
>   # Target: Embedded Intel 386 
>   TDEPFILES= i386-tdep.o i387-tdep.o
> ! TM_FILE= tm-embed.h
> Index: gdb/gdb/config/i386/tm-embed.h
> diff -c /dev/null gdb/gdb/config/i386/tm-embed.h:1.1
> *** /dev/null	Fri Nov 12 11:49:47 1999
> --- gdb/gdb/config/i386/tm-embed.h	Fri Nov 12 11:48:31 1999
> ***************
> *** 0 ****
> --- 1,35 ----
> + /* Target machine description for embedded 80[3456]86,
> +    for GDB, the GNU debugger.
> +    Copyright (C) 1999 Free Software Foundation, Inc.
> + 
> +    This file is part of GDB.
> + 
> +    This program is free software; you can redistribute it and/or modify
> +    it under the terms of the GNU General Public License as published by
> +    the Free Software Foundation; either version 2 of the License, or
> +    (at your option) any later version.
> + 
> +    This program is distributed in the hope that it will be useful,
> +    but WITHOUT ANY WARRANTY; without even the implied warranty of
> +    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +    GNU General Public License for more details.
> + 
> +    You should have received a copy of the GNU General Public License
> +    along with this program; if not, write to the Free Software
> +    Foundation, Inc., 59 Temple Place - Suite 330,
> +    Boston, MA 02111-1307, USA.  */
> + 
> + #ifndef TM_EMBED_H
> + #define TM_EMBED_H
> + 
> + /* Because GDB's embedded x86 targets did not support floating point 
> +    registers before the x86 FP support reorganization effort, it seems
> +    prudent to continue doing the same until a mechanism is in place to 
> +    select processor type at run time. */
> + 
> + #undef HAVE_I387_REGS
> + #undef HAVE_SSE_REGS
> + 
> + #include "i386/tm-i386v.h"
> + 
> + #endif /* ifndef TM_EMBED_H */
> 
> 
> -- 
> J.T. Conklin
> RedBack Networks
> 
From ian@zembu.com Tue Nov 16 13:08:00 1999
From: Ian Lance Taylor <ian@zembu.com>
To: ac131313@cygnus.com
Cc: binutils@sourceware.cygnus.com, guo@cup.hp.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Test for 32/64 bit object file?
Date: Tue, 16 Nov 1999 13:08:00 -0000
Message-id: <19991116210700.5337.qmail@daffy.airs.com>
References: <3831BC80.31216A6A@cygnus.com>
X-SW-Source: 1999-q4/msg00269.html
Content-length: 534

   Date: Wed, 17 Nov 1999 07:20:16 +1100
   From: Andrew Cagney <ac131313@cygnus.com>

   Is there a way of determining if an object file is 32 or 64 bit?  (eg
   elf32/elf64, aout32 vs aout64).

Why do you want to know?  I don't mean to be snide; it's just that
that distinction usually isn't interesting.

   Perhaphs bfd_arch_bits_per_address(ABFD) is correct?

That will tell you whether the CPU uses 32 bits in an address or 64
bits in an address.  It's not the same as elf32 vs. elf64, but it may
be what you need to know.

Ian
From kevinb@cygnus.com Tue Nov 16 13:59:00 1999
From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>, Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: PACKET_OVERHEAD constant added to remote.c
Date: Tue, 16 Nov 1999 13:59:00 -0000
Message-id: <991116215839.ZM27486@ocotillo.lan>
References: <991112184146.ZM22052@ocotillo.lan> <38308EDB.A02AF873@cygnus.com> <991115233403.ZM17177@ocotillo.lan> <3830BF79.F43EEE0A@cygnus.com> <991116041240.ZM24569@ocotillo.lan> <3831A6A7.245C4FCA@cygnus.com> <ac131313@cygnus.com>
X-SW-Source: 1999-q4/msg00270.html
Content-length: 7845

On Nov 17,  5:47am, Andrew Cagney wrote:

> Kevin Buettner wrote:
> > 
> > On Nov 16,  1:20pm, Andrew Cagney wrote:
> > 
> > > > As far as remote_write_bytes() or remote_read_bytes() are concerned,
> > > > they get their packet sizes by calling get_memory_write_packet_size()
> > > > or get_memory_read_packet_size() which in turn determine the size by
> > > > calling get_memory_packet_size().  It is the latter function which
> > > > was returning too large a value.  It is also in this function where
> > > > I chose to make an adjustment:
> > >
> > > Yes.  I'm just trying to understand if this is a recently introduced bug
> > > (by me) or has always been in there. (In particular prior to the change
> > > to remote.c below).
> > 
> > Unclear.  I was able to use an x86 linux gdbserver with gdb prior to
> > your change below (without seeing the buffer overflow problem).  I
> > don't whether it was your change which caused the breakage or something
> > else.
> 
> It is highly likely :-(
> 
> > Let me know if you'd like me to pursue this; I could do an update
> > to Nov 3 and see if the problem still exists...
> 
> If you can?  Otherwize I'll try to find a linux box - I should probably
> look at the details.

Okay... I've pursued.

I think this problem has always existed...  or it has at least as long
as we've been cutting the memory read packet size down to the size of
the remote registers.

The problem arises when the remote registers haven't been fetched yet
(via a g packet) and we try to read a large block of memory from the
remote.  If this should happen, it is possible to request a packet
(from gdbserver in my case) which is larger than remote.c is prepared
to cope with.  (If the remote registers haven't been fetched, we don't
know how large the remote's register buffer is and therefore we can't
restrict the size.)

It turns out that this was very difficult to reproduce.  I first
noticed it when Jesper Skov alerted me to the fact that gdbserver was
broken (in devo) for Linux.  gdbserver was not completely broken; it
just wouldn't fetch registers correctly.  This led to an error
condition.  (The _start breakpoint wasn't recognized and gdb saw a
SIGTRAP instead.)  I've captured what gdb was trying to do with the
following backtrace...

    Packet received: 010000006833014010a400400000000000000040
    Sending packet: $m40013368,c8#cd...
    Breakpoint 3, putpkt_binary (buf=0xbfffe730 "m40013368,c8", cnt=12)
	at ../../../devo/gdb/remote.c:3701
    3701          if (SERIAL_WRITE (remote_desc, buf2, p - buf2))
    (top-gdb) bt
    #0  putpkt_binary (buf=0xbfffe730 "m40013368,c8", cnt=12)
	at ../../../devo/gdb/remote.c:3701
    #1  0x809cde4 in putpkt (buf=0xbfffe730 "m40013368,c8")
	at ../../../devo/gdb/remote.c:3650
    #2  0x809cb29 in remote_read_bytes (memaddr=1073820520, myaddr=0x83cd8a4 "", 
	len=552) at ../../../devo/gdb/remote.c:3445
    #3  0x80a00a4 in dcache_xfer_memory (dcache=0x83c7048, memaddr=1073820520, 
	myaddr=0x83cd8a4 "", len=552, should_write=0)
	at ../../../devo/gdb/dcache.c:503
    #4  0x809cc5e in remote_xfer_memory (mem_addr=1073820520, buffer=0x83cd8a4 "", 
	mem_len=552, should_write=0, target=0x833ed20)
	at ../../../devo/gdb/remote.c:3503
    #5  0x80adabb in target_xfer_memory (memaddr=1073820520, myaddr=0x83cd8a4 "", 
	len=552, write=0, bfd_section=0x0) at ../../../devo/gdb/target.c:846
    #6  0x80ad9ee in target_read_memory (memaddr=1073820520, myaddr=0x83cd8a4 "", 
	len=552) at ../../../devo/gdb/target.c:784
    #7  0x80b86aa in read_memory (memaddr=1073820520, myaddr=0x83cd8a4 "", len=552)
	at ../../../devo/gdb/corefile.c:268
    #8  0x8093fb3 in find_solib (so_list_ptr=0x0) at ../../../devo/gdb/solib.c:1048
    #9  0x8094629 in solib_address (address=0) at ../../../devo/gdb/solib.c:1350
    #10 0x804f7c2 in print_frame_info_base (fi=0x8341980, level=-1, source=1, 
	args=1) at ../../../devo/gdb/stack.c:652
    #11 0x804f9a5 in print_frame_info (fi=0x8341980, level=-1, source=1, args=1)
	at ../../../devo/gdb/stack.c:748
    #12 0x804f0e8 in show_and_print_stack_frame_stub (args=0xbfffed68)
	at ../../../devo/gdb/stack.c:158
    #13 0x80c578b in catch_errors (
	func=0x804f090 <show_and_print_stack_frame_stub>, args=0xbfffed68, 
	errstring=0x8277300 "", mask=3) at ../../../devo/gdb/top.c:588
    #14 0x804f264 in show_and_print_stack_frame (fi=0x8341980, level=-1, source=1)
	at ../../../devo/gdb/stack.c:256
    #15 0x808029a in normal_stop () at ../../../devo/gdb/infrun.c:3466
    ...

Note that 0xc8 is 200 decimal which is half of 400.  (Which is what
remote_packet_size starts out at if REGISTER_BYTES is too small.) This
is the value of remote_packet_size and half this number is the number
of bytes that gdb is requesting from gdbserver.  Clearly this won't do
since the packet overhead has not been accounted for.

I've also been able to reproduce the problem with a working x86 linux
gdbserver as well.  (I used a broken one to get the above trace.)
I used the following program:

--- sigtrap.c ---
char trap[] = { 0xcc };
main()
{
  (*(void (*)()) trap) ();
}
--- end sigtrap.c ---

Then, in order to reproduce the problem, I start up gdbserver, start
up gdb, and then simply connect to gdbserver and continue.  I.e, I'm
using the following commands:

	set remotedebug 1
	target remote ocotillo:11200
	c

Let me know if you'd like to see a complete session.

> FYI, I suspect that rather than chop down the packet size by 32 bytes,
> it will be better to figure out what went wrong and fix that - 32 bytes
> less in a packet is a significant reduction.

I've looked at the code and I've thought about it and I really don't
see a better place to fix it.  Note that I'm only chopping 32 bytes
off of remote_packet_size in order to set what_they_get in
get_memory_packet_size().  Buffer allocations still rely on an
unchopped remote_packet_size.  Anyone calling get_memory_packet_size()
wants to know the amount that's safe to put into one of these buffers.
(It also tries to make sure that the target's buffers don't overflow
either.)

In addition, there are other pathways through get_memory_packet_size()
which avoid the chopping altogether.  So if you explicitly set
memory-read-packet-size or memory-write-packet-size to something
really small, then 32 will not get chopped off.  (Which is what I
think you were concerned about.)

To refresh your memory, here's what get_memory_packet_size looks like
after my patch has been applied:

static long
get_memory_packet_size (struct memory_packet_config *config)
{
  /* NOTE: The somewhat arbitrary 16k comes from the knowledge (folk
     law?) that some hosts don't cope very well with large alloca()
     calls.  Eventually the alloca() code will be replaced by calls to
     xmalloc() and make_cleanups() allowing this restriction to either
     be lifted or removed. */
#ifndef MAX_REMOTE_PACKET_SIZE
#define MAX_REMOTE_PACKET_SIZE 16384
#endif
  /* NOTE: 16 is just chosen at random. */
#ifndef MIN_REMOTE_PACKET_SIZE
#define MIN_REMOTE_PACKET_SIZE 16
#endif
  long what_they_get;
  if (config->fixed_p)
    {
      if (config->size <= 0)
	what_they_get = MAX_REMOTE_PACKET_SIZE;
      else
	what_they_get = config->size;
    }
  else
    {
      what_they_get = remote_packet_size - PACKET_OVERHEAD;
      /* Limit the packet to the size specified by the user. */
      if (config->size > 0
	  && what_they_get > config->size)
	what_they_get = config->size;
      /* Limit it to the size of the targets ``g'' response. */
      if (actual_register_packet_size > 0
	  && what_they_get > actual_register_packet_size)
	what_they_get = actual_register_packet_size;
    }
  if (what_they_get > MAX_REMOTE_PACKET_SIZE)
    what_they_get = MAX_REMOTE_PACKET_SIZE;
  if (what_they_get < MIN_REMOTE_PACKET_SIZE)
    what_they_get = MIN_REMOTE_PACKET_SIZE;
  return what_they_get;
}

Kevin
From ac131313@cygnus.com Tue Nov 16 14:01:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Ian Lance Taylor <ian@zembu.com>
Cc: binutils@sourceware.cygnus.com, guo@cup.hp.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Test for 32/64 bit object file?
Date: Tue, 16 Nov 1999 14:01:00 -0000
Message-id: <3831D3E2.E744E2AB@cygnus.com>
References: <3831BC80.31216A6A@cygnus.com> <19991116210700.5337.qmail@daffy.airs.com>
X-SW-Source: 1999-q4/msg00271.html
Content-length: 1134

Ian Lance Taylor wrote:
> 
>    Date: Wed, 17 Nov 1999 07:20:16 +1100
>    From: Andrew Cagney <ac131313@cygnus.com>
> 
>    Is there a way of determining if an object file is 32 or 64 bit?  (eg
>    elf32/elf64, aout32 vs aout64).
> 
> Why do you want to know?  I don't mean to be snide; it's just that
> that distinction usually isn't interesting.

never a silly question :-)

>    Perhaphs bfd_arch_bits_per_address(ABFD) is correct?
> 
> That will tell you whether the CPU uses 32 bits in an address or 64
> bits in an address.  It's not the same as elf32 vs. elf64, but it may
> be what you need to know.

GDB encounters situtations (c.f. assorted mips targets) where the object
file contains 32 bit addresses but the target has a 64 bit address
space.  The 32 address values being implicitly zero or sign extended to
64 bits.  GDB needs to know what the object file format assumed (or
didn't in some case) is doing so that it can correctly do things like
compares.

I also suspect that the sprintf_vma() et.al. macro's should format the
address according to the BFD object file address size rather than BFD64.

	enjoy,
		Andrew
From ian@zembu.com Tue Nov 16 16:23:00 1999
From: Ian Lance Taylor <ian@zembu.com>
To: ac131313@cygnus.com
Cc: binutils@sourceware.cygnus.com, guo@cup.hp.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Test for 32/64 bit object file?
Date: Tue, 16 Nov 1999 16:23:00 -0000
Message-id: <19991117001256.5855.qmail@daffy.airs.com>
References: <3831BC80.31216A6A@cygnus.com> <19991116210700.5337.qmail@daffy.airs.com> <3831D3E2.E744E2AB@cygnus.com>
X-SW-Source: 1999-q4/msg00272.html
Content-length: 1844

   Date: Wed, 17 Nov 1999 09:00:02 +1100
   From: Andrew Cagney <ac131313@cygnus.com>

   >    Perhaphs bfd_arch_bits_per_address(ABFD) is correct?
   > 
   > That will tell you whether the CPU uses 32 bits in an address or 64
   > bits in an address.  It's not the same as elf32 vs. elf64, but it may
   > be what you need to know.

   GDB encounters situtations (c.f. assorted mips targets) where the object
   file contains 32 bit addresses but the target has a 64 bit address
   space.  The 32 address values being implicitly zero or sign extended to
   64 bits.  GDB needs to know what the object file format assumed (or
   didn't in some case) is doing so that it can correctly do things like
   compares.

I don't think there is any general purpose approach to this.  The 32
bit MIPS targets act idiosyncratically, because we needed to support
64 bit MIPS processors before we supported the 64 bit MIPS ELF object
file format.  I don't think any other target acts the way they do.

Note that you can't use bfd_arch_bits_per_address to determine the
size of an address in a MIPS ELF object file.

BFD does know whether a target requires a 64 bit bfd_vma, which is
about as close as I can see to what you are asking for.  However, this
information is stored only in bfd/configure.in, in the setting of the
shell variable target64.

For the special case of an ELF target, you can look at arch_size field
of the size_info structure.  BFD doesn't currently provide any
interface for other programs to look at that field.

   I also suspect that the sprintf_vma() et.al. macro's should format the
   address according to the BFD object file address size rather than BFD64.

BFD64 defines the size of a bfd_vma, and sprintf_vma doesn't check an
object file.  If it did, I think bfd_arch_bits_per_address would be
the right thing to check.

Ian
From ac131313@cygnus.com Tue Nov 16 17:05:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: PACKET_OVERHEAD constant added to remote.c
Date: Tue, 16 Nov 1999 17:05:00 -0000
Message-id: <3831FF46.65118BCC@cygnus.com>
References: <991112184146.ZM22052@ocotillo.lan> <38308EDB.A02AF873@cygnus.com> <991115233403.ZM17177@ocotillo.lan> <3830BF79.F43EEE0A@cygnus.com> <991116041240.ZM24569@ocotillo.lan> <3831A6A7.245C4FCA@cygnus.com> <991116215839.ZM27486@ocotillo.lan>
X-SW-Source: 1999-q4/msg00273.html
Content-length: 3752

Kevin Buettner wrote:
> 
> On Nov 17,  5:47am, Andrew Cagney wrote:
> 
> > Kevin Buettner wrote:
> > >
> > > On Nov 16,  1:20pm, Andrew Cagney wrote:
> > >
> > > > > As far as remote_write_bytes() or remote_read_bytes() are concerned,
> > > > > they get their packet sizes by calling get_memory_write_packet_size()
> > > > > or get_memory_read_packet_size() which in turn determine the size by
> > > > > calling get_memory_packet_size().  It is the latter function which
> > > > > was returning too large a value.  It is also in this function where
> > > > > I chose to make an adjustment:
> > > >
> > > > Yes.  I'm just trying to understand if this is a recently introduced bug
> > > > (by me) or has always been in there. (In particular prior to the change
> > > > to remote.c below).
> > >
> > > Unclear.  I was able to use an x86 linux gdbserver with gdb prior to
> > > your change below (without seeing the buffer overflow problem).  I
> > > don't whether it was your change which caused the breakage or something
> > > else.
> >
> > It is highly likely :-(
> >
> > > Let me know if you'd like me to pursue this; I could do an update
> > > to Nov 3 and see if the problem still exists...
> >
> > If you can?  Otherwize I'll try to find a linux box - I should probably
> > look at the details.
> 
> Okay... I've pursued.
> 
> I think this problem has always existed...  or it has at least as long
> as we've been cutting the memory read packet size down to the size of
> the remote registers.

Ah, I feel much better. Much thanks!

> The problem arises when the remote registers haven't been fetched yet
> (via a g packet) and we try to read a large block of memory from the
> remote.  If this should happen, it is possible to request a packet
> (from gdbserver in my case) which is larger than remote.c is prepared
> to cope with.  (If the remote registers haven't been fetched, we don't
> know how large the remote's register buffer is and therefore we can't
> restrict the size.)

> It turns out that this was very difficult to reproduce.  I first
> noticed it when Jesper Skov alerted me to the fact that gdbserver was
> broken (in devo) for Linux.  gdbserver was not completely broken; it
> just wouldn't fetch registers correctly.  This led to an error
> condition.  (The _start breakpoint wasn't recognized and gdb saw a
> SIGTRAP instead.)  I've captured what gdb was trying to do with the
> following backtrace...

FYI, I've a number of short programs that pretend to speak GDB protocol.
Very useful for this sort of testing.

> Let me know if you'd like to see a complete session.

No this is more than sufficient, much thanks.

> > FYI, I suspect that rather than chop down the packet size by 32 bytes,
> > it will be better to figure out what went wrong and fix that - 32 bytes
> > less in a packet is a significant reduction.
> 
> I've looked at the code and I've thought about it and I really don't
> see a better place to fix it.  Note that I'm only chopping 32 bytes
> off of remote_packet_size in order to set what_they_get in
> get_memory_packet_size().  Buffer allocations still rely on an
> unchopped remote_packet_size.  Anyone calling get_memory_packet_size()
> wants to know the amount that's safe to put into one of these buffers.
> (It also tries to make sure that the target's buffers don't overflow
> either.)

What about the following:

o	Add a buffer size parameter to getpkt() so that it
	can check (after being fixed) for buffer overflows.

o	reduce the 400 to 399 (or 398?).
	Have a look at m68k-stub.c for why. Outch!

o	fix the *_read_bytes() code so that it allocates
	a buffer that includes space for the trailing
	NUL.

I can see my way through them in the next few days (unless you beat me
to it :-).

	Andrew
From ac131313@cygnus.com Tue Nov 16 17:49:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Ian Lance Taylor <ian@zembu.com>
Cc: binutils@sourceware.cygnus.com, guo@cup.hp.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Test for 32/64 bit object file?
Date: Tue, 16 Nov 1999 17:49:00 -0000
Message-id: <3832094E.18420274@cygnus.com>
References: <3831BC80.31216A6A@cygnus.com> <19991116210700.5337.qmail@daffy.airs.com> <3831D3E2.E744E2AB@cygnus.com> <19991117001256.5855.qmail@daffy.airs.com>
X-SW-Source: 1999-q4/msg00274.html
Content-length: 2369

Ian Lance Taylor wrote:
> 
>    Date: Wed, 17 Nov 1999 09:00:02 +1100
>    From: Andrew Cagney <ac131313@cygnus.com>
> 
>    >    Perhaphs bfd_arch_bits_per_address(ABFD) is correct?
>    >
>    > That will tell you whether the CPU uses 32 bits in an address or 64
>    > bits in an address.  It's not the same as elf32 vs. elf64, but it may
>    > be what you need to know.
> 
>    GDB encounters situtations (c.f. assorted mips targets) where the object
>    file contains 32 bit addresses but the target has a 64 bit address
>    space.  The 32 address values being implicitly zero or sign extended to
>    64 bits.  GDB needs to know what the object file format assumed (or
>    didn't in some case) is doing so that it can correctly do things like
>    compares.
> 
> I don't think there is any general purpose approach to this.  The 32
> bit MIPS targets act idiosyncratically, because we needed to support
> 64 bit MIPS processors before we supported the 64 bit MIPS ELF object
> file format.  I don't think any other target acts the way they do.

If we consider the MIPS idiosyncratic then can
bfd_arch_bits_per_address() be considered reliable for non mips/elf
targets?

For the mips GDB could always handle that as a special case:

	o	for an elf target check the elf info

	o	for other targets just assume
		bfd_arch_bits_per_address() is correct

> Note that you can't use bfd_arch_bits_per_address to determine the
> size of an address in a MIPS ELF object file.

per above, what about for non-mips targets?

> BFD does know whether a target requires a 64 bit bfd_vma, which is
> about as close as I can see to what you are asking for.  However, this
> information is stored only in bfd/configure.in, in the setting of the
> shell variable target64.

I think the macro ARCH_SIZE defined/used by some targets contains what
I'm looking for.
Is it worth extending BFD (struct bfd_target) to include that
information somewhere?  (Grubbing through the code it doesn't look easy
- many changes to many files).

>    I also suspect that the sprintf_vma() et.al. macro's should format the
>    address according to the BFD object file address size rather than BFD64.
> 
> BFD64 defines the size of a bfd_vma, and sprintf_vma doesn't check an
> object file.  If it did, I think bfd_arch_bits_per_address would be
> the right thing to check.

True.

	enjoy,
		Andrew
From ian@zembu.com Tue Nov 16 18:08:00 1999
From: Ian Lance Taylor <ian@zembu.com>
To: ac131313@cygnus.com
Cc: binutils@sourceware.cygnus.com, guo@cup.hp.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Test for 32/64 bit object file?
Date: Tue, 16 Nov 1999 18:08:00 -0000
Message-id: <19991117020712.6443.qmail@daffy.airs.com>
References: <3831BC80.31216A6A@cygnus.com> <19991116210700.5337.qmail@daffy.airs.com> <3831D3E2.E744E2AB@cygnus.com> <19991117001256.5855.qmail@daffy.airs.com> <3832094E.18420274@cygnus.com>
X-SW-Source: 1999-q4/msg00275.html
Content-length: 1851

   Date: Wed, 17 Nov 1999 12:47:58 +1100
   From: Andrew Cagney <ac131313@cygnus.com>

   >    GDB encounters situtations (c.f. assorted mips targets) where the object
   >    file contains 32 bit addresses but the target has a 64 bit address
   >    space.  The 32 address values being implicitly zero or sign extended to
   >    64 bits.  GDB needs to know what the object file format assumed (or
   >    didn't in some case) is doing so that it can correctly do things like
   >    compares.
   > 
   > I don't think there is any general purpose approach to this.  The 32
   > bit MIPS targets act idiosyncratically, because we needed to support
   > 64 bit MIPS processors before we supported the 64 bit MIPS ELF object
   > file format.  I don't think any other target acts the way they do.

   If we consider the MIPS idiosyncratic then can
   bfd_arch_bits_per_address() be considered reliable for non mips/elf
   targets?

That will always get you the size of an address of the CPU.  There is
no particular reason to assume that that is the size of an address
stored in the object file.

I don't know of any other case where it is different.  But I'm not
going to promise that there will never be another case.

   > BFD does know whether a target requires a 64 bit bfd_vma, which is
   > about as close as I can see to what you are asking for.  However, this
   > information is stored only in bfd/configure.in, in the setting of the
   > shell variable target64.

   I think the macro ARCH_SIZE defined/used by some targets contains what
   I'm looking for.
   Is it worth extending BFD (struct bfd_target) to include that
   information somewhere?  (Grubbing through the code it doesn't look easy
   - many changes to many files).

Yes, ARCH_SIZE is probably approximately what you are asking for.  But
it isn't used by every backend.

Ian
From rth@cygnus.com Tue Nov 16 18:35:00 1999
From: Richard Henderson <rth@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Ian Lance Taylor <ian@zembu.com>, binutils@sourceware.cygnus.com, guo@cup.hp.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Test for 32/64 bit object file?
Date: Tue, 16 Nov 1999 18:35:00 -0000
Message-id: <19991116183522.A9086@cygnus.com>
References: <3831BC80.31216A6A@cygnus.com> <19991116210700.5337.qmail@daffy.airs.com> <3831D3E2.E744E2AB@cygnus.com>
X-SW-Source: 1999-q4/msg00276.html
Content-length: 9908

On Wed, Nov 17, 1999 at 09:00:02AM +1100, Andrew Cagney wrote:
> GDB encounters situtations (c.f. assorted mips targets) where the object
> file contains 32 bit addresses but the target has a 64 bit address
> space.  The 32 address values being implicitly zero or sign extended to
> 64 bits.  GDB needs to know what the object file format assumed (or
> didn't in some case) is doing so that it can correctly do things like
> compares.

I was thinking something like this might work.  The idea is to 
have bfd_vma be 64-bits (which it already is), and have the BFD
sign extend the values it finds in the elf32 object files.  This
mirrors what we do for e.g. R_MIPS_64 in such a case, and thus
what a run-time loader ought to be doing as well.  

GDB should continue to use complete 64-bit addresses, since the
entire address space is potentially valid at runtime.

Comments?


r~


	* elf-bfd.h (struct elf_backend_data): Reorder collect and 
	type_change_ok; add sign_extend_vma.
	* elf32-mips.c (elf_backend_sign_extend_vma): Define.
	* elfcode.h (elf_swap_symbol_in): Mind be->sign_extend_vma.
	(elf_swap_shdr_in, elf_swap_phdr_in): Likewise.
	* elfxx-target.h (elf_backend_sign_extend_vma): Default.
	(elfNN_bed): Follow struture changes.

Index: elf-bfd.h
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elf-bfd.h,v
retrieving revision 1.55
diff -c -p -d -r1.55 elf-bfd.h
*** elf-bfd.h	1999/09/14 01:13:01	1.55
--- elf-bfd.h	1999/11/17 02:26:58
*************** struct elf_backend_data
*** 329,346 ****
    /* The maximum page size for this backend.  */
    bfd_vma maxpagesize;
  
-   /* This is true if the linker should act like collect and gather
-      global constructors and destructors by name.  This is true for
-      MIPS ELF because the Irix 5 tools can not handle the .init
-      section.  */
-   boolean collect;
- 
-   /* This is true if the linker should ignore changes to the type of a
-      symbol.  This is true for MIPS ELF because some Irix 5 objects
-      record undefined functions as STT_OBJECT although the definitions
-      are STT_FUNC.  */
-   boolean type_change_ok;
- 
    /* A function to translate an ELF RELA relocation to a BFD arelent
       structure.  */
    void (*elf_info_to_howto) PARAMS ((bfd *, arelent *,
--- 329,334 ----
*************** struct elf_backend_data
*** 600,605 ****
--- 588,605 ----
    bfd_vma got_header_size;
    bfd_vma plt_header_size;
  
+   /* This is true if the linker should act like collect and gather
+      global constructors and destructors by name.  This is true for
+      MIPS ELF because the Irix 5 tools can not handle the .init
+      section.  */
+   unsigned collect : 1;
+ 
+   /* This is true if the linker should ignore changes to the type of a
+      symbol.  This is true for MIPS ELF because some Irix 5 objects
+      record undefined functions as STT_OBJECT although the definitions
+      are STT_FUNC.  */
+   unsigned type_change_ok : 1;
+ 
    /* Whether the backend may use REL relocations.  (Some backends use
       both REL and RELA relocations, and this flag is set for those
       backends.)  */
*************** struct elf_backend_data
*** 616,621 ****
--- 616,625 ----
       and the backend wants RELA relocations for a particular
       section.  */
    unsigned default_use_rela_p : 1;
+ 
+   /* True if addresses "naturally" sign extend.  This is used when
+      swapping in from Elf32 when BFD64.  */
+   unsigned sign_extend_vma : 1;
  
    unsigned want_got_plt : 1;
    unsigned plt_readonly : 1;
Index: elf32-mips.c
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elf32-mips.c,v
retrieving revision 1.165
diff -c -p -d -r1.165 elf32-mips.c
*** elf32-mips.c	1999/10/22 15:51:39	1.165
--- elf32-mips.c	1999/11/17 02:26:58
*************** static const struct ecoff_debug_swap mip
*** 9114,9119 ****
--- 9114,9120 ----
  #define elf_backend_collect		true
  #define elf_backend_type_change_ok	true
  #define elf_backend_can_gc_sections	true
+ #define elf_backend_sign_extend_vma	true
  #define elf_info_to_howto		mips_info_to_howto_rela
  #define elf_info_to_howto_rel		mips_info_to_howto_rel
  #define elf_backend_sym_is_global	mips_elf_sym_is_global
Index: elfcode.h
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elfcode.h,v
retrieving revision 1.239
diff -c -p -d -r1.239 elfcode.h
*** elfcode.h	1999/09/14 01:16:13	1.239
--- elfcode.h	1999/11/17 02:26:58
*************** elf_swap_symbol_in (abfd, src, dst)
*** 205,212 ****
       const Elf_External_Sym *src;
       Elf_Internal_Sym *dst;
  {
    dst->st_name = bfd_h_get_32 (abfd, (bfd_byte *) src->st_name);
!   dst->st_value = get_word (abfd, (bfd_byte *) src->st_value);
    dst->st_size = get_word (abfd, (bfd_byte *) src->st_size);
    dst->st_info = bfd_h_get_8 (abfd, (bfd_byte *) src->st_info);
    dst->st_other = bfd_h_get_8 (abfd, (bfd_byte *) src->st_other);
--- 205,217 ----
       const Elf_External_Sym *src;
       Elf_Internal_Sym *dst;
  {
+   int signed_vma = get_elf_backend_data (abfd)->sign_extend_vma;
+ 
    dst->st_name = bfd_h_get_32 (abfd, (bfd_byte *) src->st_name);
!   if (signed_vma)
!     dst->st_value = get_signed_word (abfd, (bfd_byte *) src->st_value);
!   else
!     dst->st_value = get_word (abfd, (bfd_byte *) src->st_value);
    dst->st_size = get_word (abfd, (bfd_byte *) src->st_size);
    dst->st_info = bfd_h_get_8 (abfd, (bfd_byte *) src->st_info);
    dst->st_other = bfd_h_get_8 (abfd, (bfd_byte *) src->st_other);
*************** elf_swap_shdr_in (abfd, src, dst)
*** 293,302 ****
       const Elf_External_Shdr *src;
       Elf_Internal_Shdr *dst;
  {
    dst->sh_name = bfd_h_get_32 (abfd, (bfd_byte *) src->sh_name);
    dst->sh_type = bfd_h_get_32 (abfd, (bfd_byte *) src->sh_type);
    dst->sh_flags = get_word (abfd, (bfd_byte *) src->sh_flags);
!   dst->sh_addr = get_word (abfd, (bfd_byte *) src->sh_addr);
    dst->sh_offset = get_word (abfd, (bfd_byte *) src->sh_offset);
    dst->sh_size = get_word (abfd, (bfd_byte *) src->sh_size);
    dst->sh_link = bfd_h_get_32 (abfd, (bfd_byte *) src->sh_link);
--- 298,312 ----
       const Elf_External_Shdr *src;
       Elf_Internal_Shdr *dst;
  {
+   int signed_vma = get_elf_backend_data (abfd)->sign_extend_vma;
+ 
    dst->sh_name = bfd_h_get_32 (abfd, (bfd_byte *) src->sh_name);
    dst->sh_type = bfd_h_get_32 (abfd, (bfd_byte *) src->sh_type);
    dst->sh_flags = get_word (abfd, (bfd_byte *) src->sh_flags);
!   if (signed_vma)
!     dst->sh_addr = get_signed_word (abfd, (bfd_byte *) src->sh_addr);
!   else
!     dst->sh_addr = get_word (abfd, (bfd_byte *) src->sh_addr);
    dst->sh_offset = get_word (abfd, (bfd_byte *) src->sh_offset);
    dst->sh_size = get_word (abfd, (bfd_byte *) src->sh_size);
    dst->sh_link = bfd_h_get_32 (abfd, (bfd_byte *) src->sh_link);
*************** elf_swap_phdr_in (abfd, src, dst)
*** 339,349 ****
       const Elf_External_Phdr *src;
       Elf_Internal_Phdr *dst;
  {
    dst->p_type = bfd_h_get_32 (abfd, (bfd_byte *) src->p_type);
    dst->p_flags = bfd_h_get_32 (abfd, (bfd_byte *) src->p_flags);
    dst->p_offset = get_word (abfd, (bfd_byte *) src->p_offset);
!   dst->p_vaddr = get_word (abfd, (bfd_byte *) src->p_vaddr);
!   dst->p_paddr = get_word (abfd, (bfd_byte *) src->p_paddr);
    dst->p_filesz = get_word (abfd, (bfd_byte *) src->p_filesz);
    dst->p_memsz = get_word (abfd, (bfd_byte *) src->p_memsz);
    dst->p_align = get_word (abfd, (bfd_byte *) src->p_align);
--- 349,369 ----
       const Elf_External_Phdr *src;
       Elf_Internal_Phdr *dst;
  {
+   int signed_vma = get_elf_backend_data (abfd)->sign_extend_vma;
+ 
    dst->p_type = bfd_h_get_32 (abfd, (bfd_byte *) src->p_type);
    dst->p_flags = bfd_h_get_32 (abfd, (bfd_byte *) src->p_flags);
    dst->p_offset = get_word (abfd, (bfd_byte *) src->p_offset);
!   if (signed_vma)
!     {
!       dst->p_vaddr = get_signed_word (abfd, (bfd_byte *) src->p_vaddr);
!       dst->p_paddr = get_signed_word (abfd, (bfd_byte *) src->p_paddr);
!     }
!   else
!     {
!       dst->p_vaddr = get_word (abfd, (bfd_byte *) src->p_vaddr);
!       dst->p_paddr = get_word (abfd, (bfd_byte *) src->p_paddr);
!     }
    dst->p_filesz = get_word (abfd, (bfd_byte *) src->p_filesz);
    dst->p_memsz = get_word (abfd, (bfd_byte *) src->p_memsz);
    dst->p_align = get_word (abfd, (bfd_byte *) src->p_align);
Index: elfxx-target.h
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elfxx-target.h,v
retrieving revision 1.42
diff -c -p -d -r1.42 elfxx-target.h
*** elfxx-target.h	1999/07/19 07:54:12	1.42
--- elfxx-target.h	1999/11/17 02:26:59
*************** Foundation, Inc., 59 Temple Place - Suit
*** 332,337 ****
--- 332,341 ----
  #define elf_backend_size_info _bfd_elfNN_size_info
  #endif
  
+ #ifndef elf_backend_sign_extend_vma
+ #define elf_backend_sign_extend_vma 0
+ #endif
+ 
  extern const struct elf_size_info _bfd_elfNN_size_info;
  
  static CONST struct elf_backend_data elfNN_bed =
*************** static CONST struct elf_backend_data elf
*** 339,346 ****
    ELF_ARCH,			/* arch */
    ELF_MACHINE_CODE,		/* elf_machine_code */
    ELF_MAXPAGESIZE,		/* maxpagesize */
-   elf_backend_collect,
-   elf_backend_type_change_ok,
    elf_info_to_howto,
    elf_info_to_howto_rel,
    elf_backend_sym_is_global,
--- 343,348 ----
*************** static CONST struct elf_backend_data elf
*** 376,384 ****
--- 378,389 ----
    elf_backend_got_symbol_offset,
    elf_backend_got_header_size,
    elf_backend_plt_header_size,
+   elf_backend_collect,
+   elf_backend_type_change_ok,
    elf_backend_may_use_rel_p,
    elf_backend_may_use_rela_p,
    elf_backend_default_use_rela_p,
+   elf_backend_sign_extend_vma,
    elf_backend_want_got_plt,
    elf_backend_plt_readonly,
    elf_backend_want_plt_sym,
From kevinb@cygnus.com Tue Nov 16 18:36:00 1999
From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: PACKET_OVERHEAD constant added to remote.c
Date: Tue, 16 Nov 1999 18:36:00 -0000
Message-id: <991117023545.ZM28115@ocotillo.lan>
References: <991112184146.ZM22052@ocotillo.lan> <38308EDB.A02AF873@cygnus.com> <991115233403.ZM17177@ocotillo.lan> <3830BF79.F43EEE0A@cygnus.com> <991116041240.ZM24569@ocotillo.lan> <3831A6A7.245C4FCA@cygnus.com> <991116215839.ZM27486@ocotillo.lan> <3831FF46.65118BCC@cygnus.com> <ac131313@cygnus.com>
X-SW-Source: 1999-q4/msg00277.html
Content-length: 366

On Nov 17, 12:05pm, Andrew Cagney wrote:

> What about the following:
[...]
> o	fix the *_read_bytes() code so that it allocates
> 	a buffer that includes space for the trailing
> 	NUL.

I finally see!  I thought we needed to account framing characters,
checksum, and the packet headers.  (Which was why I was subtracting
32.) But we're only off by a NUL character.
From ac131313@cygnus.com Tue Nov 16 22:17:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: arm-opcode.h -> opcode/arm.h
Date: Tue, 16 Nov 1999 22:17:00 -0000
Message-id: <38324859.8207A651@cygnus.com>
X-SW-Source: 1999-q4/msg00278.html
Content-length: 836

Stumbled across the below.

I'm just wondering if arm-xdep.c should also (finally) be renamed to
arm-nat.c.

Ok?

	Andrew
Wed Nov 17 17:01:06 1999  Andrew Cagney  <cagney@b1.cygnus.com>

	* arm-xdep.c: #include "arm-opcode.h" -> "opcode/arm.h".
+ 
Index: arm-xdep.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/arm-xdep.c,v
retrieving revision 1.18
diff -p -r1.18 arm-xdep.c
*** arm-xdep.c	1999/08/08 07:19:43	1.18
--- arm-xdep.c	1999/11/17 06:03:54
***************
*** 21,27 ****
  #include "defs.h"
  #include "frame.h"
  #include "inferior.h"
! #include "arm-opcode.h"
  
  #include <sys/param.h>
  #include <sys/dir.h>
--- 21,27 ----
  #include "defs.h"
  #include "frame.h"
  #include "inferior.h"
! #include "opcode/arm.h"
  
  #include <sys/param.h>
  #include <sys/dir.h>
From scottb@netwinder.org Wed Nov 17 05:18:00 1999
From: Scott Bambrough <scottb@netwinder.org>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: arm-opcode.h -> opcode/arm.h
Date: Wed, 17 Nov 1999 05:18:00 -0000
Message-id: <3832AA44.4DD62773@netwinder.org>
References: <38324859.8207A651@cygnus.com>
X-SW-Source: 1999-q4/msg00279.html
Content-length: 596

Andrew Cagney wrote:
> 
> I'm just wondering if arm-xdep.c should also (finally) be renamed to
> arm-nat.c.
> 
Actually I have a patch submitted to add a linux target to the ARM
tree.  I don't think this file is used by anyone anymore.  I think it is
a relic of an old RiscOS port that no one maintains anymore.  I can't
see it being used for any of the embedded targets, and the only native
targets supported in the tree ATM, are RiscOS and maybe NetBSD (though I
doubt it).

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From rearnsha@arm.com Wed Nov 17 06:09:00 1999
From: Richard Earnshaw <rearnsha@arm.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: richard.earnshaw@arm.com
Subject: Re: arm-opcode.h -> opcode/arm.h 
Date: Wed, 17 Nov 1999 06:09:00 -0000
Message-id: <199911171408.OAA12960@cam-mail1.cambridge.arm.com>
References: <3832AA44.4DD62773@netwinder.org>
X-SW-Source: 1999-q4/msg00280.html
Content-length: 637

> Andrew Cagney wrote:
> > 
> > I'm just wondering if arm-xdep.c should also (finally) be renamed to
> > arm-nat.c.
> > 
> Actually I have a patch submitted to add a linux target to the ARM
> tree.  I don't think this file is used by anyone anymore.  I think it is
> a relic of an old RiscOS port that no one maintains anymore.  I can't
> see it being used for any of the embedded targets, and the only native
> targets supported in the tree ATM, are RiscOS and maybe NetBSD (though I
> doubt it).
> 

It was RISC iX, not RISC OS, but it's probably dead these days.

NetBSD isn't supported in the tree, but I am working on a port.

R.

Re: (patch) hpjyg23: gdbtypes.[ch] & values.c

[Jeffrey A Law]

  In message < 3831BAF0.269CEFA1@cygnus.com >you write:
  > Jimmy Guo wrote:
  > > 
  > 
  > > >BFD64:  I'm not sure this is the right test. Should some characteristic
  > > >of the ABFD be tested instead?
  > > 
  > > Suggestion for a better alternative is appreciated.
  > 
  > Hmm, TARGET_PTR_BIT indicates the size of a target C-pointer but doesn't
  > help when it comes to the object file.
  > 
  > Checking through the BFD code it looks like there isn't anything to
  > determine the address size of the object file being loaded.  Sorry.
This information is kept in the architecture/machine structures.  See
cpu-hppa.c for examples.

Once you know the architecture/machine you can extract the size of a word,
pointer or byte for the target.

jeff