[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: ia64
[Gcl-devel] Re: ia64
Tue, 16 Nov 2010 11:45:44 -0500
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
"Richard E. Harke" <address@hidden> writes:
> 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.
OK, as all our files are compiled after the final executable is linked,
and for which we are now implementing "ex-post" linking, they are not
in the same compilation unit, and will likely need their own global
pointer. Typically this is set to a little GOT table appended to the
end of the .o file, but we have to see what the register is actually
A good example are the elf64_alpha_reloc*.h files under h/.
What I don't see is where the code allows for a setting of this
value. On mips, for example, there are GPREL16 relocs which set gp
first, and then HI16/LO16, etc., which use its value. Here it just
seems we are using a preset gp in r1 against which we implement the
relocation to .sdata.
Having 22 bits for the GOT area is not a problem providing we can set
r1 within it somewhere. The PCREL21B though appears to limit the size
of the .o file to 21bits of code if we put a trampoline stub at the
end. This could be a problem. On some machines, e.g. hppa32 just
finished, we can change the branch instruction type to branch relative
to some other address than $pc if needed.
> 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.
OK, I noticed that gcc on ia64 does not have a -mlong-calls or similar
switch. We always make use of this when available, as it makes the
code more portable not having to write our own stub. This said, there
are a few machines which currently require a 4 instruction stub or so,
which we also place into the GOT space appended to the end of the .o
file. See the routines make_got_room_for_stub and write_stub in
> I believe that both of these relocs would be resolved in the linker
> as they do not appear in the dlopen code.
Right. But we *are* the linker here.
> 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.
Right. 3 41bit slots north of a 5 bit template, iirc. This should
not be so difficult for a few cpp macros to handle.
> 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
>> 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
>> Take care,
>> > Richard Harke
Camm Maguire address@hidden
"The earth is but one country, and mankind its citizens." -- Baha'u'llah