gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: trapping segfaults on mac os x


From: Camm Maguire
Subject: [Gcl-devel] Re: trapping segfaults on mac os x
Date: Mon, 19 Jul 2010 13:29:39 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Greetings!  Thanks to your helpful pointers, relocation is working on
bot intel and ppc mac.  Really appreciate your feedback.

Last point which you also appear to have worked on.  The mac does not
appear to be trapping SIGSEGV via sigaction in the standard way (for
SGC garbage collection).  Under gdb, the process appears to receive
something straight from the kernel, EXC_BAD_ACCESS, and does not
trigger or enter the handler at all.  Do you have any suggestion 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]