* Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) [not found] ` <395013E2.D78A2EE2@cygnus.com> @ 2000-06-20 20:39 ` Michael Snyder 0 siblings, 0 replies; 7+ messages in thread From: Michael Snyder @ 2000-06-20 20:39 UTC (permalink / raw) To: Andrew Cagney; +Cc: James Wilson, Jim Blandy, ezannoni, gdb-patches Andrew Cagney wrote: > LONGEST is C's equivalent to ``long'' the longest type and can fit a > CORE_ADDR. Hmmm, no, LONGEST has nothing to do with a CORE_ADDR. LONGEST is the largest integer type available in the compiler. If the compiler supports (long long), then LONGEST is (long long). Else it's usually long. It's a convention for "gimme the biggest int ya got". From ac131313@cygnus.com Tue Jun 20 21:42:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: msnyder@cygnus.com Cc: James Wilson <wilson@cygnus.com>, Jim Blandy <jimb@cygnus.com>, ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) Date: Tue, 20 Jun 2000 21:42:00 -0000 Message-id: <395047AE.BA21BB8F@cygnus.com> References: <200006200213.TAA22932@wilson.cygnus.com> <395013E2.D78A2EE2@cygnus.com> <395037E9.73C3@cygnus.com> X-SW-Source: 2000-06/msg00259.html Content-length: 714 Michael Snyder wrote: > > Andrew Cagney wrote: > > > LONGEST is C's equivalent to ``long'' the longest type and can fit a > > CORE_ADDR. > Hmmm, no, LONGEST has nothing to do with a CORE_ADDR. > LONGEST is the largest integer type available in the compiler. well: sizeof (CORE_ADDR) >= TARGET_PTR_BIT / HOST_CHAR_BIT sizeof (LONGEST) >= TARGET_LONG_LONG_BIT / HOST_CHAR_BIT CORE_ADDR is a host integer type large enough to hold a canonical target address LONGEST is the largest host integer type supported by the host giving: sizeof (LONGEST) >= sizeof (CORE_ADDR) :-) Much code (unfortunatly?) assumes that a CORE_ADDR can be passed into a LONGEST (whether doing so is correct or not). Andrew From eliz@delorie.com Wed Jun 21 00:05:00 2000 From: Eli Zaretskii <eliz@delorie.com> To: kevinb@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] TARGET_ADJUST_BREAKPOINT_ADDRESS... Date: Wed, 21 Jun 2000 00:05:00 -0000 Message-id: <200006210705.DAA02630@indy.delorie.com> References: <1000621031433.ZM31859@ocotillo.lan> X-SW-Source: 2000-06/msg00260.html Content-length: 959 > Date: Tue, 20 Jun 2000 20:14:33 -0700 > From: Kevin Buettner <kevinb@cygnus.com> > > If a breakpoint address is adjusted, there's some new code in > breakpoint.c which'll print out a warning. Such a warning might > look something like this... > > (gdb) b foo > warning: Breakpoint address moved from 0x06200090 to 0x0620008c. > Breakpoint 1 at 0x0620008c: file bar.c, line 21. Printing a message is a good idea, but making it a warning IMHO is not. Warning is for some potential trouble, while in this case GDB is doing The Right Thing. Printing a warning will confuse users. Perhaps we should make the information about moving the breakpoint part of the "Breakpoint 1 at ..." message. My other comment is about hardware-assisted breakpoints: it looks like, at least in some of the examples you gave, the address of hardware-assisted breakpoints will also need to be adjusted in the same way. So I think we need some provision for that as well. From muller@cerbere.u-strasbg.fr Wed Jun 21 03:00:00 2000 From: Pierre Muller <muller@cerbere.u-strasbg.fr> To: Jim Blandy <jimb@zwingli.cygnus.com> Cc: Mark Kettenis <kettenis@wins.uva.nl>, taylor@cygnus.com, ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] Pascal language part 4: Changes to symfile.c: commited Date: Wed, 21 Jun 2000 03:00:00 -0000 Message-id: <200006211020.MAA25998@cerbere.u-strasbg.fr> References: <Pierre> <Muller's> <message> <of> <Mon,> <19> <Jun> <2000> <12:57:27> <+0200> <200006191048.MAA24798@cerbere.u-strasbg.fr> <200006191123.NAA25313@cerbere.u-strasbg.fr> X-SW-Source: 2000-06/msg00261.html Content-length: 1510 >This table is used for deriving the language from the compilation >unit's main source file. Unless people compile .inc files separately, >.inc shouldn't appear here. OK, I thought it was based on the current file extension, I then of course completely agree that .inc should not be included. >If you remove .inc from the list, and then discover you have problems, >please let us know. > >This change is approved, assuming Mark's and my suggestions are >followed. Thus I commited the following: ChangeLog entry: 2000-06-21 Pierre Muller <muller@ics.u-strasbg.fr> * symfile.c (init_filename_language_table): add ".pas", ".p" and ".pp" as pascal source file extensions. Index: symfile.c =================================================================== RCS file: /cvs/src/src/gdb/symfile.c,v retrieving revision 1.14 diff -c -r1.14 symfile.c *** symfile.c 2000/06/16 21:02:21 1.14 --- symfile.c 2000/06/21 09:56:46 *************** *** 1925,1930 **** --- 1925,1933 ---- add_filename_language (".F", language_fortran); add_filename_language (".s", language_asm); add_filename_language (".S", language_asm); + add_filename_language (".pas", language_pascal); + add_filename_language (".p", language_pascal); + add_filename_language (".pp", language_pascal); } } 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 muller@cerbere.u-strasbg.fr Wed Jun 21 03:37:00 2000 From: Pierre Muller <muller@cerbere.u-strasbg.fr> To: gdb-patches@sourceware.cygnus.com Subject: Pascal language support patch4: commit error Date: Wed, 21 Jun 2000 03:37:00 -0000 Message-id: <200006211057.MAA26574@cerbere.u-strasbg.fr> References: <Pierre> <Muller's> <message> <of> <Mon,> <19> <Jun> <2000> <12:57:27> <+0200> <200006191048.MAA24798@cerbere.u-strasbg.fr> <200006191123.NAA25313@cerbere.u-strasbg.fr> X-SW-Source: 2000-06/msg00262.html Content-length: 605 I made a small erro when committing my patch for symfile.c which resulted in a wrong formating of the ChangeLog entry and some text that was not appropriate at that place (revision 1.495) As I noticed it just after my commit, I took the liberty to recommit ChangeLog (v 1.496) directly after with the correct info. I hope this was not an abuse of the commit rules by myself. With the deepest apologies for this error. 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 macro@ds2.pg.gda.pl Wed Jun 21 07:12:00 2000 From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> To: gdb-patches@sourceware.cygnus.com Subject: gdb 5.0: Distclean in sim/common does not remove cconfig.h (fwd) Date: Wed, 21 Jun 2000 07:12:00 -0000 Message-id: <Pine.GSO.3.96.1000621161304.28897O-100000@delta.ds2.pg.gda.pl> X-SW-Source: 2000-06/msg00263.html Content-length: 1208 ---------- Forwarded message ---------- Message-ID: <Pine.GSO.3.96.1000619183456.10348N-100000@delta.ds2.pg.gda.pl> Date: Mon, 19 Jun 2000 18:40:36 +0200 (MET DST) From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> To: bug-gdb@gnu.org Subject: gdb 5.0: Distclean in sim/common does not remove cconfig.h Hi, Upon running `make distclean' sim/common/cconfig.h does not get removed. That's probably because the generated file used to be named config.h. The following obvious patch fixes the problem for me. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + diff -u --recursive --new-file gdb-5.0.macro/sim/common/Makefile.in gdb-5.0/sim/common/Makefile.in --- gdb-5.0.macro/sim/common/Makefile.in Mon Jul 19 23:29:41 1999 +++ gdb-5.0/sim/common/Makefile.in Sat Jun 17 13:12:53 2000 @@ -113,7 +113,7 @@ distclean mostlyclean maintainer-clean realclean: clean rm -f TAGS rm -f Makefile config.cache config.log config.status - rm -f config.h stamp-h + rm -f cconfig.h stamp-h # Dummy target to force execution of dependent targets. force: ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <200006090053.RAA14301@ada.cygnus.com.cygnus.com>]
[parent not found: <14664.971.753679.67153@kwikemart.cygnus.com>]
* Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) [not found] ` <14664.971.753679.67153@kwikemart.cygnus.com> @ 2000-06-14 17:52 ` Michael Snyder 2000-06-15 20:05 ` Elena Zannoni 2000-06-19 16:41 ` James Wilson 0 siblings, 2 replies; 7+ messages in thread From: Michael Snyder @ 2000-06-14 17:52 UTC (permalink / raw) To: Elena Zannoni; +Cc: Jim Wilson, gdb-patches Elena Zannoni wrote: > > Jim Wilson writes: > > Jim, any chance you could turn the tests into a gdb testfile? Elena, I thought I would take a stab at it. Seemed like it might belong in exprs.exp. I noticed that exprs.exp seems kind of unfinished -- it sets up as if to do some enum tests, but doesn't actually do them! So I added some, including some for long enums. See below. You approve? Unfortunately I don't have Jim's compiler patch, so I can't test my tests. Jim, can you test them for me? 2000-06-14 Michael Snyder <msnyder@seadog.cygnus.com> * gdb.base/exprs.exp: Add tests for enum expressions. * gdb.base/exprs.c: Ditto. From ac131313@cygnus.com Wed Jun 14 18:06:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Michael Snyder <msnyder@cygnus.com> Cc: gdb-patches@sourceware.cygnus.com, jimb@sourceware.cygnus.com, ezannoni@sourceware.cygnus.com Subject: Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) Date: Wed, 14 Jun 2000 18:06:00 -0000 Message-id: <39482C06.D2521C1C@cygnus.com> References: <200006090053.RAA14301@ada.cygnus.com.cygnus.com> <3947FEC7.2BAC@cygnus.com> X-SW-Source: 2000-06/msg00176.html Content-length: 425 Michael Snyder wrote: > > Hi Jim, > > Jim Blandy, our Dwarf maintainer, is occupied right now. > I think your change looks good -- I only worry that we have > no guarantee that even a long will be 64-bits. I suppose a > long is more likely to be correct than an int... Hmm, Would need to be LONGEST then. Looking further and ending up in bfd_getl64(). Yes, definitly. As they say, how did this work at all? :-) Andrew From john_w_marshall@palm.com Wed Jun 14 20:24:00 2000 From: John Marshall <john_w_marshall@palm.com> To: gdb-patches@sourceware.cygnus.com (gdb-patches) Subject: [patch] make coff-solib.c compile Date: Wed, 14 Jun 2000 20:24:00 -0000 Message-id: <200006150321.UAA22785@kovalevskaya.palm.com> X-SW-Source: 2000-06/msg00177.html Content-length: 748 When building a cross debugger to eg m68k-lynxos (eg from i686-pc-linux-gnu), coff-solib.c won't compile because there's no definition of OBJF_SHARED. This gets it compiling. I'm not sure this is the right place to #include these headers, but it does compare favourably with the lists of #includes in the other *-solib.c files. John 2000-06-14 John Marshall <john_w_marshall@palm.com> * coff-solib.c: Include symfile.h and objfiles.h to make OBJF_SHARED visible. --- gdb+dejagnu-20000614/gdb/coff-solib.c.orig Wed Jun 14 20:06:07 2000 +++ gdb+dejagnu-20000614/gdb/coff-solib.c Wed Jun 14 20:06:22 2000 @@ -25,6 +25,8 @@ #include "bfd.h" #include "gdbcore.h" #include "symtab.h" +#include "symfile.h" +#include "objfiles.h" /* From muller@cerbere.u-strasbg.fr Thu Jun 15 01:13:00 2000 From: Pierre Muller <muller@cerbere.u-strasbg.fr> To: gdb-patches@sourceware.cygnus.com Subject: [PATCH]: Pascal language support : New files, commited Date: Thu, 15 Jun 2000 01:13:00 -0000 Message-id: <200006150832.KAA31285@cerbere.u-strasbg.fr> X-SW-Source: 2000-06/msg00178.html Content-length: 1018 >Feel free to commit the files. Since nothing uses them right now, >nothing will be harmed by committing them. You should make the >changes that Stan pointed out; but feel free to make them after you >do the initial commit of the files, if you wish. Done! All pas_XXX functions were renamed pascal_XXX. The references to C++ specific code are either removed or changed to specify object pascal specific stuff. ChangeLog 2000-06-14 Pierre Muller <muller@ics.u-strasbg.fr> Add support for Pascal language. Part 1: new files. * p-exp.y, p-lang.c, p-lang.h, p-typeprint.c, p-valprint.c: New files. PS: I sent this message with a day delay, because I probably made a mistake on my first emission which made that it was not sent to gdb-patches list. I orignally sent this message before [PATCH RFA] Pascal language part 2. 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 spolk@redhat.com Thu Jun 15 14:02:00 2000 From: Syd Polk <spolk@redhat.com> To: Jonathan Larmour <jlarmour@redhat.co.uk>, gdb-patches@sourceware.cygnus.com Subject: Re: RFA: Fix itcl/iwidgets config script search Date: Thu, 15 Jun 2000 14:02:00 -0000 Message-id: <4.2.0.58.20000615140225.00d0a910@pop.cygnus.com> References: <3949324E.E7268CD@redhat.co.uk> X-SW-Source: 2000-06/msg00179.html Content-length: 3450 At 08:45 PM 6/15/00 +0100, you wrote: >I found that when installing a new version of Insight over an old one that >had been built from sources that no longer existed, it failed with the same >error as described in > http://sourceware.cygnus.com/ml/insight/2000-q2/msg00212.html > >The reason is that itcl/iwidgets2.0.0/unix/configure.in is picking up the >itclConfig.sh etc. files from exec_prefix first, and using that to >determine the location of mkinstalldirs from e.g. ITCL_SRC_DIR set there. >This is bad as it refers to the old sources. > >The best fix is to make itcl/iwidgets2.0.0/unix/configure.in consistent >with tcl, tk, itcl/itcl and itcl/itk by searching in the build tree before >the exec_prefix dir, since what is in the build tree is what is going to be >installed. > >Okay to check in? 5.0 branch as well? I assume that in your description, you meant iwidgets3.0.0, since that is what your patch says. Assuming that is true, you may check this in. >Jifl > >2000-06-15 Jonathan Larmour <jlarmour@redhat.co.uk> > > * iwidgets3.0.0/unix/configure.in: Use config scripts from build > tree before exec_prefix > > >-- >Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 >"Plan to be spontaneous tomorrow." || These opinions are all my own >faultIndex: configure.in >=================================================================== >RCS file: /cvs/src/src/itcl/iwidgets3.0.0/unix/configure.in,v >retrieving revision 1.1.1.1 >diff -u -5 -p -r1.1.1.1 configure.in >--- configure.in 2000/02/07 00:19:47 1.1.1.1 >+++ configure.in 2000/06/15 19:37:44 >@@ -43,11 +43,11 @@ cd ${BUILD_DIR} > > AC_ARG_WITH(tcl, [ --with-tcl=DIR use Tcl 8.0 binaries from DIR], > itcl_search=$withval, itcl_search=`cd ../../..; ls -d > \`pwd\`/tcl*/unix`) > > TCL_LIB_DIR="" >-for dir in $exec_prefix/lib $itcl_search ; do >+for dir in $itcl_search $exec_prefix/lib ; do > if test -r $dir/tclConfig.sh; then > TCL_LIB_DIR=$dir > break > fi > done >@@ -65,11 +65,11 @@ fi > > AC_ARG_WITH(tk, [ --with-tk=DIR use Tk 8.0 binaries from DIR], > itcl_search=$withval, itcl_search=`cd ../../..; ls -d > \`pwd\`/tk*/unix`) > > TK_LIB_DIR="" >-for dir in $exec_prefix/lib $TCL_LIB_DIR $itcl_search ; do >+for dir in $itcl_search $TCL_LIB_DIR $exec_prefix/lib ; do > if test -r $dir/tkConfig.sh; then > TK_LIB_DIR=$dir > break > fi > done >@@ -86,11 +86,11 @@ fi > > AC_ARG_WITH(itcl, [ --with-itcl=DIR use Itcl 3.0 binaries from > DIR], > itcl_search=$withval, itcl_search=`cd ${BUILD_DIR}/../../itcl; pwd`) > > ITCL_LIB_DIR="" >-for dir in $exec_prefix/lib $TCL_LIB_DIR $itcl_search ; do >+for dir in $itcl_search $TCL_LIB_DIR $exec_prefix/lib ; do > if test -r $dir/itclConfig.sh; then > ITCL_LIB_DIR=$dir > break > fi > done >@@ -107,11 +107,11 @@ fi > > AC_ARG_WITH(itk, [ --with-itk=DIR use Itk 3.0 binaries from DIR], > itcl_search=$withval, itcl_search=`cd ${BUILD_DIR}/../../itk; pwd`) > > ITK_LIB_DIR="" >-for dir in $exec_prefix/lib $TCL_LIB_DIR $itcl_search ; do >+for dir in $itcl_search $TCL_LIB_DIR $exec_prefix/lib ; do > if test -r $dir/itkConfig.sh; then > ITK_LIB_DIR=$dir > break > fi > done Syd Polk spolk@redhat.com Engineering Manager +1 415 777 9810 x 241 Red Hat, Inc. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) 2000-06-14 17:52 ` Michael Snyder @ 2000-06-15 20:05 ` Elena Zannoni 2000-06-19 16:41 ` James Wilson 1 sibling, 0 replies; 7+ messages in thread From: Elena Zannoni @ 2000-06-15 20:05 UTC (permalink / raw) To: Michael Snyder; +Cc: Elena Zannoni, Jim Wilson, gdb-patches Michael Snyder writes: > Elena Zannoni wrote: > > > > Jim Wilson writes: > > > > Jim, any chance you could turn the tests into a gdb testfile? > > Elena, > > I thought I would take a stab at it. Seemed like it might > belong in exprs.exp. I noticed that exprs.exp seems kind of > unfinished -- it sets up as if to do some enum tests, but > doesn't actually do them! So I added some, including some > for long enums. See below. You approve? If they pass, yes :-) > > Unfortunately I don't have Jim's compiler patch, so I can't > test my tests. Jim, can you test them for me? > Anybody tried? Elena > 2000-06-14 Michael Snyder <msnyder@seadog.cygnus.com> > > * gdb.base/exprs.exp: Add tests for enum expressions. > * gdb.base/exprs.c: Ditto. > Index: exprs.c > =================================================================== > RCS file: /cvs/src/src/gdb/testsuite/gdb.base/exprs.c,v > retrieving revision 1.1.1.2 > diff -p -r1.1.1.2 exprs.c > *** exprs.c 1999/06/28 16:03:11 1.1.1.2 > --- exprs.c 2000/06/15 00:52:29 > *************** union tu_link { > *** 183,189 **** > --- 183,202 ---- > > enum colors {red, green, blue} color; > enum cars {chevy, ford, porsche} clunker; > + enum neg_colors {cyan = -3, magenta = -2, yellow = -1, black = 0} pigment; > > + enum long_colors { > + mauve = 0x1000000000000000L, > + puce = 0x1000000000000001L, > + teal = 0x1000000000000002L > + } shade; > + > + enum neg_long_colors { > + orange = -3L, > + purple = -2L, > + brown = -1L, > + white = 0L > + } hue; > > void dummy() > { > *************** void dummy() > *** 246,251 **** > --- 259,267 ---- > > color = red; > clunker = porsche; > + pigment = magenta; > + shade = puce; > + hue = purple; > > u_link.next = s_link; > > Index: exprs.exp > =================================================================== > RCS file: /cvs/src/src/gdb/testsuite/gdb.base/exprs.exp,v > retrieving revision 1.1.1.2 > diff -p -r1.1.1.2 exprs.exp > *** exprs.exp 1999/06/28 16:03:12 1.1.1.2 > --- exprs.exp 2000/06/15 00:52:29 > *************** proc test_expr { args } { > *** 60,65 **** > --- 60,66 ---- > } > set last_ent [expr [llength $args] - 1]; > set testname [lindex $args $last_ent]; > + # FIXME: this test does NOT detect failure of the assignment (setup). > if [gdb_test [lindex $args 0] "" "$testname (setup)"] { > gdb_suppress_tests; > } > *************** test_expr "set variable v_unsigned_long= > *** 215,217 **** > --- 216,386 ---- > test_expr "set variable v_unsigned_long=~0" "print v_unsigned_long != 0" "\\$\[0-9\]* = $true" "print v_unsigned_long != (unsigned long)~0" "\\$\[0-9\]* = $false" "print unsigned long != (~0)" > test_expr "set variable v_unsigned_long=~0" "print v_unsigned_long < 0" "\\$\[0-9\]* = $false" "print v_unsigned_long < 0x7FFF" "\\$\[0-9\]* = $false" "print unsigned long < (~0)" > test_expr "set variable v_unsigned_long=~0" "print v_unsigned_long > 0" "\\$\[0-9\]* = $true" "print v_unsigned_long > 0x7FFF" "\\$\[0-9\]* = $true" "print unsigned long > (~0)" > + # > + # test expressions with "enum color" types > + # > + test_expr "set variable color=green" \ > + "print color == red" "\\$\[0-9\]* = $false" \ > + "print color == green" "\\$\[0-9\]* = $true" \ > + "print color == blue" "\\$\[0-9\]* = $false" \ > + "print color == enum" > + test_expr "set variable color=1" \ > + "print color == 0" "\\$\[0-9\]* = $false" \ > + "print color == 1" "\\$\[0-9\]* = $true" \ > + "print color == 2" "\\$\[0-9\]* = $false" \ > + "print color == int" > + test_expr "set variable color=green" \ > + "print color != red" "\\$\[0-9\]* = $true" \ > + "print color != green" "\\$\[0-9\]* = $false" \ > + "print color != blue" "\\$\[0-9\]* = $true" \ > + "print color != enum" > + test_expr "set variable color=1" \ > + "print color != 0" "\\$\[0-9\]* = $true" \ > + "print color != 1" "\\$\[0-9\]* = $false" \ > + "print color != 2" "\\$\[0-9\]* = $true" \ > + "print color != int" > + test_expr "set variable color=green" \ > + "print color > red" "\\$\[0-9\]* = $true" \ > + "print color > green" "\\$\[0-9\]* = $false" \ > + "print color > blue" "\\$\[0-9\]* = $false" \ > + "print color > enum" > + test_expr "set variable color=1" \ > + "print color > 0" "\\$\[0-9\]* = $true" \ > + "print color > 1" "\\$\[0-9\]* = $false" \ > + "print color > 2" "\\$\[0-9\]* = $false" \ > + "print color > int" > + test_expr "set variable color=green" \ > + "print color < red" "\\$\[0-9\]* = $false" \ > + "print color < green" "\\$\[0-9\]* = $false" \ > + "print color < blue" "\\$\[0-9\]* = $true" \ > + "print color < enum" > + test_expr "set variable color=1" \ > + "print color < 0" "\\$\[0-9\]* = $false" \ > + "print color < 1" "\\$\[0-9\]* = $false" \ > + "print color < 2" "\\$\[0-9\]* = $true" \ > + "print color < int" > + # make enum a minus > + test_expr "set variable pigment=magenta" \ > + "print pigment == cyan" "\\$\[0-9\]* = $false" \ > + "print pigment == magenta" "\\$\[0-9\]* = $true" \ > + "print pigment == black" "\\$\[0-9\]* = $false" \ > + "print pigment == enum" > + test_expr "set variable pigment=-2" \ > + "print pigment == -3" "\\$\[0-9\]* = $false" \ > + "print pigment == -2" "\\$\[0-9\]* = $true" \ > + "print pigment == 0" "\\$\[0-9\]* = $false" \ > + "print pigment == int" > + test_expr "set variable pigment=magenta" \ > + "print pigment != cyan" "\\$\[0-9\]* = $true" \ > + "print pigment != magenta" "\\$\[0-9\]* = $false" \ > + "print pigment != black" "\\$\[0-9\]* = $true" \ > + "print pigment != enum" > + test_expr "set variable pigment=-2" \ > + "print pigment != -3" "\\$\[0-9\]* = $true" \ > + "print pigment != -2" "\\$\[0-9\]* = $false" \ > + "print pigment != 0" "\\$\[0-9\]* = $true" \ > + "print pigment != int" > + test_expr "set variable pigment=magenta" \ > + "print pigment > cyan" "\\$\[0-9\]* = $true" \ > + "print pigment > magenta" "\\$\[0-9\]* = $false" \ > + "print pigment > black" "\\$\[0-9\]* = $false" \ > + "print pigment > enum" > + test_expr "set variable pigment=-2" \ > + "print pigment > -3" "\\$\[0-9\]* = $true" \ > + "print pigment > -2" "\\$\[0-9\]* = $false" \ > + "print pigment > 0" "\\$\[0-9\]* = $false" \ > + "print pigment > int" > + test_expr "set variable pigment=magenta" \ > + "print pigment < cyan" "\\$\[0-9\]* = $false" \ > + "print pigment < magenta" "\\$\[0-9\]* = $false" \ > + "print pigment < black" "\\$\[0-9\]* = $true" \ > + "print pigment < enum" > + test_expr "set variable pigment=-2" \ > + "print pigment < -3" "\\$\[0-9\]* = $false" \ > + "print pigment < -2" "\\$\[0-9\]* = $false" \ > + "print pigment < 0" "\\$\[0-9\]* = $true" \ > + "print pigment < int" > + # > + # test expressions with "long enum" types > + # > + test_expr "set variable shade=puce" \ > + "print shade == mauve" "\\$\[0-9\]* = $false" \ > + "print shade == puce" "\\$\[0-9\]* = $true" \ > + "print shade == teal" "\\$\[0-9\]* = $false" \ > + "print shade == enum" > + test_expr "set variable shade=0x1000000000000001L" \ > + "print shade == 0x1000000000000000L" "\\$\[0-9\]* = $false" \ > + "print shade == 0x1000000000000001L" "\\$\[0-9\]* = $true" \ > + "print shade == 0x1000000000000002L" "\\$\[0-9\]* = $false" \ > + "print shade == int" > + test_expr "set variable shade=puce" \ > + "print shade != mauve" "\\$\[0-9\]* = $true" \ > + "print shade != puce" "\\$\[0-9\]* = $false" \ > + "print shade != teal" "\\$\[0-9\]* = $true" \ > + "print shade != enum" > + test_expr "set variable shade=0x1000000000000001L" \ > + "print shade != 0x1000000000000000L" "\\$\[0-9\]* = $true" \ > + "print shade != 0x1000000000000001L" "\\$\[0-9\]* = $false" \ > + "print shade != 0x1000000000000002L" "\\$\[0-9\]* = $true" \ > + "print shade != int" > + test_expr "set variable shade=puce" \ > + "print shade > mauve" "\\$\[0-9\]* = $true" \ > + "print shade > puce" "\\$\[0-9\]* = $false" \ > + "print shade > teal" "\\$\[0-9\]* = $false" \ > + "print shade > enum" > + test_expr "set variable shade=0x1000000000000001L" \ > + "print shade > 0x1000000000000000L" "\\$\[0-9\]* = $true" \ > + "print shade > 0x1000000000000001L" "\\$\[0-9\]* = $false" \ > + "print shade > 0x1000000000000002L" "\\$\[0-9\]* = $false" \ > + "print shade > int" > + test_expr "set variable shade=puce" \ > + "print shade < mauve" "\\$\[0-9\]* = $false" \ > + "print shade < puce" "\\$\[0-9\]* = $false" \ > + "print shade < teal" "\\$\[0-9\]* = $true" \ > + "print shade < enum" > + test_expr "set variable shade=0x1000000000000001L" \ > + "print shade < 0x1000000000000000L" "\\$\[0-9\]* = $false" \ > + "print shade < 0x1000000000000001L" "\\$\[0-9\]* = $false" \ > + "print shade < 0x1000000000000002L" "\\$\[0-9\]* = $true" \ > + "print shade < int" > + # make enum a minus > + test_expr "set variable hue=purple" \ > + "print hue == orange" "\\$\[0-9\]* = $false" \ > + "print hue == purple" "\\$\[0-9\]* = $true" \ > + "print hue == white" "\\$\[0-9\]* = $false" \ > + "print hue == enum" > + test_expr "set variable hue=-2L" \ > + "print hue == -3" "\\$\[0-9\]* = $false" \ > + "print hue == -2" "\\$\[0-9\]* = $true" \ > + "print hue == 0" "\\$\[0-9\]* = $false" \ > + "print hue == int" > + test_expr "set variable hue=purple" \ > + "print hue != orange" "\\$\[0-9\]* = $true" \ > + "print hue != purple" "\\$\[0-9\]* = $false" \ > + "print hue != white" "\\$\[0-9\]* = $true" \ > + "print hue != enum" > + test_expr "set variable hue=-2L" \ > + "print hue != -3L" "\\$\[0-9\]* = $true" \ > + "print hue != -2L" "\\$\[0-9\]* = $false" \ > + "print hue != 0L" "\\$\[0-9\]* = $true" \ > + "print hue != int" > + test_expr "set variable hue=purple" \ > + "print hue > orange" "\\$\[0-9\]* = $true" \ > + "print hue > purple" "\\$\[0-9\]* = $false" \ > + "print hue > white" "\\$\[0-9\]* = $false" \ > + "print hue > enum" > + test_expr "set variable hue=-2L" \ > + "print hue > -3L" "\\$\[0-9\]* = $true" \ > + "print hue > -2L" "\\$\[0-9\]* = $false" \ > + "print hue > 0L" "\\$\[0-9\]* = $false" \ > + "print hue > int" > + test_expr "set variable hue=purple" \ > + "print hue < orange" "\\$\[0-9\]* = $false" \ > + "print hue < purple" "\\$\[0-9\]* = $false" \ > + "print hue < white" "\\$\[0-9\]* = $true" \ > + "print hue < enum" > + test_expr "set variable hue=-2L" \ > + "print hue < -3L" "\\$\[0-9\]* = $false" \ > + "print hue < -2L" "\\$\[0-9\]* = $false" \ > + "print hue < 0L" "\\$\[0-9\]* = $true" \ > + "print hue < int" From kazu@hxi.com Thu Jun 15 21:32:00 2000 From: Kazu Hirata <kazu@hxi.com> To: gdb-patches@sourceware.cygnus.com Subject: [patch] sim/h8300/compile.c Date: Thu, 15 Jun 2000 21:32:00 -0000 Message-id: <9415.961129944.0@NO-ID-FOUND.mhonarc.org> X-SW-Source: 2000-06/msg00187.html Content-length: 2450 Hi, Attached is a patch for sim/h8300/compile.c. It fixes a bug that causes the following insns to be incorrectly distinguished. 0b 50 inc.w #1,r0 0b d0 inc.w #2,r0 0b 70 inc.l #1,er0 0b f0 inc.l #2,er0 0b 00 adds #1,er0 0b 80 adds #2,er0 0b 90 adds #4,er0 The register operands have nothing to do with the bug. As you can see from the above, the third nibble is very important to distinguish adds from inc.[wl]. When the opcode interpreter looks at each nibble, "looking_for" has "DBIT" in case of inc.[wl] and "KBIT" in case of adds. Here is what the first half of the patch does. When you're looking for "DBIT", you can distinguish inc.w from inc.l by looking at the lower three bits of the third nibble. Since the only possible third nibbles when looking for "DBIT" are 5 and 7, the third nibbles for adds (0, 8, and 9) get rejected. That is why I am ANDing with 7 instead of 5. Here is what the second half of the patch does. Now, when looking for "KBIT", the only possible third nibbles are 0, 8, and 9. All other values must be rejected. Thus, I have "default: goto fail;". The same story applies to dec.w, dec.l, and subs. The only difference is that the first nibble is 1 instead of 0. Just read the above replacing inc with dec and adds with subs. Thanks, Kazu Hirata ===File ~/gnu/gdb/ChangeLog-compile.c======================= 2000-06-15 Kazu Hirata <kazu@hxi.com> * compile.c (decode): Distinguish inc/dec.[wl] and adds/subs correctly. ============================================================ ===File ~/gnu/gdb/compile.patch============================= Index: compile.c =================================================================== RCS file: /cvs/src/src/sim/h8300/compile.c,v retrieving revision 1.3 diff -u -r1.3 compile.c --- compile.c 2000/06/13 20:32:01 1.3 +++ compile.c 2000/06/16 03:57:35 @@ -220,7 +220,10 @@ if (looking_for & DBIT) { - if ((looking_for & 5) != (thisnib & 5)) + /* Exclude adds/subs by looking at bit 0 and 2, and + make sure the operand size, either w or l, + matches by looking at bit 1. */ + if ((looking_for & 7) != (thisnib & 7)) goto fail; abs = (thisnib & 0x8) ? 2 : 1; @@ -293,6 +296,8 @@ case 0: abs = 1; break; + default: + goto fail; } } else if (looking_for & L_8) ============================================================ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) 2000-06-14 17:52 ` Michael Snyder 2000-06-15 20:05 ` Elena Zannoni @ 2000-06-19 16:41 ` James Wilson 1 sibling, 0 replies; 7+ messages in thread From: James Wilson @ 2000-06-19 16:41 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb-patches I updated my gdb and gcc source trees, and tried to run the gdb testsuite with your gdb.base/exprs.{c,exp} patch. Unfortunately, gdb won't work for me now. I don't know what the problem is, and it could take a while to figure out. Perhaps gdb is broken, or perhaps gcc is broken, or perhaps I need a kernel/glibc/whatever upgrade. I did run your new tests on a 32-bit machine (ia32-linux) and got lots of failures as I expected. Does the gdb testsuite have any support for host specific tests? We can't expect 64-bit tests to work on 32-bit hosts. Jim From innadadadavida@yahoo.com Mon Jun 19 16:50:00 2000 From: Bob <innadadadavida@yahoo.com> To: gdb-patches@sourceware.cygnus.com Subject: unprotected references to partial symtab (core dump fix) Date: Mon, 19 Jun 2000 16:50:00 -0000 Message-id: <20000619214200.12541.qmail@web5205.mail.yahoo.com> X-SW-Source: 2000-06/msg00231.html Content-length: 3969 This problem is reported against gdb 4.18 but remains in the 5.0 source (which I haven't yet built successfully...) Most references to "pst" in gdb/partial-stab.h are protected by "if (pst)" equivalents, but two aren't. (A third instance has been fixed in 5.0.) *** partial-stab.h-ORIG Sun Jun 28 14:36:50 1998 --- partial-stab.h Fri Jun 16 14:53:39 2000 *************** *** 592,596 **** the partial symbol table. */ if (textlow_not_set ! || (CUR_SYMBOL_VALUE < pst->textlow && CUR_SYMBOL_VALUE != ANOFFSET (section_offsets, SECT_OFF_TEXT))) --- 592,596 ---- the partial symbol table. */ if (textlow_not_set ! || (pst && CUR_SYMBOL_VALUE < pst->textlow && CUR_SYMBOL_VALUE != ANOFFSET (section_offsets, SECT_OFF_TEXT))) *************** *** 638,642 **** the partial symbol table. */ if (textlow_not_set ! || (CUR_SYMBOL_VALUE < pst->textlow && CUR_SYMBOL_VALUE != ANOFFSET (section_offsets, SECT_OFF_TEXT))) --- 638,642 ---- the partial symbol table. */ if (textlow_not_set ! || (pst && CUR_SYMBOL_VALUE < pst->textlow && CUR_SYMBOL_VALUE != ANOFFSET (section_offsets, SECT_OFF_TEXT))) GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.5.1". #0 0xa11b8 in read_dbx_symtab (section_offsets=0x2c5868, objfile=0x264750, text_addr=223256, text_size=817312) at partial-stab.h:593 #1 0x9f488 in dbx_symfile_read (objfile=0x264750, section_offsets=0x2c5868, mainline=0) at dbxread.c:583 #2 0xa33c8 in elfstab_build_psymtabs (objfile=0x264750, section_offsets=0x2c5868, mainline=0, staboffset=3378038, stabsize=2509536, stabstroffset=2460208, stabstrsize=3378037) at dbxread.c:2630 #3 0xa6cec in elf_symfile_read (objfile=0x264750, section_offsets=0x2c5868, mainline=0) at elfread.c:664 #4 0x62100 in syms_from_objfile (objfile=0x264750, addr=4013948928, mainline=0, verbo=0) at symfile.c:598 #5 0x62330 in symbol_file_add ( name=0x280b34 "", from_tty=0, addr=4014172184, mainline=0, mapped=0, readnow=0, user_loaded=0, is_solib=1) at symfile.c:743 #6 0x78f5c in symbol_add_stub (arg=0x280b10) at solib.c:1040 #7 0xd6b84 in catch_errors (func=0x78e88 <symbol_add_stub>, args=0x280b10, errstring=0x151198 "Error while reading shared library symbols:\n", mask=3) at top.c:558 #8 0x791d0 in solib_add ( arg_string=0x280b34 "", from_tty=0, target=0x78c00) at solib.c:1176 #9 0x69bf4 in wait_for_inferior () at infrun.c:2082 #10 0x68d94 in proceed (addr=0, siggnal=TARGET_SIGNAL_0, step=0) at infrun.c:922 #11 0x7da68 in procfs_create_inferior (exec_file=0x1b7638 "", allargs=0x1dee08 "", env=0x1bed68) at procfs.c:5522 #12 0x8a3d4 in sol_thread_create_inferior (exec_file=0x1b7638 "", allargs=0x1dee08 "", env=0x1bed68) at sol-thread.c:831 #13 0x8cd54 in find_default_create_inferior ( exec_file=0x1b7638 "", allargs=0x1dee08 "", env=0x1bed68) at target.c:1080 #14 0x66ef8 in run_command (args=0x1b5cda "", from_tty=1) at infcmd.c:259 #15 0xd7914 in execute_command (p=0x1b5cff "b", from_tty=1) at top.c:1268 #16 0xd7b00 in command_loop () at top.c:1365 #17 0xdf40c in main (argc=3, argv=0xeffff714) at main.c:635 __________________________________________________ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/ From wilson@wilson.cygnus.com Mon Jun 19 18:06:00 2000 From: James Wilson <wilson@wilson.cygnus.com> To: Jim Blandy <jimb@cygnus.com> Cc: gdb-patches@sourceware.cygnus.com, wilson@cygnus.com Subject: Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) Date: Mon, 19 Jun 2000 18:06:00 -0000 Message-id: <200006200106.SAA22809@wilson.cygnus.com> References: <npk8frhmkp.fsf@zwingli.cygnus.com> X-SW-Source: 2000-06/msg00232.html Content-length: 14760 In dwarf2read.c:read_array_type, I see two ifs that appear to handle DW_FORM_udata, DW_FORM_data1, DW_FORM_data2, and DW_FORM_data4, but not DW_FORM_data8, apparently assuming that DW_UNSND can't handle the latter. With your change, this is no longer true on platforms with 64-bit longs. I can trigger this problem with the following testcase. char array[0x100000001]; main() { } If I compile this with gcc -g, load it into gdb, and say "ptype array", I get a complaint about an ignored array bound, and gdb says the array has length two. Making this work requires changing some internal types to use long, and hence the result ends up changing a lot of files not just dwarf2read.c. With the following patch, gdb reports the correct array size. Unfortunately, I can't use "ptype array", I had to use "info variables". "ptype array" tries to read the variable value, which requires allocating 4GB+1 bytes of memory, which I don't have, so I get an internal out-of-memory error. This has not been tested against the gdb testsuite. I am currently unable to run the gdb testsuite. I need gdb to work, so I will be investigating this problem, though I expect it will take some time. 2000-06-19 James E. Wilson <wilson@cygnus.com> * c-typeprint.c (c_type_print_varspec_suffix): Use %ld for TYPE_LENGTH. * ch-valprint.c (chill_val_print): Likewise. * f-typeprint.c (print_equivalent_f77_float_type, f_type_print_base): Likewise. * gdbtypes.c (recursive_dump_type): Likewise. * symmisc.c (print_symbol): Likewise. * tracepoint.c (scope_info): Likewise. * c-typeprint.c (c_type_print_base): Use %ld for TYPE_FIELD_BITPOS. * ch-typeprint.c (chill_type_print_base, chill_type_print_base): Likewise. * gdbtypes.c (recursive_dump_type): Likewise. * dwarf2read.c (read_array_type): Change type of low and high to long. Accept DW_FORM_data8 attributes. * gdbtypes.c (create_range_type): Change type of low_bound and high_bound to long. * gdbtypes.h (struct type): Change type of length and bitpos fields to long. (create_range_type): Change prototype to use long. Index: c-typeprint.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/c-typeprint.c,v retrieving revision 2.42 diff -p -r2.42 c-typeprint.c *** c-typeprint.c 2000/02/04 19:48:52 2.42 --- c-typeprint.c 2000/06/20 00:50:45 *************** c_type_print_varspec_suffix (type, strea *** 591,597 **** fprintf_filtered (stream, "["); if (TYPE_LENGTH (type) >= 0 && TYPE_LENGTH (TYPE_TARGET_TYPE (type)) > 0 && TYPE_ARRAY_UPPER_BOUND_TYPE (type) != BOUND_CANNOT_BE_DETERMINED) ! fprintf_filtered (stream, "%d", (TYPE_LENGTH (type) / TYPE_LENGTH (TYPE_TARGET_TYPE (type)))); fprintf_filtered (stream, "]"); --- 591,597 ---- fprintf_filtered (stream, "["); if (TYPE_LENGTH (type) >= 0 && TYPE_LENGTH (TYPE_TARGET_TYPE (type)) > 0 && TYPE_ARRAY_UPPER_BOUND_TYPE (type) != BOUND_CANNOT_BE_DETERMINED) ! fprintf_filtered (stream, "%ld", (TYPE_LENGTH (type) / TYPE_LENGTH (TYPE_TARGET_TYPE (type)))); fprintf_filtered (stream, "]"); *************** c_type_print_base (type, stream, show, l *** 1146,1152 **** fputs_filtered (TYPE_FIELD_NAME (type, i), stream); if (lastval != TYPE_FIELD_BITPOS (type, i)) { ! fprintf_filtered (stream, " = %d", TYPE_FIELD_BITPOS (type, i)); lastval = TYPE_FIELD_BITPOS (type, i); } lastval++; --- 1146,1152 ---- fputs_filtered (TYPE_FIELD_NAME (type, i), stream); if (lastval != TYPE_FIELD_BITPOS (type, i)) { ! fprintf_filtered (stream, " = %ld", TYPE_FIELD_BITPOS (type, i)); lastval = TYPE_FIELD_BITPOS (type, i); } lastval++; Index: ch-typeprint.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/ch-typeprint.c,v retrieving revision 2.24 diff -p -r2.24 ch-typeprint.c *** ch-typeprint.c 2000/02/01 03:09:00 2.24 --- ch-typeprint.c 2000/06/20 00:50:45 *************** chill_type_print_base (type, stream, sho *** 146,152 **** break; case TYPE_CODE_BITSTRING: ! fprintf_filtered (stream, "BOOLS (%d)", TYPE_FIELD_BITPOS (TYPE_FIELD_TYPE (type, 0), 1) + 1); break; --- 146,152 ---- break; case TYPE_CODE_BITSTRING: ! fprintf_filtered (stream, "BOOLS (%ld)", TYPE_FIELD_BITPOS (TYPE_FIELD_TYPE (type, 0), 1) + 1); break; *************** chill_type_print_base (type, stream, sho *** 311,317 **** fputs_filtered (TYPE_FIELD_NAME (type, i), stream); if (lastval != TYPE_FIELD_BITPOS (type, i)) { ! fprintf_filtered (stream, " = %d", TYPE_FIELD_BITPOS (type, i)); lastval = TYPE_FIELD_BITPOS (type, i); } lastval++; --- 311,317 ---- fputs_filtered (TYPE_FIELD_NAME (type, i), stream); if (lastval != TYPE_FIELD_BITPOS (type, i)) { ! fprintf_filtered (stream, " = %ld", TYPE_FIELD_BITPOS (type, i)); lastval = TYPE_FIELD_BITPOS (type, i); } lastval++; Index: ch-valprint.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/ch-valprint.c,v retrieving revision 2.42 diff -p -r2.42 ch-valprint.c *** ch-valprint.c 2000/02/01 03:09:00 2.42 --- ch-valprint.c 2000/06/20 00:50:45 *************** chill_val_print (type, valaddr, embedded *** 427,433 **** if (length > TYPE_LENGTH (type) - 2) { fprintf_filtered (stream, ! "<dynamic length %ld > static length %d> *invalid*", length, TYPE_LENGTH (type)); /* Don't print the string; doing so might produce a --- 427,433 ---- if (length > TYPE_LENGTH (type) - 2) { fprintf_filtered (stream, ! "<dynamic length %ld > static length %ld> *invalid*", length, TYPE_LENGTH (type)); /* Don't print the string; doing so might produce a Index: dwarf2read.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/dwarf2read.c,v retrieving revision 2.46 diff -p -r2.46 dwarf2read.c *** dwarf2read.c 2000/06/19 22:19:53 2.46 --- dwarf2read.c 2000/06/20 00:50:45 *************** read_array_type (die, objfile) *** 2415,2421 **** { if (child_die->tag == DW_TAG_subrange_type) { ! unsigned int low, high; /* Default bounds to an array with unspecified length. */ low = 0; --- 2415,2421 ---- { if (child_die->tag == DW_TAG_subrange_type) { ! unsigned long int low, high; /* Default bounds to an array with unspecified length. */ low = 0; *************** read_array_type (die, objfile) *** 2437,2443 **** else if (attr->form == DW_FORM_udata || attr->form == DW_FORM_data1 || attr->form == DW_FORM_data2 ! || attr->form == DW_FORM_data4) { low = DW_UNSND (attr); } --- 2437,2444 ---- else if (attr->form == DW_FORM_udata || attr->form == DW_FORM_data1 || attr->form == DW_FORM_data2 ! || attr->form == DW_FORM_data4 ! || attr->form == DW_FORM_data8) { low = DW_UNSND (attr); } *************** read_array_type (die, objfile) *** 2463,2469 **** else if (attr->form == DW_FORM_udata || attr->form == DW_FORM_data1 || attr->form == DW_FORM_data2 ! || attr->form == DW_FORM_data4) { high = DW_UNSND (attr); } --- 2464,2471 ---- else if (attr->form == DW_FORM_udata || attr->form == DW_FORM_data1 || attr->form == DW_FORM_data2 ! || attr->form == DW_FORM_data4 ! || attr->form == DW_FORM_data8) { high = DW_UNSND (attr); } Index: f-typeprint.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/f-typeprint.c,v retrieving revision 2.14 diff -p -r2.14 f-typeprint.c *** f-typeprint.c 2000/02/01 03:09:00 2.14 --- f-typeprint.c 2000/06/20 00:50:45 *************** print_equivalent_f77_float_type (type, s *** 320,326 **** appropriate real. XLC stupidly outputs -12 as a type for real when it really should be outputting -18 */ ! fprintf_filtered (stream, "real*%d", TYPE_LENGTH (type)); } /* Print the name of the type (or the ultimate pointer target, --- 320,326 ---- appropriate real. XLC stupidly outputs -12 as a type for real when it really should be outputting -18 */ ! fprintf_filtered (stream, "real*%ld", TYPE_LENGTH (type)); } /* Print the name of the type (or the ultimate pointer target, *************** f_type_print_base (type, stream, show, l *** 420,426 **** break; case TYPE_CODE_COMPLEX: ! fprintf_filtered (stream, "complex*%d", TYPE_LENGTH (type)); break; case TYPE_CODE_FLT: --- 420,426 ---- break; case TYPE_CODE_COMPLEX: ! fprintf_filtered (stream, "complex*%ld", TYPE_LENGTH (type)); break; case TYPE_CODE_FLT: Index: gdbtypes.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/gdbtypes.c,v retrieving revision 2.109 diff -p -r2.109 gdbtypes.c *** gdbtypes.c 2000/05/28 01:25:29 2.109 --- gdbtypes.c 2000/06/20 00:50:45 *************** struct type * *** 450,457 **** create_range_type (result_type, index_type, low_bound, high_bound) struct type *result_type; struct type *index_type; ! int low_bound; ! int high_bound; { if (result_type == NULL) { --- 450,457 ---- create_range_type (result_type, index_type, low_bound, high_bound) struct type *result_type; struct type *index_type; ! long low_bound; ! long high_bound; { if (result_type == NULL) { *************** recursive_dump_type (type, spaces) *** 2798,2804 **** break; } puts_filtered ("\n"); ! printfi_filtered (spaces, "length %d\n", TYPE_LENGTH (type)); printfi_filtered (spaces, "objfile "); gdb_print_host_address (TYPE_OBJFILE (type), gdb_stdout); printf_filtered ("\n"); --- 2798,2804 ---- break; } puts_filtered ("\n"); ! printfi_filtered (spaces, "length %ld\n", TYPE_LENGTH (type)); printfi_filtered (spaces, "objfile "); gdb_print_host_address (TYPE_OBJFILE (type), gdb_stdout); printf_filtered ("\n"); *************** recursive_dump_type (type, spaces) *** 2831,2837 **** for (idx = 0; idx < TYPE_NFIELDS (type); idx++) { printfi_filtered (spaces + 2, ! "[%d] bitpos %d bitsize %d type ", idx, TYPE_FIELD_BITPOS (type, idx), TYPE_FIELD_BITSIZE (type, idx)); gdb_print_host_address (TYPE_FIELD_TYPE (type, idx), gdb_stdout); --- 2831,2837 ---- for (idx = 0; idx < TYPE_NFIELDS (type); idx++) { printfi_filtered (spaces + 2, ! "[%d] bitpos %ld bitsize %d type ", idx, TYPE_FIELD_BITPOS (type, idx), TYPE_FIELD_BITSIZE (type, idx)); gdb_print_host_address (TYPE_FIELD_TYPE (type, idx), gdb_stdout); Index: gdbtypes.h =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/gdbtypes.h,v retrieving revision 2.83 diff -p -r2.83 gdbtypes.h *** gdbtypes.h 2000/05/28 01:25:29 2.83 --- gdbtypes.h 2000/06/20 00:50:45 *************** struct type *** 241,247 **** TARGET_CHAR_BIT)--the other choice would be to make it consistently in units of HOST_CHAR_BIT. */ ! unsigned length; /* FIXME, these should probably be restricted to a Fortran-specific field in some fashion. */ --- 241,247 ---- TARGET_CHAR_BIT)--the other choice would be to make it consistently in units of HOST_CHAR_BIT. */ ! unsigned long length; /* FIXME, these should probably be restricted to a Fortran-specific field in some fashion. */ *************** struct type *** 333,339 **** of this argument. For a range bound or enum value, this is the value itself. */ ! int bitpos; /* For a static field, if TYPE_FIELD_STATIC_HAS_ADDR then physaddr is the location (in the target) of the static field. --- 333,339 ---- of this argument. For a range bound or enum value, this is the value itself. */ ! long bitpos; /* For a static field, if TYPE_FIELD_STATIC_HAS_ADDR then physaddr is the location (in the target) of the static field. *************** extern struct type *make_function_type ( *** 983,990 **** extern struct type *lookup_function_type (struct type *); ! extern struct type *create_range_type (struct type *, struct type *, int, ! int); extern struct type *create_array_type (struct type *, struct type *, struct type *); --- 983,990 ---- extern struct type *lookup_function_type (struct type *); ! extern struct type *create_range_type (struct type *, struct type *, long, ! long); extern struct type *create_array_type (struct type *, struct type *, struct type *); Index: symmisc.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/symmisc.c,v retrieving revision 1.87 diff -p -r1.87 symmisc.c *** symmisc.c 2000/05/28 01:25:35 1.87 --- symmisc.c 2000/06/20 00:50:45 *************** print_symbol (args) *** 623,629 **** { unsigned i; struct type *type = check_typedef (SYMBOL_TYPE (symbol)); ! fprintf_filtered (outfile, "const %u hex bytes:", TYPE_LENGTH (type)); for (i = 0; i < TYPE_LENGTH (type); i++) fprintf_filtered (outfile, " %02x", --- 623,629 ---- { unsigned i; struct type *type = check_typedef (SYMBOL_TYPE (symbol)); ! fprintf_filtered (outfile, "const %lu hex bytes:", TYPE_LENGTH (type)); for (i = 0; i < TYPE_LENGTH (type); i++) fprintf_filtered (outfile, " %02x", Index: tracepoint.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/tracepoint.c,v retrieving revision 2.58 diff -p -r2.58 tracepoint.c *** tracepoint.c 2000/06/04 00:35:17 2.58 --- tracepoint.c 2000/06/20 00:50:45 *************** scope_info (args, from_tty) *** 2519,2525 **** continue; } if (SYMBOL_TYPE (sym)) ! printf_filtered (", length %d.\n", TYPE_LENGTH (check_typedef (SYMBOL_TYPE (sym)))); } if (BLOCK_FUNCTION (block)) --- 2519,2525 ---- continue; } if (SYMBOL_TYPE (sym)) ! printf_filtered (", length %ld.\n", TYPE_LENGTH (check_typedef (SYMBOL_TYPE (sym)))); } if (BLOCK_FUNCTION (block)) From ac131313@cygnus.com Mon Jun 19 18:18:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Alan Modra <alan@linuxcare.com.au> Cc: BINUTILS Patches <binutils@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com> Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 18:18:00 -0000 Message-id: <394EC637.24300B87@cygnus.com> References: <Pine.LNX.4.21.0006200100160.12273-100000@front.linuxcare.com.au> X-SW-Source: 2000-06/msg00233.html Content-length: 12020 Alan Modra wrote: > > On Mon, 19 Jun 2000, Andrew Cagney wrote: > > > The attatched patch changes the MIPS ELF32 backend so that it is more > > likely to return a sign-extended offset. At present the ELF backend > > returns sign-extended symbol table values but not sign extended debug > > information. > > Hi Andrew, > Would it be better to just change ecoff_swap_sym_in? It seems like > this would achieve what you want, and not risk breaking quite so much. > I'm worried about what happens if things like PDR.adr get changed from > 0xa0000000 to 0xffffffffa0000000. Thats why I'm asking :-) Remember though, on the MIPS platform, if ``PDR.adr'' is an address then, the canonical form of the value ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. GDB and BFD have, for too many years, been bribed and cajoled into perpetuated the lie that MIPS doesn't sign extend addresses. GDB's now decided to come clean on this matter (and purge an amazing amount of bogus code :-). Any way I've attached a revised patch. I wasn't ruthless enough the first time.... With this revision the linker appears to work :-) Testing is continuing. I guess the question for BFD people is, is this the correct approach to fixing this bug? Andrew Mon Jun 19 20:53:14 2000 Andrew Cagney <cagney@b1.cygnus.com> * ecoffswap.h (ecoff_get_off, ecoff_put_off): Add ECOFF_SIGNED_32 and ECOF_SIGNED_64 to list ways to extract an offset. * elf64-mips.c (ECOFF_SIGNED_64): Define instead of ECOFF_64. * elf32-mips.c (ECOFF_SIGNED_32): Define instead of ECOFF_32. Index: ecoffswap.h =================================================================== RCS file: /cvs/cvsfiles/devo/bfd/ecoffswap.h,v retrieving revision 1.19 diff -p -r1.19 ecoffswap.h *** ecoffswap.h 1996/03/12 22:41:13 1.19 --- ecoffswap.h 2000/06/20 01:02:48 *************** Foundation, Inc., 59 Temple Place - Suit *** 27,36 **** on them in gdb by naming the including source file; e.g., 'coff-mips.c':ecoff_swap_hdr_in. ! Before including this header file, one of ECOFF_32 or ECOFF_64 must ! be defined. These are checked when swapping information that ! depends upon the target size. This code works for 32 bit and 64 ! bit ECOFF, but may need to be generalized in the future. Some header file which defines the external forms of these structures must also be included before including this header file. --- 27,37 ---- on them in gdb by naming the including source file; e.g., 'coff-mips.c':ecoff_swap_hdr_in. ! Before including this header file, one of ECOFF_32, ECOFF_64, ! ECOF_SIGNED_32 or ECOFF_SIGNED_64 must be defined. These are ! checked when swapping information that depends upon the target ! size. This code works for 32 bit and 64 bit ECOFF, but may need to ! be generalized in the future. Some header file which defines the external forms of these structures must also be included before including this header file. *************** Foundation, Inc., 59 Temple Place - Suit *** 50,55 **** --- 51,64 ---- #define ecoff_get_off bfd_h_get_64 #define ecoff_put_off bfd_h_put_64 #endif + #ifdef ECOFF_SIGNED_32 + #define ecoff_get_off bfd_h_get_signed_32 + #define ecoff_put_off bfd_h_put_signed_32 + #endif + #ifdef ECOFF_SIGNED_64 + #define ecoff_get_off bfd_h_get_signed_64 + #define ecoff_put_off bfd_h_put_signed_64 + #endif /* ECOFF auxiliary information swapping routines. These are the same for all ECOFF targets, so they are defined in ecofflink.c. */ *************** ecoff_swap_fdr_in (abfd, ext_copy, inter *** 185,191 **** intern->adr = ecoff_get_off (abfd, (bfd_byte *)ext->f_adr); intern->rss = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_rss); ! #ifdef ECOFF_64 if (intern->rss == 0xffffffff) intern->rss = -1; #endif --- 194,200 ---- intern->adr = ecoff_get_off (abfd, (bfd_byte *)ext->f_adr); intern->rss = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_rss); ! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64) if (intern->rss == 0xffffffff) intern->rss = -1; #endif *************** ecoff_swap_fdr_in (abfd, ext_copy, inter *** 197,207 **** intern->cline = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_cline); intern->ioptBase = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_ioptBase); intern->copt = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_copt); ! #ifdef ECOFF_32 intern->ipdFirst = bfd_h_get_16 (abfd, (bfd_byte *)ext->f_ipdFirst); intern->cpd = bfd_h_get_16 (abfd, (bfd_byte *)ext->f_cpd); #endif ! #ifdef ECOFF_64 intern->ipdFirst = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_ipdFirst); intern->cpd = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_cpd); #endif --- 206,216 ---- intern->cline = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_cline); intern->ioptBase = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_ioptBase); intern->copt = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_copt); ! #if defined (ECOFF_32) || defined (ECOFF_SIGNED_32) intern->ipdFirst = bfd_h_get_16 (abfd, (bfd_byte *)ext->f_ipdFirst); intern->cpd = bfd_h_get_16 (abfd, (bfd_byte *)ext->f_cpd); #endif ! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64) intern->ipdFirst = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_ipdFirst); intern->cpd = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_cpd); #endif *************** ecoff_swap_fdr_out (abfd, intern_copy, e *** 262,272 **** bfd_h_put_32 (abfd, intern->cline, (bfd_byte *)ext->f_cline); bfd_h_put_32 (abfd, intern->ioptBase, (bfd_byte *)ext->f_ioptBase); bfd_h_put_32 (abfd, intern->copt, (bfd_byte *)ext->f_copt); ! #ifdef ECOFF_32 bfd_h_put_16 (abfd, intern->ipdFirst, (bfd_byte *)ext->f_ipdFirst); bfd_h_put_16 (abfd, intern->cpd, (bfd_byte *)ext->f_cpd); #endif ! #ifdef ECOFF_64 bfd_h_put_32 (abfd, intern->ipdFirst, (bfd_byte *)ext->f_ipdFirst); bfd_h_put_32 (abfd, intern->cpd, (bfd_byte *)ext->f_cpd); #endif --- 271,281 ---- bfd_h_put_32 (abfd, intern->cline, (bfd_byte *)ext->f_cline); bfd_h_put_32 (abfd, intern->ioptBase, (bfd_byte *)ext->f_ioptBase); bfd_h_put_32 (abfd, intern->copt, (bfd_byte *)ext->f_copt); ! #if defined (ECOFF_32) || defined (ECOFF_SIGNED_32) bfd_h_put_16 (abfd, intern->ipdFirst, (bfd_byte *)ext->f_ipdFirst); bfd_h_put_16 (abfd, intern->cpd, (bfd_byte *)ext->f_cpd); #endif ! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64) bfd_h_put_32 (abfd, intern->ipdFirst, (bfd_byte *)ext->f_ipdFirst); bfd_h_put_32 (abfd, intern->cpd, (bfd_byte *)ext->f_cpd); #endif *************** ecoff_swap_pdr_in (abfd, ext_copy, inter *** 341,347 **** intern->lnHigh = bfd_h_get_32 (abfd, (bfd_byte *)ext->p_lnHigh); intern->cbLineOffset = ecoff_get_off (abfd, (bfd_byte *)ext->p_cbLineOffset); ! #ifdef ECOFF_64 intern->gp_prologue = bfd_h_get_8 (abfd, (bfd_byte *) ext->p_gp_prologue); if (bfd_header_big_endian (abfd)) { --- 350,356 ---- intern->lnHigh = bfd_h_get_32 (abfd, (bfd_byte *)ext->p_lnHigh); intern->cbLineOffset = ecoff_get_off (abfd, (bfd_byte *)ext->p_cbLineOffset); ! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64) intern->gp_prologue = bfd_h_get_8 (abfd, (bfd_byte *) ext->p_gp_prologue); if (bfd_header_big_endian (abfd)) { *************** ecoff_swap_pdr_out (abfd, intern_copy, e *** 400,406 **** bfd_h_put_32 (abfd, intern->lnHigh, (bfd_byte *)ext->p_lnHigh); ecoff_put_off (abfd, intern->cbLineOffset, (bfd_byte *)ext->p_cbLineOffset); ! #ifdef ECOFF_64 bfd_h_put_8 (abfd, intern->gp_prologue, (bfd_byte *) ext->p_gp_prologue); if (bfd_header_big_endian (abfd)) { --- 409,415 ---- bfd_h_put_32 (abfd, intern->lnHigh, (bfd_byte *)ext->p_lnHigh); ecoff_put_off (abfd, intern->cbLineOffset, (bfd_byte *)ext->p_cbLineOffset); ! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64) bfd_h_put_8 (abfd, intern->gp_prologue, (bfd_byte *) ext->p_gp_prologue); if (bfd_header_big_endian (abfd)) { *************** ecoff_swap_ext_in (abfd, ext_copy, inter *** 629,638 **** } intern->reserved = 0; ! #ifdef ECOFF_32 intern->ifd = bfd_h_get_signed_16 (abfd, (bfd_byte *)ext->es_ifd); #endif ! #ifdef ECOFF_64 intern->ifd = bfd_h_get_signed_32 (abfd, (bfd_byte *)ext->es_ifd); #endif --- 638,647 ---- } intern->reserved = 0; ! #if defined (ECOFF_32) || defined (ECOFF_SIGNED_32) intern->ifd = bfd_h_get_signed_16 (abfd, (bfd_byte *)ext->es_ifd); #endif ! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64) intern->ifd = bfd_h_get_signed_32 (abfd, (bfd_byte *)ext->es_ifd); #endif *************** ecoff_swap_ext_out (abfd, intern_copy, e *** 663,669 **** | (intern->cobol_main ? EXT_BITS1_COBOL_MAIN_BIG : 0) | (intern->weakext ? EXT_BITS1_WEAKEXT_BIG : 0)); ext->es_bits2[0] = 0; ! #ifdef ECOFF_64 ext->es_bits2[1] = 0; ext->es_bits2[2] = 0; #endif --- 672,678 ---- | (intern->cobol_main ? EXT_BITS1_COBOL_MAIN_BIG : 0) | (intern->weakext ? EXT_BITS1_WEAKEXT_BIG : 0)); ext->es_bits2[0] = 0; ! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64) ext->es_bits2[1] = 0; ext->es_bits2[2] = 0; #endif *************** ecoff_swap_ext_out (abfd, intern_copy, e *** 672,687 **** | (intern->cobol_main ? EXT_BITS1_COBOL_MAIN_LITTLE : 0) | (intern->weakext ? EXT_BITS1_WEAKEXT_LITTLE : 0)); ext->es_bits2[0] = 0; ! #ifdef ECOFF_64 ext->es_bits2[1] = 0; ext->es_bits2[2] = 0; #endif } ! #ifdef ECOFF_32 bfd_h_put_signed_16 (abfd, intern->ifd, (bfd_byte *)ext->es_ifd); #endif ! #ifdef ECOFF_64 bfd_h_put_signed_32 (abfd, intern->ifd, (bfd_byte *)ext->es_ifd); #endif --- 681,696 ---- | (intern->cobol_main ? EXT_BITS1_COBOL_MAIN_LITTLE : 0) | (intern->weakext ? EXT_BITS1_WEAKEXT_LITTLE : 0)); ext->es_bits2[0] = 0; ! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64) ext->es_bits2[1] = 0; ext->es_bits2[2] = 0; #endif } ! #if defined (ECOFF_32) || defined (ECOFF_SIGNED_32) bfd_h_put_signed_16 (abfd, intern->ifd, (bfd_byte *)ext->es_ifd); #endif ! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64) bfd_h_put_signed_32 (abfd, intern->ifd, (bfd_byte *)ext->es_ifd); #endif Index: elf32-mips.c =================================================================== RCS file: /cvs/cvsfiles/devo/bfd/elf32-mips.c,v retrieving revision 1.176 diff -p -r1.176 elf32-mips.c *** elf32-mips.c 2000/05/29 16:45:57 1.176 --- elf32-mips.c 2000/06/20 01:03:07 *************** Foundation, Inc., 59 Temple Place - Suit *** 40,46 **** #include "coff/internal.h" #include "coff/ecoff.h" #include "coff/mips.h" ! #define ECOFF_32 #include "ecoffswap.h" /* This structure is used to hold .got information when linking. It --- 40,46 ---- #include "coff/internal.h" #include "coff/ecoff.h" #include "coff/mips.h" ! #define ECOFF_SIGNED_32 #include "ecoffswap.h" /* This structure is used to hold .got information when linking. It Index: elf64-mips.c =================================================================== RCS file: /cvs/cvsfiles/devo/bfd/elf64-mips.c,v retrieving revision 1.18 diff -p -r1.18 elf64-mips.c *** elf64-mips.c 1999/12/10 10:49:53 1.18 --- elf64-mips.c 2000/06/20 01:03:09 *************** Foundation, Inc., 59 Temple Place - Suit *** 45,51 **** #include "coff/ecoff.h" /* The 64 bit versions of the mdebug data structures are in alpha.h. */ #include "coff/alpha.h" ! #define ECOFF_64 #include "ecoffswap.h" static void mips_elf64_swap_reloc_in --- 45,51 ---- #include "coff/ecoff.h" /* The 64 bit versions of the mdebug data structures are in alpha.h. */ #include "coff/alpha.h" ! #define ECOFF_SIGNED_64 #include "ecoffswap.h" static void mips_elf64_swap_reloc_in From ac131313@cygnus.com Mon Jun 19 18:29:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: GDB Patches <gdb-patches@sourceware.cygnus.com> Subject: [Fwd: [rfc] For mips, sign-extended ecoff offsets] Date: Mon, 19 Jun 2000 18:29:00 -0000 Message-id: <394EC8C8.C90112BF@cygnus.com> X-SW-Source: 2000-06/msg00234.html Content-length: 1250 Something for the symtab maintainers - perhaphs an internal sanity check is possible? Somewhere in gdb is code that merges the various pieces of symbolic information. In the case below I was seeing: o gdb read in a symbol with a sign extended value (asymbol) o gdb read in the same symbol but not sign extended (ecoff_swap_sym_in) o something o gdb ``maint print msymtab'' with the bad value. If anyone knows where that ``something'' which is doing a merge is, could I suggest a sanity check to ensure that the merged symbols actually have the same address. enjoy, Andrew PS: I'm still not sure where that ``something'' is :-) > Hello, > > The attatched patch changes the MIPS ELF32 backend so that it is more > likely to return a sign-extended offset. At present the ELF backend > returns sign-extended symbol table values but not sign extended debug > information. > > For instance, an asymbol might contain 0xfffffffa0100124 yet the value > returned by ecoff_swap_sym_in() is 0xa0100124. > > Preliminary tests with GDB suggest this improves things significantly. > Next question is, what damage is this likely to do to BFD and the > linker. > > Andrew > > PS: This will hurt GDB more than it can hurt BFD :-) From ulfc@calypso.engr.sgi.com Mon Jun 19 18:47:00 2000 From: Ulf Carlsson <ulfc@calypso.engr.sgi.com> To: Andrew Cagney <ac131313@cygnus.com> Cc: Alan Modra <alan@linuxcare.com.au>, BINUTILS Patches <binutils@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com> Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 18:47:00 -0000 Message-id: <14670.52424.697477.308492@calypso.engr.sgi.com> References: <Pine.LNX.4.21.0006200100160.12273-100000@front.linuxcare.com.au> <394EC637.24300B87@cygnus.com> X-SW-Source: 2000-06/msg00235.html Content-length: 1305 Hi Andrew, > > > The attatched patch changes the MIPS ELF32 backend so that it is more > > > likely to return a sign-extended offset. At present the ELF backend > > > returns sign-extended symbol table values but not sign extended debug > > > information. > > > > Hi Andrew, > > Would it be better to just change ecoff_swap_sym_in? It seems like > > this would achieve what you want, and not risk breaking quite so much. > > I'm worried about what happens if things like PDR.adr get changed from > > 0xa0000000 to 0xffffffffa0000000. > > Thats why I'm asking :-) Remember though, on the MIPS platform, if > ``PDR.adr'' is an address then, the canonical form of the value > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. > GDB and BFD have, for too many years, been bribed and cajoled into > perpetuated the lie that MIPS doesn't sign extend addresses. GDB's now > decided to come clean on this matter (and purge an amazing amount of > bogus code :-). 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! Ulf From alan@linuxcare.com.au Mon Jun 19 18:50:00 2000 From: Alan Modra <alan@linuxcare.com.au> To: Andrew Cagney <ac131313@cygnus.com> Cc: BINUTILS Patches <binutils@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com> Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 18:50:00 -0000 Message-id: <Pine.LNX.4.21.0006201128050.12273-100000@front.linuxcare.com.au> References: <394EC637.24300B87@cygnus.com> X-SW-Source: 2000-06/msg00236.html Content-length: 1270 On Tue, 20 Jun 2000, Andrew Cagney wrote: > > I'm worried about what happens if things like PDR.adr get changed from > > 0xa0000000 to 0xffffffffa0000000. > > Thats why I'm asking :-) Remember though, on the MIPS platform, if > ``PDR.adr'' is an address then, the canonical form of the value > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. > GDB and BFD have, for too many years, been bribed and cajoled into > perpetuated the lie that MIPS doesn't sign extend addresses. GDB's now > decided to come clean on this matter (and purge an amazing amount of > bogus code :-). Well, it's the likelihood of other "bogus code" existing in binutils that assumes addresses are _not_ sign extended that worries me. If you work to the "You break it, you fix it" rule, then you may be taking on quite a bit of work :-) > Any way I've attached a revised patch. I wasn't ruthless enough the > first time.... With this revision the linker appears to work :-) > Testing is continuing. There's an ECOF_ typo still in a comment. > I guess the question for BFD people is, is this the correct approach to > fixing this bug? I'd like to hear Ian's comments on this before you check it in. Regards, Alan Modra -- Linuxcare. Support for the Revolution. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) [not found] <200006090053.RAA14301@ada.cygnus.com.cygnus.com> [not found] ` <14664.971.753679.67153@kwikemart.cygnus.com> @ 2001-09-05 0:16 ` Michael Snyder [not found] ` <npk8frhmkp.fsf@zwingli.cygnus.com> 2 siblings, 0 replies; 7+ messages in thread From: Michael Snyder @ 2001-09-05 0:16 UTC (permalink / raw) To: gdb-patches; +Cc: jimb, ezannoni Hi Jim, Jim Blandy, our Dwarf maintainer, is occupied right now. I think your change looks good -- I only worry that we have no guarantee that even a long will be 64-bits. I suppose a long is more likely to be correct than an int... Elena, this is your call. Michael Jim Wilson wrote: > > This fixes two bugs in the handling of 64-bit values on 64-bit LP64 hosts. > We need to use long instead of int in several places, so that we don't > accidentally truncate values to 32-bits when longs are 64-bits. > > The specific problems fixed are unsigned 64-bit enum values, and signed 64-bit > enum values. > > This testcase is extracted from emacs. > > enum gdb_lisp_params > { > gdb_data_seg_bits = 0x8000000000000000UL, > }; > > main() > { > printf ("0x%lx\n", gdb_data_seg_bits); > } > > Without this patch, "print (long) gdb_data_seg_bits" gives 0. > > #include <limits.h> > > enum foo > { > bar = LONG_MIN > }; > > main() > { > printf ("0x%lx\n", bar); > } > > Without this patch, "print (long) bar" gives 0. > > In order for these testcases to work, you also need the gcc patches I checked > in today, as gcc also got it wrong until today. > > This was tested on ia64-linux with make check in the gdb directory. > > 2000-06-08 James E. Wilson <wilson@bletchleypark.cygnus.com> > > * dwarf2read.c (struct attribute): Change unsnd and snd field types > to long. > (read_8_bytes): Change return type to long. > (read_unsigned_leb128): Change return type to long. Change type of > local result to long. Cast argument of left shift to long. > (read_signed_leb128): Likewise. > > *** orig-devo/gdb/dwarf2read.c Fri Jun 2 14:22:37 2000 > --- devo/gdb/dwarf2read.c Thu Jun 8 15:37:41 2000 > *************** struct attribute > *** 227,234 **** > { > char *str; > struct dwarf_block *blk; > ! unsigned int unsnd; > ! int snd; > CORE_ADDR addr; > } > u; > --- 227,234 ---- > { > char *str; > struct dwarf_block *blk; > ! unsigned long unsnd; > ! long int snd; > CORE_ADDR addr; > } > u; > *************** static unsigned int read_2_bytes (bfd *, > *** 591,597 **** > > static unsigned int read_4_bytes (bfd *, char *); > > ! static unsigned int read_8_bytes (bfd *, char *); > > static CORE_ADDR read_address (bfd *, char *); > > --- 591,597 ---- > > static unsigned int read_4_bytes (bfd *, char *); > > ! static unsigned long read_8_bytes (bfd *, char *); > > static CORE_ADDR read_address (bfd *, char *); > > *************** static char *read_n_bytes (bfd *, char * > *** 599,607 **** > > static char *read_string (bfd *, char *, unsigned int *); > > ! static unsigned int read_unsigned_leb128 (bfd *, char *, unsigned int *); > > ! static int read_signed_leb128 (bfd *, char *, unsigned int *); > > static void set_cu_language (unsigned int); > > --- 599,607 ---- > > static char *read_string (bfd *, char *, unsigned int *); > > ! static unsigned long read_unsigned_leb128 (bfd *, char *, unsigned int *); > > ! static long read_signed_leb128 (bfd *, char *, unsigned int *); > > static void set_cu_language (unsigned int); > > *************** read_4_signed_bytes (abfd, buf) > *** 3446,3452 **** > return bfd_get_signed_32 (abfd, (bfd_byte *) buf); > } > > ! static unsigned int > read_8_bytes (abfd, buf) > bfd *abfd; > char *buf; > --- 3446,3452 ---- > return bfd_get_signed_32 (abfd, (bfd_byte *) buf); > } > > ! static unsigned long > read_8_bytes (abfd, buf) > bfd *abfd; > char *buf; > *************** read_string (abfd, buf, bytes_read_ptr) > *** 3543,3555 **** > #endif > } > > ! static unsigned int > read_unsigned_leb128 (abfd, buf, bytes_read_ptr) > bfd *abfd; > char *buf; > unsigned int *bytes_read_ptr; > { > ! unsigned int result, num_read; > int i, shift; > unsigned char byte; > > --- 3543,3556 ---- > #endif > } > > ! static unsigned long > read_unsigned_leb128 (abfd, buf, bytes_read_ptr) > bfd *abfd; > char *buf; > unsigned int *bytes_read_ptr; > { > ! unsigned long result; > ! unsigned int num_read; > int i, shift; > unsigned char byte; > > *************** read_unsigned_leb128 (abfd, buf, bytes_r > *** 3562,3568 **** > byte = bfd_get_8 (abfd, (bfd_byte *) buf); > buf++; > num_read++; > ! result |= ((byte & 127) << shift); > if ((byte & 128) == 0) > { > break; > --- 3563,3569 ---- > byte = bfd_get_8 (abfd, (bfd_byte *) buf); > buf++; > num_read++; > ! result |= ((unsigned long)(byte & 127) << shift); > if ((byte & 128) == 0) > { > break; > *************** read_unsigned_leb128 (abfd, buf, bytes_r > *** 3573,3585 **** > return result; > } > > ! static int > read_signed_leb128 (abfd, buf, bytes_read_ptr) > bfd *abfd; > char *buf; > unsigned int *bytes_read_ptr; > { > ! int result; > int i, shift, size, num_read; > unsigned char byte; > > --- 3574,3586 ---- > return result; > } > > ! static long > read_signed_leb128 (abfd, buf, bytes_read_ptr) > bfd *abfd; > char *buf; > unsigned int *bytes_read_ptr; > { > ! long result; > int i, shift, size, num_read; > unsigned char byte; > > *************** read_signed_leb128 (abfd, buf, bytes_rea > *** 3593,3599 **** > byte = bfd_get_8 (abfd, (bfd_byte *) buf); > buf++; > num_read++; > ! result |= ((byte & 127) << shift); > shift += 7; > if ((byte & 128) == 0) > { > --- 3594,3600 ---- > byte = bfd_get_8 (abfd, (bfd_byte *) buf); > buf++; > num_read++; > ! result |= ((long)(byte & 127) << shift); > shift += 7; > if ((byte & 128) == 0) > { ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <npk8frhmkp.fsf@zwingli.cygnus.com>]
* Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) [not found] ` <npk8frhmkp.fsf@zwingli.cygnus.com> @ 2001-09-05 0:16 ` Michael Snyder 0 siblings, 0 replies; 7+ messages in thread From: Michael Snyder @ 2001-09-05 0:16 UTC (permalink / raw) To: gdb-patches; +Cc: jimb Jim Blandy wrote: > > One question about this patch: > > In dwarf2read.c:read_array_type, I see two ifs that appear to handle > DW_FORM_udata, DW_FORM_data1, DW_FORM_data2, and DW_FORM_data4, but > not DW_FORM_data8, apparently assuming that DW_UNSND can't handle the > latter. With your change, this is no longer true on platforms with > 64-bit longs. > > Could you try expanding those `ifs' to recognize DW_FORM_data8 too, > and see if there are any adverse effects? It would seem to be a > natural extension. Jim (Blandy), one of the two or three changes that you've just made in dwarf2read.c has broken shared libs on Solaris. Please try running shlib-call.exp Thanks, Michael ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <200006200106.SAA22809@wilson.cygnus.com>]
* Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) [not found] <200006200106.SAA22809@wilson.cygnus.com> @ 2000-06-19 19:03 ` Andrew Cagney 0 siblings, 0 replies; 7+ messages in thread From: Andrew Cagney @ 2000-06-19 19:03 UTC (permalink / raw) To: Jim Blandy, elena; +Cc: James Wilson, gdb-patches [to/cc re-aranged] James Wilson wrote: > 2000-06-19 James E. Wilson <wilson@cygnus.com> > * gdbtypes.h (struct type): Change type of length and bitpos fields to > long. Um, again, shouldn't this be LONGEST? Andrew From wilson@wilson.cygnus.com Mon Jun 19 19:13:00 2000 From: James Wilson <wilson@wilson.cygnus.com> To: Andrew Cagney <ac131313@cygnus.com> Cc: Jim Blandy <jimb@cygnus.com>, elena@cygnus.com, James Wilson <wilson@cygnus.com>, gdb-patches@sourceware.cygnus.com Subject: Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) Date: Mon, 19 Jun 2000 19:13:00 -0000 Message-id: <200006200213.TAA22932@wilson.cygnus.com> References: <394ED0B7.EFE765A8@cygnus.com> X-SW-Source: 2000-06/msg00239.html Content-length: 429 Um, again, shouldn't this be LONGEST? What is LONGEST, what are the rules for its use, and what are the implications of trying to use it? I am aware that my patches aren't going to work for cross debuggers from 32-bit hosts to 64-bit targets, but right now I'm not worried about that. I need to get the native 64-bit debugger working correctly, and I don't have time at the moment to worry about the cross debugger case. Jim From ac131313@cygnus.com Mon Jun 19 19:16:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Ulf Carlsson <ulfc@calypso.engr.sgi.com> Cc: Alan Modra <alan@linuxcare.com.au>, BINUTILS Patches <binutils@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com> Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 19:16:00 -0000 Message-id: <394ED3B3.E5A18E2C@cygnus.com> References: <Pine.LNX.4.21.0006200100160.12273-100000@front.linuxcare.com.au> <394EC637.24300B87@cygnus.com> <14670.52424.697477.308492@calypso.engr.sgi.com> X-SW-Source: 2000-06/msg00240.html Content-length: 1654 Ulf Carlsson wrote: > > Hi Andrew, > > > > > The attatched patch changes the MIPS ELF32 backend so that it is more > > > > likely to return a sign-extended offset. At present the ELF backend > > > > returns sign-extended symbol table values but not sign extended debug > > > > information. > > > > > > Hi Andrew, > > > Would it be better to just change ecoff_swap_sym_in? It seems like > > > this would achieve what you want, and not risk breaking quite so much. > > > I'm worried about what happens if things like PDR.adr get changed from > > > 0xa0000000 to 0xffffffffa0000000. > > > > Thats why I'm asking :-) Remember though, on the MIPS platform, if > > ``PDR.adr'' is an address then, the canonical form of the value > > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. > > GDB and BFD have, for too many years, been bribed and cajoled into > > perpetuated the lie that MIPS doesn't sign extend addresses. GDB's now > > decided to come clean on this matter (and purge an amazing amount of > > bogus code :-). > > 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! FYI, it certainly makes a mess of the symbol table lookup code. At one end of GDB the MIPS processor (with those 64 bit registers being used in the n32 ABI say) is providing sign extended register values while at the other end BFD is giving GDB, er, inconsistent values. Andrew From ac131313@cygnus.com Mon Jun 19 19:23:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Alan Modra <alan@linuxcare.com.au> Cc: BINUTILS Patches <binutils@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com> Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 19:23:00 -0000 Message-id: <394ED588.3945491@cygnus.com> References: <Pine.LNX.4.21.0006201128050.12273-100000@front.linuxcare.com.au> X-SW-Source: 2000-06/msg00241.html Content-length: 1701 Alan Modra wrote: > > On Tue, 20 Jun 2000, Andrew Cagney wrote: > > > > I'm worried about what happens if things like PDR.adr get changed from > > > 0xa0000000 to 0xffffffffa0000000. > > > > Thats why I'm asking :-) Remember though, on the MIPS platform, if > > ``PDR.adr'' is an address then, the canonical form of the value > > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. > > GDB and BFD have, for too many years, been bribed and cajoled into > > perpetuated the lie that MIPS doesn't sign extend addresses. GDB's now > > decided to come clean on this matter (and purge an amazing amount of > > bogus code :-). > > Well, it's the likelihood of other "bogus code" existing in binutils that > assumes addresses are _not_ sign extended that worries me. If you work to > the "You break it, you fix it" rule, then you may be taking on quite a bit > of work :-) I can help to an extent, however, to be honest, I'm having enough fun just re-stablizing the the GDB side of the MIPS. Consequently I'd be focusing on GDB specific problems. People on the BFD/MIPS side will need to be willing to help if there is fallout. > > Any way I've attached a revised patch. I wasn't ruthless enough the > > first time.... With this revision the linker appears to work :-) > > Testing is continuing. > > There's an ECOF_ typo still in a comment. Thanks. > > I guess the question for BFD people is, is this the correct approach to > > fixing this bug? > > I'd like to hear Ian's comments on this before you check it in. Ian has a long memory (Nick does to :-) and both would be very familar with the underlying problems and the very long history that is behind this :-) Andrew From jimb@zwingli.cygnus.com Mon Jun 19 19:37:00 2000 From: Jim Blandy <jimb@zwingli.cygnus.com> To: Michael Snyder <msnyder@cygnus.com> Cc: gdb-patches@sourceware.cygnus.com Subject: Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) Date: Mon, 19 Jun 2000 19:37:00 -0000 Message-id: <npk8flf57z.fsf@zwingli.cygnus.com> References: <200006090053.RAA14301@ada.cygnus.com.cygnus.com> <npk8frhmkp.fsf@zwingli.cygnus.com> <3949479C.22B3@cygnus.com> X-SW-Source: 2000-06/msg00242.html Content-length: 1973 > Jim (Blandy), one of the two or three changes that you've just made > in dwarf2read.c has broken shared libs on Solaris. > > Please try running shlib-call.exp Looks okay to me: cd ~/cygnus/sun4u/sourceware/gdb/main/native/build/ make check-gdb RUNTESTFLAGS=shlib-call.exp Making a new config file... Nothing to be done for all... rootme=`pwd`; export rootme; \ srcdir=/home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/testsuite ; export srcdir ; \ EXPECT=`if [ -f ${rootme}/../../expect/expect ] ; then echo ${rootme}/../../expect/expect ; else echo expect ; fi` ; export EXPECT ; \ LD_LIBRARY_PATH=$rootme/../../expect:$rootme/../../libstdc++:$rootme/../../tk/unix:$rootme/../../tcl/unix:$rootme/../../bfd:$rootme/../../opcodes:$LD_LIBRARY_PATH; \ export LD_LIBRARY_PATH; \ if [ -f ${rootme}/../../expect/expect ] ; then \ TCL_LIBRARY=${srcdir}/../../tcl/library ; \ export TCL_LIBRARY ; fi ; \ runtest shlib-call.exp Test Run By jimb on Mon Jun 19 21:35:19 2000 Native configuration is sparc-sun-solaris2.5.1 === gdb tests === Using /home/jimb/testing/boards/standard.exp as standard board description file for build. Using /home/jimb/testing/boards/standard.exp as standard board description file for host. Schedule of variations: unix Running target unix Using /home/jimb/testing/boards/standard.exp as standard board description file for target. Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/testsuite/config/unix.exp as tool-and-target-specific interface file. Running /home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/testsuite/gdb.base/shlib-call.exp ... === gdb Summary === # of expected passes 19 /stone/jimb/cygnus/sun4u/sourceware/gdb/main/native/build/gdb/testsuite/../../gdb/gdb version 5.0 -nx Compilation finished at Mon Jun 19 21:35:28 From geoffk@cygnus.com Mon Jun 19 20:08:00 2000 From: Geoff Keating <geoffk@cygnus.com> To: ulfc@calypso.engr.sgi.com Cc: ac131313@cygnus.com, alan@linuxcare.com.au, binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 20:08:00 -0000 Message-id: <200006200307.UAA10516@localhost.cygnus.com> References: <Pine.LNX.4.21.0006200100160.12273-100000@front.linuxcare.com.au> <394EC637.24300B87@cygnus.com> <14670.52424.697477.308492@calypso.engr.sgi.com> X-SW-Source: 2000-06/msg00243.html Content-length: 653 > From: Ulf Carlsson <ulfc@calypso.engr.sgi.com> > Date: Mon, 19 Jun 2000 18:45:44 -0700 (PDT) > 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). -- - Geoffrey Keating <geoffk@cygnus.com> From ian@zembu.com Mon Jun 19 20:39:00 2000 From: Ian Lance Taylor <ian@zembu.com> To: alan@linuxcare.com.au Cc: ac131313@cygnus.com, binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 20:39:00 -0000 Message-id: <20000620033908.18201.qmail@daffy.airs.com> References: <Pine.LNX.4.21.0006201128050.12273-100000@front.linuxcare.com.au> X-SW-Source: 2000-06/msg00244.html Content-length: 1140 Date: Tue, 20 Jun 2000 11:50:26 +1000 (EST) From: Alan Modra <alan@linuxcare.com.au> > > I'm worried about what happens if things like PDR.adr get changed from > > 0xa0000000 to 0xffffffffa0000000. > > Thats why I'm asking :-) Remember though, on the MIPS platform, if > ``PDR.adr'' is an address then, the canonical form of the value > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. > GDB and BFD have, for too many years, been bribed and cajoled into > perpetuated the lie that MIPS doesn't sign extend addresses. GDB's now > decided to come clean on this matter (and purge an amazing amount of > bogus code :-). > I guess the question for BFD people is, is this the correct approach to > fixing this bug? I'd like to hear Ian's comments on this before you check it in. This is all due to a long-ago decision to ship support for a 64-bit MIPS chip using a 32-bit MIPS target. I think that sign extending pdr.ADR is probably right, since that is how 32 bit addresses are treated by the relocation routines. But the real fix is to use a 64-bit MIPS target. Ian From ian@zembu.com Mon Jun 19 20:41:00 2000 From: Ian Lance Taylor <ian@zembu.com> To: geoffk@cygnus.com Cc: ulfc@calypso.engr.sgi.com, ac131313@cygnus.com, alan@linuxcare.com.au, binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 20:41:00 -0000 Message-id: <20000620034102.18244.qmail@daffy.airs.com> References: <Pine.LNX.4.21.0006200100160.12273-100000@front.linuxcare.com.au> <394EC637.24300B87@cygnus.com> <14670.52424.697477.308492@calypso.engr.sgi.com> <200006200307.UAA10516@localhost.cygnus.com> X-SW-Source: 2000-06/msg00245.html Content-length: 973 Date: Mon, 19 Jun 2000 20:07:59 -0700 From: Geoff Keating <geoffk@cygnus.com> > From: Ulf Carlsson <ulfc@calypso.engr.sgi.com> > Date: Mon, 19 Jun 2000 18:45:44 -0700 (PDT) > 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. Ian From kevinb@cygnus.com Tue Jun 20 00:14:00 2000 From: Kevin Buettner <kevinb@cygnus.com> To: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFC] PARAMS elimination: tui/tuiIO.c Date: Tue, 20 Jun 2000 00:14:00 -0000 Message-id: <1000620071434.ZM523@ocotillo.lan> References: <1000616022019.ZM17748@ocotillo.lan> <kevinb@cygnus.com> X-SW-Source: 2000-06/msg00246.html Content-length: 229 On Jun 15, 7:20pm, Kevin Buettner wrote: > More PARAMS elminiation... I'll wait two days for comments / objections > before committing the changes below. > > * tui/tuiIO.c: Eliminate use of PARAMS from this file. Committed. From kevinb@cygnus.com Tue Jun 20 00:23:00 2000 From: Kevin Buettner <kevinb@cygnus.com> To: gdb-patches@sourceware.cygnus.com Subject: [PATCH RFC] PARAMS elimination: tui/tuiSourceWin.h Date: Tue, 20 Jun 2000 00:23:00 -0000 Message-id: <1000620072300.ZM544@ocotillo.lan> X-SW-Source: 2000-06/msg00247.html Content-length: 1131 More PARAMS elimination... I'll wait for two days for comments / objections before committing the changes below. (The only file left after this one is copying.awk.) * tuiSourceWin.h: Eliminate use of PARAMS from this file. Index: tui/tuiSourceWin.h =================================================================== RCS file: /cvs/src/src/gdb/tui/tuiSourceWin.h,v retrieving revision 1.2 diff -u -r1.2 tuiSourceWin.h --- tuiSourceWin.h 2000/05/28 01:12:42 1.2 +++ tuiSourceWin.h 2000/06/20 07:18:29 @@ -6,10 +6,10 @@ extern void tuiDisplayMainFunction (void); -extern void tuiUpdateSourceWindow PARAMS - ((TuiWinInfoPtr, struct symtab *, Opaque, int)); -extern void tuiUpdateSourceWindowAsIs PARAMS - ((TuiWinInfoPtr, struct symtab *, Opaque, int)); +extern void tuiUpdateSourceWindow (TuiWinInfoPtr, struct symtab *, Opaque, + int); +extern void tuiUpdateSourceWindowAsIs (TuiWinInfoPtr, struct symtab *, Opaque, + int); extern void tuiUpdateSourceWindowsWithAddr (Opaque); extern void tui_vUpdateSourceWindowsWithAddr (va_list); extern void tuiUpdateSourceWindowsWithLine (struct symtab *, int); ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2001-09-05 0:16 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <200006200213.TAA22932@wilson.cygnus.com>
[not found] ` <395013E2.D78A2EE2@cygnus.com>
2000-06-20 20:39 ` gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) Michael Snyder
[not found] <200006090053.RAA14301@ada.cygnus.com.cygnus.com>
[not found] ` <14664.971.753679.67153@kwikemart.cygnus.com>
2000-06-14 17:52 ` Michael Snyder
2000-06-15 20:05 ` Elena Zannoni
2000-06-19 16:41 ` James Wilson
2001-09-05 0:16 ` Michael Snyder
[not found] ` <npk8frhmkp.fsf@zwingli.cygnus.com>
2001-09-05 0:16 ` Michael Snyder
[not found] <200006200106.SAA22809@wilson.cygnus.com>
2000-06-19 19:03 ` Andrew Cagney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox