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

[Michael Snyder <msnyder@specifix.com>]

On Mon, 2008-02-18 at 16:27 +0000, Maciej W. Rozycki wrote:
> On Mon, 18 Feb 2008, Nigel Stephens wrote:
> 
> > >> - 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.
> 
>  As I see it there is really no need to notice the difference of the 
> MIPS16 mode text references in DWARF records.  The architecture already 
> observes the bit #0 in text references is not a part of the address and is 
> merely a mode bit.  We have, in particular, joint text and data address 
> space and where a MIPS16 instruction is treated as data, e.g. when 
> inserting a breakpoint or with self-modifying code the corresponding data 
> address has its bit #0 clear.

Isn't this a lot like Arm/Thumb?
How's it handled there?