Re: [rfc] For mips, sign-extended ecoff offsets

Re: [rfc] For mips, sign-extended ecoff offsets

[Andrew Cagney]

(I've been away for a week, sorry)

Ian Lance Taylor wrote:
> 
>    >  But the real fix is to use a
>    > 64-bit MIPS target.
> 
>    Kind of :-)  GDB can now be built to support (embedded only mind) the
>    debugging of a fairly arbitrary MIPS ABI on 64 bit MIPS targets.  For
>    instance, a single GDB executable can debug both ``gcc -mips2'' and
>    ``gcc ...'' executables running on a 64 bit vr5000.  It might even
>    eventually support that behavour under IRIX :-)
> 
>    Implementing this cleanly relies 32 bit MIPS addresses always being
>    correctly sign extended.  At present they are not and things are
>    suffering for it :-)
> 
> I don't understand that.  When gdb is debugging a 32 bit target, such
> as gcc -mips2, it should handle all target addresses as 32 bit values.
> Anything else would be a host/target confusion.  Sign extension or
> lack thereof should be irrelevant.

GDB has two things to contend with:

	o	the program - gcc -mips2 (32 bit) (ABI)

	o	the physical target - 32 or 64 bit (ISA)

When debugging a 32 bit program on what is a 64 bit physical target, GDB
could communicate using either 32 or 64 bit values/addresses.  GDB
started out by trying to follow the ABI and talk 32bit to 64 bit
physical targets.

It turns out this was a bad idea.  Instead, GDB should always talk
64bits to 64 bit physical targets.  This simplifies both the embedded
stub and GDBs internals.  In the case of GDB, the simplification comes
from replacing scrambled code trying to directly convert
symbolic-address <-> target-address with two clearly separate
translations - symbol<->canonical and cannonical<->target address.

> The only issue here is that, for historical reasons, some 64 bit
> targets use a 32 bit object file format.  If each 64 bit target used a
> 64 bit object file format, all would be well.

Yes, for the MIPS that is how things started.

Since then, however, things have evolved and now people are trying to do
things like build single GDB binaries that can debug (on IRIX) any of
n32, o32 and o64.

	enjoy,
		Andrew
From aoliva@redhat.com Mon Jul 03 23:51:00 2000
From: Alexandre Oliva <aoliva@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Subject: ARM sim exceptions: adjust LR properly in Thumb mode
Date: Mon, 03 Jul 2000 23:51:00 -0000
Message-id: <orbt0ee6bl.fsf@guarana.lsd.ic.unicamp.br>
X-SW-Source: 2000-07/msg00027.html
Content-length: 49

I'm checking this in, approved by Nick Clifton:

Re: [rfc] For mips, sign-extended ecoff offsets

[Alan Modra]

On Mon, 19 Jun 2000, Ulf Carlsson wrote:

> On a 64-bit MIPS processor 32-bit addresses are of course sign
> extended, but this shouldn't concern the 32-bit BFD backend for MIPS
> in any way.  Whether we sign extend the addresses or not shouldn't
> make any difference except in our internal representation of the
> bfd_vma.  I may be wrong though!

It doesn't make much difference if bfd_vma is only 32-bits (ie. BFD_64 is
not set)  Where you get into trouble is with targets that are generally
32-bit, but you may be using 64-bit bfd_vma types due to --enable-targets

-- 
Linuxcare.  Support for the Revolution.

Re: [rfc] For mips, sign-extended ecoff offsets

[Ralf Baechle]

On Mon, Jun 19, 2000 at 08:41:02PM -0700, Ian Lance Taylor wrote:

>    > On a 64-bit MIPS processor 32-bit addresses are of course sign
>    > extended, but this shouldn't concern the 32-bit BFD backend for MIPS
>    > in any way.  Whether we sign extend the addresses or not shouldn't
>    > make any difference except in our internal representation of the
>    > bfd_vma.  I may be wrong though!
> 
>    The 64-bit MIPS machines often use the 32-bit ELF format, typically
>    because they have 32-bit memory addresses (I forget whether trying to
>    access 0x0000000087654321 gives you 0xffffffff87654321 or a trap).
> 
> I think the real reason this happens is historical--because we didn't
> have a 64-bit MIPS format when we started supporting 64-bit MIPS
> chips.  I don't think there is any particularly legitimate reason to
> use a 32-bit format for a 64-bit chip.

We do that for Linux/MIPS64.  Originally I came up with this due to the
incredible brokeness of ld for 64-bit MIPS ELF.  It allows us to generate
64-bit code that is more compact than standard 64-bit code because dla get
expanded to only 2 instructions like in 32-bit code.  All it takes is
proper placement of the code into the 32-bit address space.  We still
have kept the advantages of 64-bit code.

  Ralf
From eliz@delorie.com Sun Jun 25 22:37:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Stephane.Carrez@free.fr
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [Patch 2/7]: 68HC11 port of gdb (sim)
Date: Sun, 25 Jun 2000 22:37:00 -0000
Message-id: <200006260537.BAA09053@indy.delorie.com>
References: <395689E9.2E071E0@free.fr>
X-SW-Source: 2000-06/msg00307.html
Content-length: 638

> Date: Mon, 26 Jun 2000 00:38:33 +0200
> From: Stephane Carrez <Stephane.Carrez@free.fr>
> 
> This patch represents the 68hc11 simulator.

Thanks!

> gdb/sim/m68hc11/dv-m68hc11.c
> gdb/sim/m68hc11/dv-m68hc11eepr.c
> gdb/sim/m68hc11/dv-m68hc11sio.c
> gdb/sim/m68hc11/dv-m68hc11spi.c
> gdb/sim/m68hc11/dv-m68hc11tim.c

The names of these 5 files all clash after truncation to DOS 8+3
namespace limits, so they make it harder for users to unpack the GDB
distribution on MS-DOS and Windows 3.X systems.  Since these files are
all in an m68hc11 subdirectory, I wonder whether you could remove the
m68hc11 part from the file names altogether?
From muller@cerbere.u-strasbg.fr Mon Jun 26 01:02:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Eli Zaretskii <eliz@is.elta.co.il>, Andrew Cagney <ac131313@cygnus.com>
Cc: taylor@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] Pascal language part 3: Changes to Makefile.in
Date: Mon, 26 Jun 2000 01:02:00 -0000
Message-id: <200006260823.KAA27064@cerbere.u-strasbg.fr>
References: <200006191043.MAA24719@cerbere.u-strasbg.fr>
X-SW-Source: 2000-06/msg00308.html
Content-length: 1264

At 02:54 24/06/00 -0400, Eli Zaretskii wrote:
>> Date: Mon, 19 Jun 2000 12:17:39 +0200
>> From: Pierre Muller <muller@cerbere.u-strasbg.fr>
>> 
>> ChangeLog entry:
>> 
>> 2000-06-19  Muller Pierre <muller@ics.u-strasbg.fr>
>>    * Makefile.in: add rules to compile and link pascal specific files.
>
>Sorry for the long delay in reacting to this.
>
>> + # p-exp.tab.c is generated in objdir from p-exp.y if it doesn't exist
>> + # in srcdir, then compiled in objdir to p-exp.tab.o.
>
>The new file p-exp.tab.c needs a line to be added to
>gdb/config/djgpp/fnchange.lst, like this:
>
>  @V@/gdb/p-exp.tab.c @V@/gdb/p-exp_tab.c

  Should I ally this patch together with the Makefile.in changes or just 
send a mail to Eli to ask him to check this patch in when I check in the
Makefile.in changes.

  For the moment, I still got no replies about the validity of the patch
itself.
Did someone already try to recompile GDB after applying this patch?

  I was in particular unsure about possible problems when cross-compiling
from or
to processors having different int or pointer type length.



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From gin@mo.msk.ru Mon Jun 26 06:28:00 2000
From: "Golubev I. N." <gin@mo.msk.ru>
To: gdb-patches@sourceware.cygnus.com
Subject: savestring dcls conflict
Date: Mon, 26 Jun 2000 06:28:00 -0000
Message-id: <023839575a5055-gin@mo.msk.ru>
X-SW-Source: 2000-06/msg00309.html
Content-length: 2091

Version: 5.0 with readline-4.1

I still do not think that gdb must be built only with its own
readline.

Definitions and behavior of savestring functions in readline and gdb
are different.  <readline/readline.h> provides dcl of its own way and
provides a way to block away this dcl.  I patch gdb to make use of
blocking away method and avoid conflicts of dcls with compilation
errors.  If header does not contain dcl in question, no harm is done.

--- gdb/event-top.c	2000/06/19 13:07:57	1.1
+++ gdb/event-top.c	2000/06/19 13:13:26	1.2
@@ -32,7 +32,11 @@
 #include "gdbcmd.h"
 
 /* readline include files */
+/* so we can use vanilla `readline.h': block away `savestring' dcl we
+   do not want to use; we use our one instead */
+#define savestring
 #include <readline/readline.h>
+#undef savestring
 #include <readline/history.h>
 
 #include <signal.h>
--- gdb/tracepoint.c	2000/06/19 13:16:17	1.1
+++ gdb/tracepoint.c	2000/06/19 13:19:48	1.2
@@ -36,7 +36,11 @@
 #include "ax-gdb.h"
 
 /* readline include files */
+/* so we can use vanilla `readline.h': block away `savestring' dcl we
+   do not want to use; we use our one instead */
+#define savestring
 #include <readline/readline.h>
+#undef savestring
 #include <readline/history.h>
 
 /* readline defines this.  */
--- gdb/top.c	2000/06/19 13:16:32	1.1
+++ gdb/top.c	2000/06/19 13:19:48	1.2
@@ -36,7 +36,11 @@
 #include "version.h"
 
 /* readline include files */
+/* so we can use vanilla `readline.h': block away `savestring' dcl we
+   do not want to use; we use our one instead */
+#define savestring
 #include <readline/readline.h>
+#undef savestring
 #include <readline/history.h>
 
 /* readline defines this.  */
--- gdb/utils.c	2000/06/19 13:16:33	1.1
+++ gdb/utils.c	2000/06/19 13:19:48	1.2
@@ -50,7 +50,11 @@
 #include "language.h"
 #include "annotate.h"
 
+/* so we can use vanilla `readline.h': block away `savestring' dcl we
+   do not want to use; we use our one instead */
+#define savestring
 #include <readline/readline.h>
+#undef savestring
 
 #undef XMALLOC
 #define XMALLOC(TYPE) ((TYPE*) xmalloc (sizeof (TYPE)))
From kevinb@cygnus.com Mon Jun 26 23:46:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] PARAMS elimination: copying.awk
Date: Mon, 26 Jun 2000 23:46:00 -0000
Message-id: <1000627064608.ZM7213@ocotillo.lan>
References: <1000622072725.ZM1668@ocotillo.lan> <kevinb@cygnus.com>
X-SW-Source: 2000-06/msg00310.html
Content-length: 441

On Jun 22, 12:27am, Kevin Buettner wrote:

> [Whew! The last file, I think.]
> 
> More PARAMS elimination... As before, I'll wait two days for comments
> and objections before committing the changes below.
> 
> BTW, I just noticed that copying.c had its PARAMS eliminated in my
> mega-patch on 2000-05-27.  So it's about time that copying.awk got
> fixed up to match.
> 
> 	* copying.awk: Eliminate use of PARAMS from this file.

Committed.
From eliz@delorie.com Tue Jun 27 04:12:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: muller@cerbere.u-strasbg.fr
Cc: ac131313@cygnus.com, taylor@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] Pascal language part 3: Changes to Makefile.in
Date: Tue, 27 Jun 2000 04:12:00 -0000
Message-id: <200006271112.HAA10628@indy.delorie.com>
References: <200006191043.MAA24719@cerbere.u-strasbg.fr> <200006260823.KAA27064@cerbere.u-strasbg.fr>
X-SW-Source: 2000-06/msg00311.html
Content-length: 553

> Date: Mon, 26 Jun 2000 09:56:10 +0200
> From: Pierre Muller <muller@cerbere.u-strasbg.fr>
> >
> >The new file p-exp.tab.c needs a line to be added to
> >gdb/config/djgpp/fnchange.lst, like this:
> >
> >  @V@/gdb/p-exp.tab.c @V@/gdb/p-exp_tab.c
> 
>   Should I ally this patch together with the Makefile.in changes or just 
> send a mail to Eli to ask him to check this patch in when I check in the
> Makefile.in changes.

It would be nice if you committed both changes at the same time, so as
to keep the repository consistent at all times.  Thanks.