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

[Ralf Baechle <ralf@oss.sgi.com>]

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.