[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: mach-o-reloc.c
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Re: mach-o-reloc.c |
Date: |
Thu, 15 Jul 2010 01:36:15 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
Greetings!
OK, all is looking well now for ppc and x86_32 macosx, except for SGC
garbage collection. The issue here is that the kernel sends
EXC_BAD_ACCESS when writing to mprotected memory, apparently usurping
the SEGFAULT the libc would normally pass to the handler. Any ideas
here?
Take care,
Aurelien Chanudet <address@hidden> writes:
> Hi Camm,
>
> 1) Documentation : check out http://www.opensource.apple.com and look
> for source code of dyld (dynamic loader), gdb, etc.
>
> 2) Do you know how to make loaded code executable on the intel mac?
> I don't but I guess one can find code snippets in the source code of
> dyld or gdb.
>
> Why was there apparently no protection issue on ppc?
> Isn't the code flagged as execution enabled when unexec'ing ?
>
> 3) Would you expect this to be ppc specific in any way?
> Yes, it is ppc specific. Branch islands are necessary on ppc because
> assembly instructions are hardcoded on 32 bits with 8 bits for the
> operand and 24 bits for the argument. Which means that one cannot jump
> from one point in memory to another point in memory with the two
> points being distant from more than can be coded on 24 bits.
>
> 4) sbrk : as far as I remember, sbrk was poorly implemented on Mac OS
> X which is why I probably overloaded it.
>
> Hope this helps,
> Aurelien
>
> On Wed, Jun 16, 2010 at 11:54 PM, Camm Maguire <address@hidden> wrote:
>> Greetings!
>>
>> OK first as a reminder, your very helpful contributions included
>> unexec and bfd object loading and execution on ppc mac os x.
>>
>> 1) Where did you go for documentation on these items?
>>
>> 2) Once an object is loaded, the instuction cache must be cleared
>> before it can be executed. You had the following macro for ppc mac:
>>
>> #define CLEAR_CACHE_LINE_SIZE 32
>> #define CLEAR_CACHE
>> \
>> do {
>> \
>> void *v=memory->cfd.cfd_start,*ve=v+memory->cfd.cfd_size;
>> \
>> v=(void *)((unsigned long)v & ~(CLEAR_CACHE_LINE_SIZE - 1));
>> \
>> for (;v<ve;v+=CLEAR_CACHE_LINE_SIZE)
>> \
>> asm __volatile__
>> \
>> ("dcbst 0,%0\n\tsync\n\ticbi 0,%0\n\tsync\n\tisync": : "r" (v) :
>> "memory"); \
>> } while(0)
>>
>> I've tried using the 386 equivalent (for various OSes)
>>
>> #define CLEAR_CACHE {\
>> void *p,*pe; \
>> p=(void *)((unsigned long)memory->cfd.cfd_start & ~(PAGESIZE-1)); \
>> pe=(void *)((unsigned long)(memory->cfd.cfd_start+memory->cfd.cfd_size) &
>> ~(PAGESIZE-1)) + PAGESIZE-1; \
>> if (mprotect(p,pe-p,PROT_READ|PROT_WRITE|PROT_EXEC)) {\
>> fprintf(stderr,"%p %p\n",p,pe);\
>> perror("");\
>> FEerror("Cannot mprotect", 0);\
>> }\
>> }
>> #endif
>>
>> which typically clears the cache automatically at a higher level.
>> This is returning EACCES for me. When omitted, the kernel gives me
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: 13 at address: 0x0000006c
>>
>> Do you know how to make loaded code executable on the intel mac? Why
>> was there apparently no protection issue on ppc?
>>
>> 3) Current bfd has many of the functions you implemented for ppc mac
>> in a file mach-o-i386.c. But I noticed you were careful to sidestep
>> the generic get_relocated_section_contents in certain cases:
>>
>> if ((sectp != NULL) &&
>> (((sectp->flags & SECTION_TYPE) == BFD_MACH_O_S_LAZY_SYMBOL_POINTERS) ||
>> ((sectp->flags & SECTION_TYPE) ==
>> BFD_MACH_O_S_NON_LAZY_SYMBOL_POINTERS)))
>> {
>> if (!bfd_mach_o_get_indirect_section_contents (abfd, link_info, asect,
>> data, symbols))
>> return NULL;
>>
>> return data;
>> }
>> else
>> {
>> return bfd_generic_get_relocated_section_contents (abfd, link_info,
>> link_order, data,
>> relocateable,
>> symbols);
>> }
>>
>>
>> This appears to be connected to the "branch islands" you "craft" and
>> "inject" here:
>>
>> #if defined(DARWIN)
>> if ((bi = bfd_mach_o_craft_fp_branch_islands (b)) == NULL)
>> FEerror ("Could not craft fp register preservation stubs",0);
>> #endif
>>
>> ...
>>
>> #if defined(DARWIN)
>> if (!bfd_mach_o_inject_fp_branch_islands (b, bi, q))
>> FEerror ("Could not inject fp register preservation stubs",0);
>> #endif> Would you expect this to be ppc specific in any way? The standard
>> get_relocated_section_contents returns successfully with latest
>> upstream binutils without this extra code (apparently). (I cannot yet
>> verify its correctness due to 2)).
>
>>
>>
>> 4) I've had to update unexmacosx.c from latest emacs. This appears
>> to be working. vm_allocate in place of sbrk() appears OK. I was
>> wondering if you knew why sbrk() successfully appends a few meg and no
>> more to the .data section. Is this a question of some hard limit
>> encoded in the binary, or a kernel limitation? ulimit does not appear
>> to alter the result. Would a linker script moving the .data section
>> address elsewhere change things? It would be simpler to have a common
>> sbrk target from a gcl development perspective if possible.
>>
>> Thank you so much again!
>>
>> Aurelien Chanudet <address@hidden> writes:
>>
>>> Sure, how can I help ?
>>>
>>> On Tue, Jun 15, 2010 at 10:57 PM, Camm Maguire <address@hidden> wrote:
>>>> Greetings! Understood. As am I.
>>>>
>>>> Still, I was wondering if I might bother you with a few questions
>>>> regarding what I think should be relatively trivial modifications to
>>>> your file to run on intel macs. May I ask, with the understanding of
>>>> course that you let me know immediately when your time becomes short?
>>>>
>>>> Take care,
>>>>
>>>> Aurelien Chanudet <address@hidden> writes:
>>>>
>>>>> Hi Camm,
>>>>>
>>>>> Yes I'm but much less involved in open source development as I was a
>>>>> couple of years ago.
>>>>>
>>>>> Aurelien
>>>>>
>>>>> On Tue, Jun 15, 2010 at 6:28 PM, Camm Maguire <address@hidden> wrote:
>>>>>> Hi Aurelien! Checking to see if you are reachable at this address.
>>>>>>
>>>>>> Take care,
>>>>>> --
>>>>>> Camm Maguire address@hidden
>>>>>> ==========================================================================
>>>>>> "The earth is but one country, and mankind its citizens." --
>>>>>> Baha'u'llah
>>>>>>
>>>>
>>>> --
>>>> Camm Maguire address@hidden
>>>> ==========================================================================
>>>> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Camm Maguire address@hidden
>> ==========================================================================
>> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>>
>
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gcl-devel] Re: mach-o-reloc.c,
Camm Maguire <=