ia64 hardware renames registers after a subroutine call. (registers 0-31 do not get renamed) The alloc instruction specifies how many registers to protect. The first one past that number will be renamed r32 after the next call. In this case r33 is saving some status related to renaming, r34 is saving the stack pointer, r32 is saving the return address and r35 is saving the global pointer which resides in r1 The called routine will have its own global pointer. This isn't necessarily the case but is determined by the compiler depending on whether the target of the call is in the same compilation unit or not. It appears that r36 is being used to pass a parameter which will appear in the called routine as r32 The field in the addl that is being relocated is just 22 bits and he field in the call is just 21 bits. But note that the call will go to a stub that will reload the gp register before calling the "real" address. I believe that both of these relocs would be resolved in the linker as they do not appear in the dlopen code. Also modifying a field in an instruction is a very messy business on ia64. The field to be modified is never on a byte boundary and sometimes is split into discontiguous parts.
Richard On Monday 15 November 2010 10:49:38 am you wrote: > Now a question or two of my own: > > In the code: > > 0000000000000000 <init_code>: > 0: 00 08 15 08 80 05 [MII] alloc r33=ar.pfs,5,4,0 > 6: 20 02 30 00 42 00 mov r34=r12 > c: 04 00 c4 00 mov r32=b0 > 10: 02 18 01 02 00 21 [MII] mov r35=r1 > 11: GPREL22 .sdata > 16: e0 00 04 00 48 80 addl r14=0,r1;; > 1c: 04 70 00 84 mov r36=r14 > 20: 10 00 00 00 01 00 [MIB] nop.m 0x0 > 22: PCREL21B do_init > 26: 00 00 00 02 00 00 nop.i 0x0 > 2c: 08 00 00 50 br.call.sptk.many b0=20 > <init_code+0x20> > > I take it r35 is always set to (presumably) the top of the function. > Are there really only 22/21 bits of relative addressing space from > this point to both do_init and .sdata? On other machines with gp > pointers, one can set the value to a nearby location at function > beginning. > > Take care, > > > Richard Harke _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
