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 Fri, 1 Feb 2008, Maciej W. Rozycki wrote:

> > elsewhere)?  Maybe mips_write_pc should use mips_pc_is_mips16; that's
> > how Thumb works, by always consulting the minimal symbol table to find
> > out whether an address should be called as MIPS16 or MIPS32.
> 
>  The ABI is different, so it is not enough to set the PC correctly -- more 
> about it in the patch that is going through my regression testing at the 
> moment.  Though perhaps the other places could use mips_pc_is_mips16() 
> too.  On the other hand I feel setting the block's start address correctly 
> is the right way to make the handling consistent throughout -- by using 
> mips_pc_is_mips16() here and there some places may be omitted by accident.  
> Hmm...

 I have tried your suggestion of using mips_pc_is_mips16() in 
mips_write_pc(), but it only removes some of the regressions.  I think 
your proposal could work if the LSB of MIPS16 addresses was explicitly 
cleared throughout processing within GDB as all the DWARF-2 records 
referring to such addresses are currently meant to have it set.  This is 
obviously because the R_MIPS_32 relocation is used for them as well as 
where an address of a function is taken for the purpose of making a call, 
so all these places are treated the same by the linker and GDB is prepared 
to it.

 Obviously the problem in the first place is in the way the stub is 
annotated with debugging information.  Moving it outside the block 
describing the associated actual function breaks backtracing and 
single-stepping quite badly if I recall correctly.  The DWARF-3 spec 
actually provides for such special code fragments by the means of the 
DW_AT_trampoline attribute, but GCC does not really have any infrastruture 
for handling it yet, except from recognising the name of the attribute.  
Until that is adopted I think we should have means to handle stubs 
regardless and even once GCC has been updated I think older binaries 
should be kept supported by reasonable means.

 Please note that for MIPS16 we have return stubs too. ;-)

  Maciej


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