[Gcl-devel] Re: ia64

[Camm Maguire]

Greetings!  Great to hear from you -- was just arguing with myself
whether I was going to tackle this or not.

Some unrelated good news -- hppa32 is finished and testing, and will
be committed shortly.

"Richard E. Harke" <address@hidden> writes:

> Well, steps one and two were easy enough.
>
> I have been reading documentation and looking
> through existing code but i think it is time to
> ask some questions. First, maybe, some more
> background. If this is to replace the use of
> dlopen, what is the advantage?

Primarily two items:

1) dlopen consumes a file descriptor for each loaded .o file --
axiom for example has already exceeded the standard limits and cannot
build its databases using dlopen without root privelege modifications.

2) It is well nigh impossible to implement the persistence customary
in lisp developemnt -- load .o, save-system, move image wherever,
re-execute.  All .o files would have to follow the image and retain
their paths, or the entire image would need to be rebuilt with a
somewhat complicated auxiliary procedure, compiler::link, calling ld
directly and building gcl and the new code together all over again.
This is very finicky to get right, as for example, it will be unable
to replicate the effect of loading the same file twice, requires
unique filenames, requires special lisp code to be written for each
appliaction, etc.  In sum, it takes an incremental image buildup model
to a global assembly process, requiring all bits to be present when
needed. 

If dlopen could be passed an address into which the relocated code
would be dumped, and release the file-descriptor, that would be
perfect.  I've requested such support from the libc people -- not much
response yet.

In any case, ia64, thumb, and possibly ppc64 are the only machines
still unsupported.

>
> As a replacement for dlopen, I assume that only
> the relocs handled in dlopen need be dealt with.
>

Or perhaps the relocs output by gcc using the flags of the
compiler::*cc* and compiler::*opt-three* variables.


> What about lazy binding?

Given the lack of callable .plt entries on mips, we have a facility to
re-exec on startup pushing LD_BIND_NOW to the environment.  No other
machine requires this.  Relocations must be made to addresses within
the finally linked executable as opposed to within an external shared
lib as ld.so might not give the same address on subsequent execution
or on a different machine.  Most machines have a .plt trampoline which
does the lazy binding on first call.  Where direct addressing is
present, we just call the .plt for a slightly slower call.  Where got
load calls occur, we can just point to the global got and follow the
main executable of doing the plt code only once (except on mips).

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
>
>
> On Tuesday 26 October 2010 03:05:08 pm you wrote:
>> "Richard E. Harke" <address@hidden> writes:
>> > On Friday 27 August 2010 02:38:23 pm you wrote:
>> >> Greetings!  We had discussed some time ago native object relocation in
>> >> gcl on ia64, in the context of axiom support.  I've recently
>> >> implemented an overhaul of this feature, supporting custom (non-bfd)
>> >> relocation for all elf targets but ia64 and hppa.  To support ia64, I
>> >> need to write a small switch statement on the elf relocation type, and
>> >> example of which I can provide you if interested.
>> >>
>> >> Would you be available for questions in this area?
>> >>
>> >> Take care,
>> >
>> > I'm willing to do what I can to help. I haven't been working on ia64
>> > much recently so it may take some effort for me to get back up to speed.
>> > I still have an ia64 machine I could use for testing though the
>> > software hasn't been updated in a while.
>>
>> Thank you so much!  Your efforts will save a lot of time and are thus
>> greatly appreciated!
>>
>> Here in a nutshell is how to get started:
>>
>> 1) cvs -z9 -q -d:pserver:address@hidden:/sources/gcl co  -d \
>> gcl-2.6.8pre -r Version_2_6_8pre gcl
>>
>> 2) cd gcl-2.6.8pre
>>
>> 3) write small elf64_ia64_reloc.h (and possibly
>> elf64_ia64_reloc_special.h) files following the many examples in the
>> h/ subdir for the other architectures
>>
>> 4) append to ia64-linux.h:
>> #define RELOC_H "elf64_ia64_reloc.h"
>>
>> and optionally
>>
>> #define SPECIAL_RELOC_H "elf64_ia64_reloc_special.h"
>>
>> 5) ./configure --enable-debug --disable-dlopen --enable-custreloc && make
>>
>> 6) cd unixport
>>
>> 7) cat >f.l
>> (defun foo (x) x)
>> .
>>
>> 8) ./saved_gcl (or ./saved_pre_gcl
>>
>> 9) (compile-file "f.l")
>>
>> 10) (load "f")
>>
>> 11) (foo 1)
>>
>> then chase down bugs.  Once I get this file working, then I do
>>
>> 12) (defun bar (x) (flet ((g (x) x)) (g x)))
>>
>> 13) (compile 'bar)
>>
>> 14) (bar 2)
>>
>> then
>>
>> 15) (compile-file "../cmpnew/gcl_cmpeval.lsp")
>>
>> 16) (load *)
>>
>> 17) (compile nil '(lambda nil nil))
>>
>> finally
>>
>> 18) cd ../pcl && make
>>
>> If this goes mostly through (there will be some small errors as ansi
>> was not configured in above), you are most likely done!
>>
>>
>> As you can tell, most machines just need the simple reloc file with
>> switch entries for the various reloc types.  o/sfaslelf.c includes
>> these entries for the low level work.  's' holds the symbol value, 'a'
>> the addend, 'r' the reloc entry, and 'where' the instruction address.
>>
>> Some machines requiring an appended .got table take an additional
>> special reloc file.  The goal here is to allocate a got table entry to
>> each needed reloc and encode it in the relocation or symbol
>> structures.  On mips and alpha alone, tiny trampolines have t be
>> written in this space as genuine .plt entries are not (yet) provided.
>> I don't anticipate this problem on ia64.  All relocated addresses
>> should lie within the base gcl executable, and not in an external
>> shared library.  This is because the image can be moved, and said
>> address might be different on a different machine.  Make sure to
>> relocate 'sin' to the .plt entry of 'sin', etc.
>>
>> This sounds more daunting than it is.  Please let me know if anything
>> is unclear -- I'd be most happy to help.  And thank you again so much
>> for offering assistance!
>>
>> Take care,
>>
>> > Richard
>
>
>
>
>
>

-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah