[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] ghci on arm
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] ghci on arm |
Date: |
Fri, 27 Jan 2012 09:58:23 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) |
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
- Re: [Gcl-devel] ghci on arm, Camm Maguire, 2012/01/25
- Message not available
- Re: [Gcl-devel] ghci on arm,
Camm Maguire <=
- Message not available