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

Maciej W. Rozycki
2008-02-13T18:28:39Z

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