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

[Nigel Stephens <nigel at mips dot com>]

Sorry if I repeat anything -- I've not been copied on this conversation
until now.

Maciej W. Rozycki wrote:
> 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.
>>     

Hmm. The ELF symbol table has an "out of band" mechanism to distinguish
symbols which refer to different architectural encodings, using the
architecture-specific bits in the st_info field. But how would you
represent that in  DWARF's object file encoding, noting that the
"MIPS16-ness" of an undefined symbol is not known at compile time, only
at final link time.

And this is not just a way of sneaking architecture-specific
"information" through the object file: it is a fundamental aspect of the
MIPS architecture. From the running software's point of view bit 0 of
the PC must be set to execute MIPS16 instructions (e.g. when performing
an indirect jump or function call) and it will always be viewed as set
when made visible to software (e.g. in the return address register after
a function call, or saved on the stack, or in the exception program
counter). Bit 0 must therefore be set in any data which points to a
MIPS16 instruction. Because of the way that DWARF information is
generated using assembler directives, then by the time a program is
fully linked bit 0 of a to a MIPS16 address within a DWARF section will
"by definition" be set: it would otherwise not be a valid pointer to a
MIPS16 instruction. I suppose that we could invent new relocation types
for DWARF data, or get the linker to relocate data within .dwarf*
sections differently, but that would be an intrusive change.

>> - The addresses in GDB's line tables and block ranges should not have
>>   such extra bits set in them.
>>     

Well, I suppose that you could clear bit 0, after stashing it in some
other field of the line table or block range. But you'd then have to
make sure that it continued to be passed around, along with the address
-- or else at some point you'd have to fold it back into bit0 of the
address anyway.

>> - 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.
>   

What about when there isn't an ELF symbol associated with an address?

>   
>> 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). 

Maybe fix GAS then? Maciej, can you provide example assembler code that
GAS handles incorrectly?

>  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
>   

-- 
Nigel Stephens     | MIPS Technologies (UK)      | t:(+44|0)1223 203110
Technical Director | 7200 Cambridge Research Pk  | f:(+44|0)1223 203181
.                  | Cambridge, England CB25 9TL | c:(+44|0)7976 686470