[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: Call for help with MACOSX Re: [Axiom-developer] [MAC
Re: [Gcl-devel] Re: Call for help with MACOSX Re: [Axiom-developer] [MACOSX] What is unexec and why does it fail ?
06 May 2005 17:26:38 -0400
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Aurelien, Darwin appears to be missing on_exit, which I've been using
in the new socket code to destroy forked children when the parent
quits. Is there similar on Darwin, or does this happen automatically
Have just tested 2.6.7 on macosx successfully. I take it you are too
busy to look at the large memory image issue, yes?
Aurelien Chanudet <address@hidden> writes:
> > Beyond the axiom issue discussed below, some acl2
> > users at the
> > University of Texas are running into difficulties
> > with the mac code
> > when making very large images. Would you have a
> > chance to try to
> > build ACL2 with maxpages doubled, quadrupled, and
> > even multiplied by 8
> > if you OS allows? Please let me know if you have
> > some time to
> > investigate this. I can send you more information
> > if so.
> What version of ACL2 and gcl are these people using ?
> Will try to give this a look as time permits. By the
> way, what's the status of SGC on the Mac now ? There
> have been some recent issues as far as I remember.
> > What dedication! Is this a known issue on the Mac?
> > Any help from the
> > gdb developers?
> This is a known issue on the Mac, albeit one that
> interests no one but me (for understandable reasons, I
> feel it way more confortable to debug SGC in GCL using
> gdb than using printf debugging). Basically, attaching
> gdb to a process, say GCL, which handles segfaults on
> its own, makes it impossible for the signal handler to
> be called. Gdb will simply refuse to pass the
> exception to the program. This is due to the way
> traditionnal Unix signals are handled in MacOSX's Mach
> kernel. Traditionnal signals are handled by a BSD
> layer which gdb bypasses...
> > I'm not sure what you mean here. Its in the CVS
> > head tree (aka 2.7.0)
> > to my understanding. Should I post it to the
> > website on the errata
> > page?
> It must be fine then. I must confess I'm not "CVS
> savvy". I just wanted to make sure that the file can
> be retrieved when using the basic "cvs login / cvs co"
> > 1) Add reloc records for any symbols relocated to a
> > dlopened library
> > in a given session, together with whatever
> > section is also needed
> > to indicate that the image is (now permanently)
> > dynamically linked
> > against the lib.
> > 2) Merge gprof section info from any loaded .o files
> > into the final
> > saved image so that profiling will work without
> > having to generate
> > a fresh image with ld.
> Under what form are gprof information stored ?
> Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour
> dialoguer instantanément avec vos amis. A télécharger gratuitement sur
> Gcl-devel mailing list
Camm Maguire address@hidden
"The earth is but one country, and mankind its citizens." -- Baha'u'llah