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

["Jim Blandy" <jimb@red-bean.com>]

On Mon, Feb 18, 2008 at 5:32 AM, Nigel Stephens <nigel@mips.com> wrote:
>  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.

If you're going to conclude that DWARF DW_AT_low_pc and DW_AT_high_pc
attributes ought to have bit zero set when they show the extent of
MIPS16 code, I don't think that's right.  After all, if I want to
disassemble such an instruction, which address do I start reading
bytes from? I must clear bit zero.

Does DWARF information refer to undefined symbols?  Doesn't the
compiler know the mode associated with every symbol it refers to in
DWARF?  Couldn't relocs against DWARF data citing MIPS16 symbols
subtract off bit 0 in the addend?

GDB actually does have mechanisms (which Maciej mentions) for setting
and masking off bit zero when writing and reading the PC.  It seems to
me GDB could look up the linker symbol associated with an address to
find the appropriate mode.