* 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 ` gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) 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 ` gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) 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] ` <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
* 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
* 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
* 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] <200006090053.RAA14301@ada.cygnus.com.cygnus.com>
[not found] ` <14664.971.753679.67153@kwikemart.cygnus.com>
2000-06-14 17:52 ` gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux) 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] <200006200213.TAA22932@wilson.cygnus.com>
[not found] ` <395013E2.D78A2EE2@cygnus.com>
2000-06-20 20:39 ` 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