MIPS: Handle manual calls of MIPS16 functions with a call stub

[Maciej W. Rozycki]

On Fri, 8 Feb 2008, Jim Blandy wrote:

> On Feb 8, 2008 6:23 AM, Maciej W. Rozycki <macro@mips.com> wrote:
> >  It is much more than that, but I think it can be done with some
> > adjustments to pointer_to_address(), address_to_pointer() and
> > integer_to_address() methods.  If DWARF-2 records could be treated as
> > pointers (which they are given how the linker processes them) rather than
> > addresses then such a setup should work.  That should be done above the
> > level of the DWARF-2 interpreter, as losing the LSB from relative data
> > often contained in records would result in an accumulative error.
> 
> If you're suggesting that we run the values in DWARF data through
> pointer_to_address, I don't think that's right, either.  DWARF
> specifies that those attributes' values are byte addresses of code.

 You are right indeed -- this is what the spec says:

"address

   Represented as an object of appropriate size to hold an address on the 
   target machine (DW_FORM_addr).  The size is encoded in the compilation 
   unit header (see Section 7.5.1).  This address is relocatable in a 
   relocatable object file and is relocated inan executable file or shared 
   object."

> Putting ISA information in low bits of DWARF attribute values isn't
> the way we've decided to do things.

 Unfortunately this is what the current versions of the relevant tools do 
and I think it has been like this for a while.  The linker does not 
differentiate between relocations used for taking an address of a function 
for the purpose of making a call and for other uses and the same 
relocation types are used in both cases.

 Ultimately it is the linker that should be fixed (though from the current 
behaviour I think GAS has a problem here as well), but I am afraid broken 
tools and broken binaries are going to be out there for a while yet, so it 
may be a reasonable idea to try to handle them as well as possible.  I 
recognise pointer_to_address() may not be the best choice here though.

 However I think it will have to be involved anyway elsewhere as I find 
the current model assumed by GDB inconsistent.

  Maciej