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 <aurelien.chanu...@gmail.com> 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 <c...@maguirefamily.org> 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 <aurelien.chanu...@gmail.com> writes: >> >>> Sure, how can I help ? >>> >>> On Tue, Jun 15, 2010 at 10:57 PM, Camm Maguire <c...@maguirefamily.org> >>> 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 <aurelien.chanu...@gmail.com> 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 <c...@maguirefamily.org> >>>>> wrote: >>>>>> Hi Aurelien! Checking to see if you are reachable at this address. >>>>>> >>>>>> Take care, >>>>>> -- >>>>>> Camm Maguire >>>>>> c...@maguirefamily.org >>>>>> ========================================================================== >>>>>> "The earth is but one country, and mankind its citizens." -- >>>>>> Baha'u'llah >>>>>> >>>> >>>> -- >>>> Camm Maguire c...@maguirefamily.org >>>> ========================================================================== >>>> "The earth is but one country, and mankind its citizens." -- Baha'u'llah >>>> >>> >>> >>> >>> >> >> -- >> Camm Maguire c...@maguirefamily.org >> ========================================================================== >> "The earth is but one country, and mankind its citizens." -- Baha'u'llah >> > > > > -- Camm Maguire c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
