[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: Mac OS X
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] Re: Mac OS X |
Date: |
Wed, 23 Jun 2010 17:32:57 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
That would be so great -- thanks!
Matt Kaufmann <address@hidden> writes:
> Hi, Camm --
>
> In case you don't need that Mac to be at Tim's site:
>
> On my desktop I have a ppc mac running Mac OS 10.4.11. I can give you
> an account when I'm at work tomorrow, if you like.
>
> -- Matt
> From: Camm Maguire <address@hidden>
> Date: Wed, 23 Jun 2010 16:29:32 -0400
> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2)
> Cc: address@hidden
> Sender: address@hidden
> X-SpamAssassin-Status: No, hits=-0.7 required=5.0
> X-UTCS-Spam-Status: No, hits=-256 required=165
>
> Greetings! You don't happen to have access to an older ppc mac os x
> box so I can compare the older working code, do you?
>
> Take care,
>
> Tim Daly <address@hidden> writes:
>
> > fixed
> >
> > Camm Maguire wrote:
> >> Greetings, and thanks!
> >>
> >> ssh axiom-developer.com
> >> ssh: connect to host axiom-developer.com port 22: Connection refused
> >>
> >>
> >> Tim Daly <address@hidden> writes:
> >>
> >>
> >>> The server is rebooted.
> >>>
> >>> Camm Maguire wrote:
> >>>
> >>>> Greetings!
> >>>>
> >>>> Tim Daly <address@hidden> writes:
> >>>>
> >>>>
> >>>>> Generally I encounter these kinds of errors due to SELinux.
> >>>>> I disable SELinux exec-shield and randomize loading everywhere.
> >>>>> They are pointless bandaids. However, on OS X I don't see them
> >>>>> installed anywhere.
> >>>>>
> >>>>> There is a check for "use secure virtual memory" in security
> >>>>>
> >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>>
> >>>> This sounds promising. I'm ready for a reboot whenever you are. If
> >>>> you can drop me a note when its back up that would be great.
> >>>>
> >>>> Take care,
> >>>>
> >>>>
> >>>>> which I disabled but I'll need to reboot for it to take effect.
> >>>>> I can reboot anytime but you'll have to let me know when.
> >>>>>
> >>>>> Camm Maguire wrote:
> >>>>>
> >>>>>> Greetings! Progess continues, but now I've run into a new
> (hopefully
> >>>>>> final) difficulty. GCL loads compiled .o files, marks the memory
> >>>>>> PROT_READ|PROT_WRITE|PROT_EXEC, and then executes it. Typically,
> the
> >>>>>> memory resides in the .data segment, but here there is a static
> >>>>>> separate heap allocated with vm_allocate. In any case, mprotect is
> >>>>>> returning "permision denied"
> >>>>>>
> >>>>>> [EACCES] The requested protection conflicts with the
> access
> >>>>>> permissions of the process on the specified
> address
> >>>>>> range.
> >>>>>>
> >>>>>> Something in the kernel is setup to forbid execution (most likely)
> of
> >>>>>> vm_allocate'd memory. Omiting the call gives a kernel access denied
> >>>>>> error on jumping to the new address. (On ppc mac os x, there was no
> >>>>>> mprotect required, just some (ppc specific) assembly to clear the
> >>>>>> instruction cache. This mprotect setup is what is used on the
> >>>>>> majority of linux platforms.)
> >>>>>>
> >>>>>> Anyway, wondering if you new anything about your kernel security
> >>>>>> settings and/or might you check your logs to get a hint toward a
> >>>>>> workaround.
> >>>>>>
> >>>>>> Take care,
> >>>>>>
> >>>>>> Tim Daly <address@hidden> writes:
> >>>>>>
> >>>>>>
> >>>>>>> xcode-select -printpath shows /Developer which is where XCode
> lives.
> >>>>>>>
> >>>>>>> I am downloading the latest xcode now.
> >>>>>>>
> >>>>>>> Camm Maguire wrote:
> >>>>>>>
> >>>>>>>> Greetings! I've been told gcc-4.2 is the latest for mac, but you
> have
> >>>>>>>> 4.0 installed. Is something called xcode installed? macports?
> Are
> >>>>>>>> there any command line tools to query installed software and
> available
> >>>>>>>> options? Can you please install gcc 4.2?
> >>>>>>>>
> >>>>>>>> Take care,
> >>>>>>>>
> >>>>>>>> Tim Daly <address@hidden> writes:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> I show some speculation below but perhaps rewriting this
> >>>>>>>>>
> >>>>>>>>> malloc_list->c.c_car = alloc_simple_string(size);
> >>>>>>>>>
> >>>>>>>>> into
> >>>>>>>>> t1 = alloc_simple_string(size);
> >>>>>>>>> t2 = malloc_list->c
> >>>>>>>>> t3.c = t1
> >>>>>>>>>
> >>>>>>>>> or some equivalent might
> >>>>>>>>> (a) not trip across the compiler bug and
> >>>>>>>>> (b) give you a better clue what it does not like
> >>>>>>>>>
> >>>>>>>>> Camm Maguire wrote:
> >>>>>>>>>
> >>>>>>>>>> Greetings!
> >>>>>>>>>>
> >>>>>>>>>> Tim Daly <address@hidden> writes:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> The MAC is back online.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> Thanks!
> >>>>>>>>>>
> >>>>>>>>>> Do you speak any assembler? I'm failing now here:
> >>>>>>>>>>
> >>>>>>>>>> 0x0000641e <my_malloc+134>: call 0x2e5b <make_cons>
> >>>>>>>>>>
> >>>>>>>>> this call succeeded so now we need to set up the stack for the
> >>>>>>>>> alloc_simple_string call
> >>>>>>>>> to do that the compiler would have to
> >>>>>>>>> (a) get the malloc_list value
> >>>>>>>>> (b) get the c struct pointer
> >>>>>>>>> (c) get the c_car pointer off of the c struct
> >>>>>>>>> (d) push the size
> >>>>>>>>> (e) call alloc_simple_string
> >>>>>>>>> so I'm going to do some guessing.
> >>>>>>>>>
> >>>>>>>>>> 0x00006423 <my_malloc+139>: mov %eax,%edx
> >>>>>>>>>>
> >>>>>>>>> Notice that the 'lea 0x233caf(%ebx)' (load effective address) is
> done twice.
> >>>>>>>>> This must be a reference to a known location since the compiler
> has
> >>>>>>>>> inlined it.
> >>>>>>>>> It is not clear what this "known location" is since I don't have
> the
> >>>>>>>>> symbol table
> >>>>>>>>> but I'm guessing it is "malloc_list"
> >>>>>>>>>
> >>>>>>>>> Proceeding on that assumption we load %eax with the address of
> malloc_list
> >>>>>>>>>
> >>>>>>>>>> 0x00006425 <my_malloc+141>: lea 0x233caf(%ebx),%eax
> >>>>>>>>>>
> >>>>>>>>> We then use the contents of %eax (the address of malloc_list) to
> get
> >>>>>>>>> the word
> >>>>>>>>> it points at.... maybe malloc_list->c
> >>>>>>>>>
> >>>>>>>>>> 0x0000642b <my_malloc+147>: mov (%eax),%eax
>
> >>>>>>>>> Then we try to store %edx into this location pointer? But %edx
> is a
> >>>>>>>>> free variable here
> >>>>>>>>> so I have no idea what it might contain.
> >>>>>>>>>
> >>>>>>>>>> 0x0000642d <my_malloc+149>: mov %edx,(%eax)
> >>>>>>>>>> <-------
> >>>>>>>>>> 0x0000642f <my_malloc+151>: lea 0x233caf(%ebx),%eax
> >>>>>>>>>> 0x00006435 <my_malloc+157>: mov (%eax),%eax
> >>>>>>>>>> 0x00006437 <my_malloc+159>: mov (%eax),%esi
> >>>>>>>>>>
> >>>>>>>>> at this point 0x8(%ebp) would be an access off the base pointer
> of the frame
> >>>>>>>>> so I'm guessing that 'size' was passed in from some prior call.
> %eax
> >>>>>>>>> contains
> >>>>>>>>> the 'size' value.
> >>>>>>>>>
> >>>>>>>>>> 0x00006439 <my_malloc+161>: mov 0x8(%ebp),%eax
> >>>>>>>>>>
> >>>>>>>>> at this point %eax must contain the address of 'size' (item d
> above)
> >>>>>>>>>
> >>>>>>>>>> 0x0000643c <my_malloc+164>: mov %eax,(%esp)
> >>>>>>>>>>
> >>>>>>>>> at this point the top of stack would be pointing at the 'size'
> argument
> >>>>>>>>>
> >>>>>>>>>> 0x0000643f <my_malloc+167>: call 0xa79a4
> <alloc_simple_string>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> on C code
> >>>>>>>>>>
> >>>>>>>>>> malloc_list = make_cons(Cnil, malloc_list);
> >>>>>>>>>>
> >>>>>>>>>> malloc_list->c.c_car = alloc_simple_string(size);
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> with
> >>>>>>>>>>
> >>>>>>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
> >>>>>>>>>> Reason: KERN_INVALID_ADDRESS at address: 0xff17a000
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> because gcc compiled some dereferencing of this address at the
> above
> >>>>>>>>>> instruction between the calls, presumably to set the cons to the
> >>>>>>>>>> variable malloc_list. But the address of the latter is not
> 0xff17a000
> >>>>>>>>>> but
> >>>>>>>>>>
> >>>>>>>>>> p &malloc_list
> >>>>>>>>>> $7 = (object *) 0x102410
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Anyway, I have no contacts with any mac people, so don't know
> where
> >>>>>>>>>> really to turn. First guess is a compiler bug. Google turns
> up other
> >>>>>>>>>> examples (different applications) with no obvious solutions.
> >>>>>>>>>>
> >>>>>>>>>> Take care,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Camm Maguire wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Greetings!
> >>>>>>>>>>>>
> >>>>>>>>>>>> Tim Daly <address@hidden> writes:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
>
> >>>>>>>>>>>>> Actually all of the code is gradually getting moved into a
> single
> >>>>>>>>>>>>> file, e.g. the interpreter code will all live in
> bookvol5.lsp.
> >>>>>>>>>>>>> I will be adding type decorations for the lisp code directly
> >>>>>>>>>>>>> into the file.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'm still in the process of consolidating the code. I have
> about
> >>>>>>>>>>>>> 120 files to add. I am "tree-shaking" the code as I add it
> so only
> >>>>>>>>>>>>> live routines are picked up. Old, dead code is never moved
> and dropped.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I am trying to create a fully literate form of Axiom so all
> of
> >>>>>>>>>>>>> the code in the interpreter will be in book form, in volume
> 5.
> >>>>>>>>>>>>> All of the compiler will live in volume 9.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I have moved most of the system already. All of the spad
> code lives
> >>>>>>>>>>>>> in volume 10, all of the graphics (vol8) and hyperdoc (vol
> 7) are
> >>>>>>>>>>>>> in their own books.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I want to restructure Axiom along the lines of Christian
> Queinnac's
> >>>>>>>>>>>>> Lisp In Small Pieces book. You should be able to "read"
> Axiom like
> >>>>>>>>>>>>> a novel. That way, when I get hit by a bus, someone else has
> a slim
> >>>>>>>>>>>>> chance of maintaining and extending Axiom. Otherwise this
> code is
> >>>>>>>>>>>>> way too complex and it will just die.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
>
> >>>>>>>>>>>> Needless to say, I think your efforts are just fantastic.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Not to distract from them, but if we could get these two
> :native-reloc
> >>>>>>>>>>>> patches in at the depsys and interpsys creation stages, and
> >>>>>>>>>>>> (hopefully) if we could get into the testing loop a test
> build with a
> >>>>>>>>>>>> gcl without :native-reloc in *features*, life, at least
> Debian/Ubuntu
> >>>>>>>>>>>> life, would go ever so much more smoothly.
> >>>>>>>>>>>>
> >>>>>>>>>>>> These #-native-reloc branches are successfully working on
> alpha, mips,
> >>>>>>>>>>>> mipsel, ia64, and hppa at
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://buildd.debian.org/status/package.php?p=axiom
> >>>>>>>>>>>>
> >>>>>>>>>>>> BTW, intel mac appears to be off again. Would it be possible
> to leave
> >>>>>>>>>>>> it up and I will let you know when I've figured out a fix?
> It could
> >>>>>>>>>>>> take some time alas, as its related to gmp and not gcl proper.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Take care,
> >>>>>>>>>>>>
> >>>>>>>>>>>>
>
> >>>>>>>>>>>>> Tim
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Camm Maguire wrote:
> >>>>>>>>>>>>>
>
> >>>>>>>>>>>>>> BTW, I take it the older PASS1=t build followed by a touch
> of all lsp
> >>>>>>>>>>>>>> and a remake to load the .fn files is no longer required
> for optimal
> >>>>>>>>>>>>>> compilations?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Take care,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Tim Daly <address@hidden> writes:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
>
> >>>>>>>>>>>>>>> ssh address@hidden (note the .com, not .org)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Camm Maguire wrote:
> >>>>>>>>>>>>>>>
>
> >>>>>>>>>>>>>>>> Greetings! Tim, do you have a publicly accessible intel
> mac osx
> >>>>>>>>>>>>>>>> machine I can use for gcl porting?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>>>>>
>
> >>>>>>>>>>>>>>>
>
> >>>>>>>>>>>>>>
>
> >>>>>>>>>>>>>
>
> >>>>>>>>>>>>
>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
> >
>
> --
> Camm Maguire address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- [Gcl-devel] Re: [Axiom-developer] Axiom May 2010 release, Camm Maguire, 2010/06/01
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- [Gcl-devel] Mac OS X, Camm Maguire, 2010/06/09
- Message not available
- Message not available
- Message not available
- [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/15
- Message not available
- Message not available
- Message not available
- [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/15
- Message not available
- Message not available
- Message not available
- [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/16
- Message not available
- [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/16
- Message not available
- [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/16
- Message not available
- [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/17
- Message not available
- [Gcl-devel] Re: Mac OS X, Camm Maguire, 2010/06/23
- Re: [Gcl-devel] Re: Mac OS X, Matt Kaufmann, 2010/06/23
- Re: [Gcl-devel] Re: Mac OS X,
Camm Maguire <=
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- [Gcl-devel] gcl on intel mac, Camm Maguire, 2010/06/29
- Message not available
- [Gcl-devel] Re: gcl on intel mac, Camm Maguire, 2010/06/30
- [Gcl-devel] Re: gcl on intel mac, Matt Kaufmann, 2010/06/30