From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ralf Baechle To: ulfc@calypso.engr.sgi.com, ac131313@cygnus.com, alan@linuxcare.com.au, binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com, geoffk@cygnus.com Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Sun, 25 Jun 2000 14:13:00 -0000 Message-id: <20000625224009.A3529@bacchus.dhis.org> References: <394EC637.24300B87@cygnus.com> <14670.52424.697477.308492@calypso.engr.sgi.com> <200006200307.UAA10516@localhost.cygnus.com> <20000620034102.18244.qmail@daffy.airs.com> X-SW-Source: 2000-06/msg00306.html 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 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 > > 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 To: Eli Zaretskii , Andrew Cagney 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 >> >> ChangeLog entry: >> >> 2000-06-19 Muller Pierre >> * 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." 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. 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 +#undef savestring #include #include --- 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 +#undef savestring #include /* 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 +#undef savestring #include /* 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 +#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 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> 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 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 > > > >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.