From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: Richard Henderson , David B Anderson , gdb@sourceware.cygnus.com, binutils@sourceware.cygnus.com Subject: Re: Why does mips define elf_backend_sign_extend_vma to true? Date: Wed, 08 Aug 2001 07:29:00 -0000 Message-id: <20010808072922.C26704@lucon.org> References: <20010807232102.A19636@lucon.org> X-SW-Source: 2001-08/msg00066.html 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.