This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]