Re: [Gcl-devel] ghci on arm

[Camm Maguire]

Greetings!  GCL does use LGPL.   I'm unaware of a BSD variant.  What is
the license of binutils?

Take care,

Karel Gardas <address@hidden> writes:

> Hello!
>
> Camm, thanks a lot for the suggestion. I've thought it would be really
> nice if we can reuse some of GCL code. Unfortunately we don't live in
> a perfect engineering world, but here we hit (probably!) the issue of
> different licenses in use. Am I right assuming GCL is using some kind
> of GPL/LGPL license? GHC on the other hand is using BSD (or BSD-like)
> so if I'm right we're not able to mix the code here.
>
> Anyway, idea of reusing some other project code looks really
> appealing. Do you know any project dealing with ARM linker and yet
> with BSD or BSD like license?
>
> Thanks a lot!
> Karel
>
>
> On 01/26/12 04:12 AM, Camm Maguire wrote:
>> Greetings!  GCL has a working native linker now on armel and armhf.  We
>> have a generic elf relocation file, with machine specific headers
>> implementing only those relocs output by gcc.  I can step you through
>> the code if interested.
>>
>> For example, here is the core file for elf32_arm, which should be almost
>> readable:
>>
>> #define R_ARM_THM_CALL        10
>> #define R_ARM_CALL 28
>> #define R_ARM_V4BX 40
>> #define R_ARM_THM_MOVW_ABS_NC 47
>> #define R_ARM_THM_MOVW_ABS    48
>>      case R_ARM_THM_CALL:
>>        s+=a;
>>        if (ELF_ST_TYPE(sym->st_info)==STT_FUNC) s|=1;
>>        s-=p+4; /*FIXME maybe drop 4 and add_val below*/
>>        s=((long)s>>1);
>>        massert(!(abs(s)&0xffc00000));
>>        store_val(where,MASK(11),s>>11);
>>        store_val(where,MASK(11)<<16,(s&0x7ff)<<16);
>>        break;
>>      case R_ARM_THM_MOVW_ABS_NC:
>>        s+=a;
>>        if (ELF_ST_TYPE(sym->st_info)==STT_FUNC) s|=1;
>>        s&=0xffff;
>>        s=((s>>12)&0xf)|(((s>>11)&0x1)<<10)|((s&0xff)<<16)|(((s>>8)&0x7)<<28);
>>        add_vals(where,~0L,s);
>>        break;
>>      case R_ARM_THM_MOVW_ABS:
>>        s+=a;
>>        s>>=16;
>>        s=((s>>12)&0xf)|(((s>>11)&0x1)<<10)|((s&0xff)<<16)|(((s>>8)&0x7)<<28);
>>        add_vals(where,~0L,s);
>>        break;
>>      case R_ARM_CALL:
>>        add_vals(where,MASK(24),((long)(s+a-p))>>2);
>>        break;
>>      case R_ARM_ABS32:
>>        add_val(where,~0L,s+a);
>>        break;
>>      case R_ARM_V4BX:
>>        add_val(where,~0L,s+a);
>>        break;
>>
>>
>> I've found the quickest way to implement these is to make a simple a.out
>> file with ld -R<main program>  <foo.o>  and reverse engineer, looking at
>> binutils and some platform docs as necessary.
>>
>> I'm missing ia64 only -- any help here?
>>
>> Take care,
>>
>>
>>
>> Clint Adams<address@hidden>  writes:
>>
>>> On Tue, Jan 10, 2012 at 03:17:41PM -0500, Ben Gamari wrote:
>>>> If anyone knows people experienced in ARM linker implementation, then feel
>>>> free to send them my way. At this point I'm at the difficult point of
>>>> figuring out why some relocation (plural?) sends the CPU to the
>>>> middle of nowhere. I've had next to no experience with linker
>>>> implementation in general, much less the mess that seems to be ARM, so
>>>> feedback from someone with some experience in this field would be
>>>> definitely appreciated. As Karel said, there is no Haskell code here at
>>>> all; strictly C.
>>>
>>> Maybe Camm has dealt with something similar already and can offer
>>> some insight?
>>>
>>>
>>>
>>>
>>
>
>
>
>
>

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