gcl-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]