Re: Why does mips define elf_backend_sign_extend_vma to true?

Re: Why does mips define elf_backend_sign_extend_vma to true?

[H . J . Lu]

On Tue, Aug 07, 2001 at 06:45:04PM -0700, H . J . Lu wrote:
> On Tue, Aug 07, 2001 at 09:42:24PM -0400, Andrew Cagney wrote:
> > > On Tue, Aug 07, 2001 at 06:24:59PM -0700, H . J . Lu wrote:
> > > 
> > >> Only elf32-mips.c has
> > >> 
> > >> #define elf_backend_sign_extend_vma        true
> > >> 
> > >> and we get
> > >> 
> > >> # nm vmlinux
> > >> ffffffff802e01f0 D C_A_D
> > >> ffffffff802df344 D EISA_bus
> > >> ....
> > >> 
> > >> Does anyone know why mips does this?
> > >> 
> > > 
> > > 
> > > It seems that it was done on purpose:
> > > 
> > > http://sources.redhat.com/ml/binutils/1999-11/msg00080.html
> > > 
> > > I don't believe it is correct for the normal 32bit MIPS SVR4 ABI. I'd like
> > > to turn it off. If you want to do sign extension, you should create a new
> > > ABI, not break the existing ABI.
> > 
> > 
> > Several ABI's have implied sign extension of addresses.  MIPS is one.
> > 
> 
> Show me where it is documemnted in the 32bit SVR4 MIPS ABI.
> 

FYI, some prorgams using bfd are broken on Linux/mips because of this: nm,
objdump and gdb. In gdb

# gdb vmlinux
...
(gdb) list printk
1874
1875    static void __exit packet_exit(void)
1876    {
1877            remove_proc_entry("net/packet", 0);
1878            unregister_netdevice_notifier(&packet_netdev_notifier);
1879            sock_unregister(PF_PACKET);
1880            return;
1881    }
1882
1883    static int __init packet_init(void)


H.J.

Re: Why does mips define elf_backend_sign_extend_vma to true?

[Daniel Jacobowitz]

On Tue, Aug 07, 2001 at 06:52:09PM -0700, H . J . Lu wrote:
> FYI, some prorgams using bfd are broken on Linux/mips because of this: nm,
> objdump and gdb. In gdb
> 
> # gdb vmlinux
> ...
> (gdb) list printk
> 1874
> 1875    static void __exit packet_exit(void)
> 1876    {
> 1877            remove_proc_entry("net/packet", 0);
> 1878            unregister_netdevice_notifier(&packet_netdev_notifier);
> 1879            sock_unregister(PF_PACKET);
> 1880            return;
> 1881    }
> 1882
> 1883    static int __init packet_init(void)

Maybe off in your tools land.  What debug format?  What patches?  What
GDB version?

I know there's something wrong with DWARF2 yet.  Stabs works perfectly
well.

I also can't see how BFD chooses to display adddresses affecting the
ABI in any way.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Why does mips define elf_backend_sign_extend_vma to true?

[David B Anderson]

Andrew Cagney wrote
|> > Several ABI's have implied sign extension of addresses.  MIPS is one.

 H . J . Lu wrote
|> Show me where it is documemnted in the 32bit SVR4 MIPS ABI.

You have to know where to look :-)
It's not in the ABI, it's in the hardware.
When running MIPSIII or MIPSIV.
The hardware, on loading a 32bit integer value into a 
64 bit integer register, sign-extends to 64 bits.
(for example, with a lw instruction: any 32bit integer
load does this extension)

gdb is simply reflecting the hardware action.

Documented in  "See MIPS Run" by Sweetman,1999, page 28 (for example).


|FYI, some programs using bfd are broken on Linux/mips because of this: nm,

Corrections welcome...
David B. Anderson davea@sgi.com danderson@acm.org 

Re: Why does mips define elf_backend_sign_extend_vma to true?

[H . J . Lu]

On Tue, Aug 07, 2001 at 08:26:20PM -0700, David B Anderson wrote:
> 
> 
> Andrew Cagney wrote
> |> > Several ABI's have implied sign extension of addresses.  MIPS is one.
> 
>  H . J . Lu wrote
> |> Show me where it is documemnted in the 32bit SVR4 MIPS ABI.
> 
> You have to know where to look :-)
> It's not in the ABI, it's in the hardware.
> When running MIPSIII or MIPSIV.
> The hardware, on loading a 32bit integer value into a 
> 64 bit integer register, sign-extends to 64 bits.
> (for example, with a lw instruction: any 32bit integer
> load does this extension)
> 
> gdb is simply reflecting the hardware action.
> 

What does that have anything to do with ELF files for MIPS I/II? We get
different values on the same 32bit mips ELF file for MIPS I/II:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x8010074c
  Start of program headers:          52 (bytes into file)
  Start of section headers:          2178004 (bytes into file)
  Flags:                             0x10000001, noreorder, mips2 UNKNOWN
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         3
  Size of section headers:           40 (bytes)
  Number of section headers:         18
  Section header string table index: 15

from 32bit bfd and 64bit bfd. I propose this patch to at least fix the
SRV4 ABI. I think the better fix is to check the EF_MIPS field to only
do sign extension for MIPS III/IV. But we don't support such encoding.
I think it is the time to reconsider

http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00418.html

I am willing to provide a patch for that.


H.J.
----
2001-08-07  H.J. Lu  <hjl@gnu.org>

	* elf32-mips.c (elf_backend_sign_extend_vma): Undefine for the
	SVR4 ABI.

Index: elf32-mips.c
===================================================================
RCS file: /work/cvs/gnu/binutils/bfd/elf32-mips.c,v
retrieving revision 1.33
diff -u -p -r1.33 elf32-mips.c
--- elf32-mips.c	2001/07/04 07:34:35	1.33
+++ elf32-mips.c	2001/08/08 04:44:51
@@ -9511,6 +9511,8 @@ static const struct ecoff_debug_swap mip
 
 #define INCLUDED_TARGET_FILE            /* More a type of flag */
 
+#undef elf_backend_sign_extend_vma
+
 #undef TARGET_LITTLE_SYM
 #undef TARGET_LITTLE_NAME
 #undef TARGET_BIG_SYM

Re: Why does mips define elf_backend_sign_extend_vma to true?

[Richard Henderson]

On Tue, Aug 07, 2001 at 10:04:51PM -0700, H . J . Lu wrote:
> I think the better fix is to check the EF_MIPS field to only
> do sign extension for MIPS III/IV. But we don't support such encoding.

There are too many odd combinations of mips chips for
something so simplistic to work.

Besides, things aren't broken.  Use a 64-bit BFD and 
you _should_ get sign-extension for MIPS.


r~

Re: Why does mips define elf_backend_sign_extend_vma to true?

[H . J . Lu]

On Tue, Aug 07, 2001 at 10:46:22PM -0700, Richard Henderson wrote:
> On Tue, Aug 07, 2001 at 10:04:51PM -0700, H . J . Lu wrote:
> > I think the better fix is to check the EF_MIPS field to only
> > do sign extension for MIPS III/IV. But we don't support such encoding.
> 
> There are too many odd combinations of mips chips for
> something so simplistic to work.
> 
> Besides, things aren't broken.  Use a 64-bit BFD and 
> you _should_ get sign-extension for MIPS.
> 

That is wrong for MIPS I/II even if BFD is 64bit for whatever reason.
In any case, I won't bother with any patches. But I will fix it in my
Linux binutils.


H.J.

Re: Why does mips define elf_backend_sign_extend_vma to true?

[Richard Henderson]

On Tue, Aug 07, 2001 at 11:21:02PM -0700, H . J . Lu wrote:
> That is wrong for MIPS I/II even if BFD is 64bit for whatever reason.

What is the basis of your assertion that it is incorrect?
Apart from you don't like the way it looks, that is.


r~

Re: Why does mips define elf_backend_sign_extend_vma to true?

[Maciej W. Rozycki]

On Tue, 7 Aug 2001, H . J . Lu wrote:

> > Besides, things aren't broken.  Use a 64-bit BFD and 
> > you _should_ get sign-extension for MIPS.
> 
> That is wrong for MIPS I/II even if BFD is 64bit for whatever reason.

 Sign-extension is fine.  I think what you really want is to truncate
addresses in the output of certain programs such as nm and objdump to 32
bits if the output BFD is elf32-*mips.  It's on my to-do list for some
time, but don't hold your breath (i.e. feel free to do it yourself ;-) ). 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Why does mips define elf_backend_sign_extend_vma to true?

[H . J . Lu]

On Wed, Aug 08, 2001 at 10:11:29AM +0200, Maciej W. Rozycki wrote:
> On Tue, 7 Aug 2001, H . J . Lu wrote:
> 
> > > Besides, things aren't broken.  Use a 64-bit BFD and 
> > > you _should_ get sign-extension for MIPS.
> > 
> > That is wrong for MIPS I/II even if BFD is 64bit for whatever reason.
> 
>  Sign-extension is fine.  I think what you really want is to truncate
> addresses in the output of certain programs such as nm and objdump to 32
> bits if the output BFD is elf32-*mips.  It's on my to-do list for some
> time, but don't hold your breath (i.e. feel free to do it yourself ;-) ). 

It is not fine at all. The change is to address the problem in

http://sources.redhat.com/ml/binutils/1999-11/msg00067.html

which said

GDB encounters situtations (c.f. assorted mips targets) where the object
file contains 32 bit addresses but the target has a 64 bit address
space.  The 32 address values being implicitly zero or sign extended to
64 bits.  GDB needs to know what the object file format assumed (or
didn't in some case) is doing so that it can correctly do things like
compares.

The key here is "the target has a 64 bit address space." It is not the same
as the gdb/nm/objdump configured with the 64bit BFD. The approach is wrong.

It seems that I am the only one who thinks it is incorrect. I will find a
simple way to get around it in my binutils/gdb.

If people agreee it is wrong, I am willing to spend time finding a soluton
acceptable for everyone.


H.J.

Re: Why does mips define elf_backend_sign_extend_vma to true?

[Andrew Cagney]

> http://sources.redhat.com/ml/binutils/1999-11/msg00067.html
> 
> which said
> 
> GDB encounters situtations (c.f. assorted mips targets) where the object
> file contains 32 bit addresses but the target has a 64 bit address
> space.  The 32 address values being implicitly zero or sign extended to
> 64 bits.  GDB needs to know what the object file format assumed (or
> didn't in some case) is doing so that it can correctly do things like
> compares.
> 
> The key here is "the target has a 64 bit address space." It is not the same
> as the gdb/nm/objdump configured with the 64bit BFD. The approach is wrong.
> 
> It seems that I am the only one who thinks it is incorrect. I will find a
> simple way to get around it in my binutils/gdb.
> 
> If people agreee it is wrong, I am willing to spend time finding a soluton
> acceptable for everyone.


There is an old saying K.I.S.S.

GDB was, not so recently changed to apply the rule that the MIPS target, 
always, no matter what, sign extens 32 bit addresses.

It had the pleasant side effect of fixing numerous bugs and flushing out 
too much bogus code.  What your proposing is a step back into the dark 
ages of MIPS programming.

	Andrew

Re: Why does mips define elf_backend_sign_extend_vma to true?

[H . J . Lu]

On Wed, Aug 08, 2001 at 10:50:41AM -0400, Andrew Cagney wrote:
> 
> There is an old saying K.I.S.S.
> 
> GDB was, not so recently changed to apply the rule that the MIPS target, 
> always, no matter what, sign extens 32 bit addresses.
> 
> It had the pleasant side effect of fixing numerous bugs and flushing out 
> too much bogus code.  What your proposing is a step back into the dark 
> ages of MIPS programming.


Please try

1. Find a decent compiler for Linux/mips.
2. Check out the Linux mips kernel from oss.sgi.com.
3. Compile the kernel with -g.
4. Compile Linux/mips gdb with 64bit BFD.
5. Do

# mipsel-linux-gdb vmlinux
...
(gdb) list printk

Then tell me why it looks ok to you. Mine looks like

(gdb) p printk
$1 = {int (char *)} 0x8011c530
(gdb) list printk
1874
1875    static void __exit packet_exit(void)
1876    {
1877            remove_proc_entry("net/packet", 0);
1878            unregister_netdevice_notifier(&packet_netdev_notifier);
1879            sock_unregister(PF_PACKET);
1880            return;
1881    }
1882
1883    static int __init packet_init(void)

The problem is the 64bit BFD does the sign extension to the section
addresses which have the bit 31 set. Gdb cannot find 0x8011c530 in
those ranges. You may say oh, let's fix gdb to do

(gdb) p printk
$1 = {int (char *)} 0xffffffff8011c530

I don't think it will be useful to me. I don't think I can set a break
pount at 0xffffffff8011c530. The sign extension here is only the
artifact of the 64bit BFD. My mips target is 32bit.


H.J.

Re: Why does mips define elf_backend_sign_extend_vma to true?

[Andrew Cagney]

> 
> 
> Please try
> 
> 1. Find a decent compiler for Linux/mips.
> 2. Check out the Linux mips kernel from oss.sgi.com.
> 3. Compile the kernel with -g.
> 4. Compile Linux/mips gdb with 64bit BFD.
> 5. Do


You might need to find a simpler test!


> The problem is the 64bit BFD does the sign extension to the section
> addresses which have the bit 31 set. Gdb cannot find 0x8011c530 in
> those ranges. You may say oh, let's fix gdb to do
> 
> (gdb) p printk
> $1 = {int (char *)} 0xffffffff8011c530
> 
> I don't think it will be useful to me. I don't think I can set a break
> pount at 0xffffffff8011c530. The sign extension here is only the
> artifact of the 64bit BFD. My mips target is 32bit.


There is a bug but the underlying problem is the oposite of what you 
claim.  Something is breaking that simple always sign-extend rule 
(forgetting to sign extend something) and, as a consequence, the symbol 
lookup is failing.

Remember people around here spent years fighting GDB and BFD MIPS 
braindamage until someone realised it was all backwards.

	Andrew

Re: Why does mips define elf_backend_sign_extend_vma to true?

[H . J . Lu]

On Wed, Aug 08, 2001 at 11:18:05AM -0400, Andrew Cagney wrote:
> 
> You might need to find a simpler test!
> 

If it is that simple, shouldn't you have caught it long time ago?

> 
> > The problem is the 64bit BFD does the sign extension to the section
> > addresses which have the bit 31 set. Gdb cannot find 0x8011c530 in
> > those ranges. You may say oh, let's fix gdb to do
> > 
> > (gdb) p printk
> > $1 = {int (char *)} 0xffffffff8011c530
> > 
> > I don't think it will be useful to me. I don't think I can set a break
> > pount at 0xffffffff8011c530. The sign extension here is only the
> > artifact of the 64bit BFD. My mips target is 32bit.
> 
> 
> There is a bug but the underlying problem is the oposite of what you 
> claim.  Something is breaking that simple always sign-extend rule 
> (forgetting to sign extend something) and, as a consequence, the symbol 
> lookup is failing.
> 

I am willing to buy it. The immediate problem is in

struct obj_section *
find_pc_sect_section (CORE_ADDR pc, struct sec *section)
{
  struct obj_section *s;
  struct objfile *objfile;

  ALL_OBJSECTIONS (objfile, s)
    if ((section == 0 || section == s->the_bfd_section) &&
        s->addr <= pc && pc < s->endaddr)
      return (s);

  return (NULL);
}

s->addr and s->endaddr came from BFD with sign extension. But `pc' is
not, which has the bit 31 set. All of them have the type of CORE_ADDR.
Any suggestions? I am not sure if it is the only problem in gdb.


H.J.

Re: Why does mips define elf_backend_sign_extend_vma to true?

[Daniel Jacobowitz]

On Wed, Aug 08, 2001 at 09:02:49AM -0700, H . J . Lu wrote:
> 
> I am willing to buy it. The immediate problem is in
> 
> struct obj_section *
> find_pc_sect_section (CORE_ADDR pc, struct sec *section)
> {
>   struct obj_section *s;
>   struct objfile *objfile;
> 
>   ALL_OBJSECTIONS (objfile, s)
>     if ((section == 0 || section == s->the_bfd_section) &&
>         s->addr <= pc && pc < s->endaddr)
>       return (s);
> 
>   return (NULL);
> }
> 
> s->addr and s->endaddr came from BFD with sign extension. But `pc' is
> not, which has the bit 31 set. All of them have the type of CORE_ADDR.
> Any suggestions? I am not sure if it is the only problem in gdb.

PC should be already be sign extended at this point... in my tests, it
is.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Why does mips define elf_backend_sign_extend_vma to true?

[H . J . Lu]

On Wed, Aug 08, 2001 at 09:54:01AM -0700, Daniel Jacobowitz wrote:
> On Wed, Aug 08, 2001 at 09:02:49AM -0700, H . J . Lu wrote:
> > 
> > I am willing to buy it. The immediate problem is in
> > 
> > struct obj_section *
> > find_pc_sect_section (CORE_ADDR pc, struct sec *section)
> > {
> >   struct obj_section *s;
> >   struct objfile *objfile;
> > 
> >   ALL_OBJSECTIONS (objfile, s)
> >     if ((section == 0 || section == s->the_bfd_section) &&
> >         s->addr <= pc && pc < s->endaddr)
> >       return (s);
> > 
> >   return (NULL);
> > }
> > 
> > s->addr and s->endaddr came from BFD with sign extension. But `pc' is
> > not, which has the bit 31 set. All of them have the type of CORE_ADDR.
> > Any suggestions? I am not sure if it is the only problem in gdb.
> 
> PC should be already be sign extended at this point... in my tests, it
> is.

The gdb I checked out from the 5.1 branch yesterday doesn't do it. BTW,
what

(gdb) print printk

# gdb yourgdb
.....
(top-gdb) print sizeof (CORE_ADDR)

say?


H.J.




H.J.

Re: Why does mips define elf_backend_sign_extend_vma to true?

[Daniel Jacobowitz]

On Wed, Aug 08, 2001 at 10:02:28AM -0700, H . J . Lu wrote:
> The gdb I checked out from the 5.1 branch yesterday doesn't do it. BTW,
> what
> 
> (gdb) print printk

Not sign extended.

> # gdb yourgdb
> .....
> (top-gdb) print sizeof (CORE_ADDR)

8 (64-bit).

That's why I was confused.  I'm going to go figure out what want64 at
configure time accomplishes that MIPS doesn't always do.  I don't have
a "64-bit-bfd" built, but CORE_ADDR is always 64-bit on MIPS.

Wait... --enable-64-bit-bfd should not have any effect on MIPS.  All it
does is force wordsize=64, as far as I can see, and wordsize=64 is
forced by the inclusion of the elf64 vectors in $selvecs for
mips*-*-linux-gnu.  Does not using it have any effect on your problem?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Why does mips define elf_backend_sign_extend_vma to true?

[H . J . Lu]

On Wed, Aug 08, 2001 at 11:01:59AM -0700, Daniel Jacobowitz wrote:
> On Wed, Aug 08, 2001 at 10:02:28AM -0700, H . J . Lu wrote:
> > The gdb I checked out from the 5.1 branch yesterday doesn't do it. BTW,
> > what
> > 
> > (gdb) print printk
> 
> Not sign extended.
> 
> > # gdb yourgdb
> > .....
> > (top-gdb) print sizeof (CORE_ADDR)
> 
> 8 (64-bit).
> 

Something must be wrong somewhere. I checked out gdb 5.1 from CVS
yesterday and did

/home/hjl/work/gnu/src/gdb-5.1/gdb/configure \
	--target=mipsel-linux \
	--prefix=/export/tools \
	--with-local-prefix=/export/tools

It doesn't work for me.


H.J.

Re: Why does mips define elf_backend_sign_extend_vma to true?

[Andrew Cagney]

> There is a bug but the underlying problem is the oposite of what you 
>> claim.  Something is breaking that simple always sign-extend rule 
>> (forgetting to sign extend something) and, as a consequence, the symbol 
>> lookup is failing.
>> 
> 
> 
> I am willing to buy it. The immediate problem is in
> 
> struct obj_section *
> find_pc_sect_section (CORE_ADDR pc, struct sec *section)
> {
>   struct obj_section *s;
>   struct objfile *objfile;


Ah, now your getting it! :-)

In the bad old days, one developer would decide that the PC was wrong, 
and a second would decide that the s->endaddr was wrong.  They would 
then fix/test their local cases and commit their changes.  Only to find 
that their target was still broken .... :-/

	Andrew

Re: Why does mips define elf_backend_sign_extend_vma to true?

[Daniel Jacobowitz]

On Wed, Aug 08, 2001 at 08:03:06AM -0700, H . J . Lu wrote:
> On Wed, Aug 08, 2001 at 10:50:41AM -0400, Andrew Cagney wrote:
> > 
> > There is an old saying K.I.S.S.
> > 
> > GDB was, not so recently changed to apply the rule that the MIPS target, 
> > always, no matter what, sign extens 32 bit addresses.
> > 
> > It had the pleasant side effect of fixing numerous bugs and flushing out 
> > too much bogus code.  What your proposing is a step back into the dark 
> > ages of MIPS programming.
> 
> 
> Please try
> 
> 1. Find a decent compiler for Linux/mips.
> 2. Check out the Linux mips kernel from oss.sgi.com.
> 3. Compile the kernel with -g.
> 4. Compile Linux/mips gdb with 64bit BFD.
> 5. Do

drow@nevyn:~% /opt/src/gdb/obj-cross/gdb/gdb
/opt/mvista/mips/linux13/vmlinux
GNU gdb 2001-07-26-cvs (MI_OUT)
Copyright 2001 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 "--host=i686-pc-linux-gnu
--target=mipsel-hardhat-linux"...
(gdb) list printk
247     asmlinkage long sys_syslog(int type, char * buf, int len)
248     {
249             if ((type != 3) && !capable(CAP_SYS_ADMIN))
250                     return -EPERM;
251             return do_syslog(type, buf, len);
252     }
253
254     asmlinkage int printk(const char *fmt, ...)
255     {
256             va_list args;

I've already asked you in this thread, what version of tools and what
debug format are you using?  Is it gcc3.0 with all your patches and
your Linux binutils?

Using more mainstream tools, the problem does not seem to exist.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Why does mips define elf_backend_sign_extend_vma to true?

[H . J . Lu]

On Wed, Aug 08, 2001 at 09:48:08AM -0700, Daniel Jacobowitz wrote:
> On Wed, Aug 08, 2001 at 08:03:06AM -0700, H . J . Lu wrote:
> > On Wed, Aug 08, 2001 at 10:50:41AM -0400, Andrew Cagney wrote:
> > > 
> > > There is an old saying K.I.S.S.
> > > 
> > > GDB was, not so recently changed to apply the rule that the MIPS target, 
> > > always, no matter what, sign extens 32 bit addresses.
> > > 
> > > It had the pleasant side effect of fixing numerous bugs and flushing out 
> > > too much bogus code.  What your proposing is a step back into the dark 
> > > ages of MIPS programming.
> > 
> > 
> > Please try
> > 
> > 1. Find a decent compiler for Linux/mips.
> > 2. Check out the Linux mips kernel from oss.sgi.com.
> > 3. Compile the kernel with -g.
> > 4. Compile Linux/mips gdb with 64bit BFD.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> 
> I've already asked you in this thread, what version of tools and what
> debug format are you using?  Is it gcc3.0 with all your patches and
> your Linux binutils?

See #4 above. One way to do it is

# ../configure --enable-64-bit-bfd --enable-targets=all ....



H.J.

Re: Why does mips define elf_backend_sign_extend_vma to true?

[Maciej W. Rozycki]

On Wed, 8 Aug 2001, H . J . Lu wrote:

> The problem is the 64bit BFD does the sign extension to the section
> addresses which have the bit 31 set. Gdb cannot find 0x8011c530 in
> those ranges. You may say oh, let's fix gdb to do
> 
> (gdb) p printk
> $1 = {int (char *)} 0xffffffff8011c530

 Yep, that would mostly be the right approach, with the additional note
that the sign-extended addresses need not be observed externally.  All the
code needs to do is to sign-extend all addresses before passing them to
the 64-bit BFD core and truncate them back to 32 bits after passing them
to a user's output.

> I don't think it will be useful to me. I don't think I can set a break
> pount at 0xffffffff8011c530. The sign extension here is only the
> artifact of the 64bit BFD. My mips target is 32bit.

 You don't need to have top 32 bits of 64-bit internal BFD representation
visible to a user. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +