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

Maciej W. Rozycki
2008-02-15T11:36:41Z

On Wed, 13 Feb 2008, Jim Blandy wrote:

> It seems that we all agree on the following:
>
> - It's contrary to the DWARF spec for producers to put arch-specific
> information in the low bits of the addresses in the line number
> table, function and block address ranges, and so on. Existing
> toolchains that do this are buggy, but that's life.
>
> - The addresses in GDB's line tables and block ranges should not have
> such extra bits set in them.
>
> - The proper place to store arch-specific data on minimal symbols is
> in the 'info' field of 'struct minimal_symbol'. In cases like
> MIPS16, the gdbarch_push_dummy_call method can consult that
> information at call time to see which calling convention is
> appropriate.

I certainly agree here.

> If we agree that we want to work around the linker bugs in GDB's
> reader, that means we have to clear those bits and stash the
> information elsewhere when we read the DWARF. So something like
> Maciej's original patch doesn't seem wrong to me.

OK, but the original patch does not clear the bit, but actually it sets
it in the single case discovered so far where GAS gets it wrong (and
linker does not fix up in any way). What I attempted meanwhile was to
adjust the DWARF reader so that it effectively ignores the bit. It proved
not as straightforward as it could immediately be thought it would be as
with some structures addresses are calculated cumulatively and one or more
addends may be odd. It is therefore necessary, where applicable, not only
to mask out the LSB, but also to remember its value and carry it forward
to the next addition.

What I have developed is a crude hack as a proof of concept which just
does all the extra calculation unconditionally so that I could verify it
was at all workable as well as identify all the places that would have to
be changed and how. If there is agreement to push this approach forward I
will have a look at how to do this properly.

> The name 'make_symbol_special' seems awfully vague, though. Is the
> term 'special' inherited from outside GDB, or did it originate within
> GDB? In either case, I don't want it propagating into the DWARF
> reader; that's horrible. :)

I have just derived an arbitrary name from make_msymbol_special. No
preference either way, but I gather this is not the way we want to go
anyway.

Maciej