[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: Wed, 16 Jun 2010 17:54:48 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)


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                                                             
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) & 
   if (mprotect(p,pe-p,PROT_READ|PROT_WRITE|PROT_EXEC)) {\
     fprintf(stderr,"%p %p\n",p,pe);\
     FEerror("Cannot mprotect", 0);\

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) == 
      if (!bfd_mach_o_get_indirect_section_contents (abfd, link_info, asect,
                                                     data, symbols))
        return NULL;

      return data;
      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);


#if defined(DARWIN)
  if (!bfd_mach_o_inject_fp_branch_islands (b, bi, q))
    FEerror ("Could not inject fp register preservation stubs",0);

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

reply via email to

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