gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] mprotect question


From: Camm Maguire
Subject: Re: [Gcl-devel] mprotect question
Date: 04 Sep 2003 10:16:48 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Aurelien Chanudet <address@hidden> writes:

> Hi,
> 
> I've tried compiling ACL2 on Mac OS X. Towards the end of the build,
> the compilation errors out, because mprotect (called from within GCL's
> sgc_mprotect) fails to promote a page whose max protection is
> read/write (not execute) to read/write/execute. A temporary fix is to
> promote the max protection to read/write/execute.
> 
> However, I'm wondering why this is happening. When GCL allocates
> memory pages, the initial max protection for these pages is set to
> read/write/execute. So, for a page's max protection to end up being
> read/write as in the afore-mentioned issue, someone must have change
> the max protection. My first question is : does GCL explicitly change
> a page's max protection ?
> 
> The stratified garbage collection code actually #defines
> PROT_READ_WRITE to be (PROT_READ | PROT_WRITE | PROT_EXEC). My second
> question is : where does the need for PROT_EXEC exactly originate from
> ?
> 

OK, last question first, PROT_EXEC is needed to execute compiled
object files loaded into GCL's data core.  As you are using dlopen,
you don't strictly need this, but GCL currently uses PROT_EXEC
everywhere for simplicity.  

The new page procedure goes like this, at least on linux:

sbrk
if (sgc_enabled)
mprotect(PROT_READ|PROT_WRITE|PROT_EXEC)

My guess is that the default permissions returned by sbrk on your
system are different from those on linux.  If sgc_enabled is false,
pages will just go through the sbrk, and then will be mprotected
PROT_READ when sgc_start is called (as they would be old pages).  Then
a write happens to the page, a SEGV is raised, and the attempted
promotion mprotect is called.  I don't know why sbrk -> PROT_READ ->
PROT_READ_WRITE_EXEC would fail if sbrk -> PROT_READ_WRITE_EXEC
succeeds, but if this is the case for some reason, you could try
adding an explicit mprotect READ_WRITE_EXEC after the sbrk and before
the if(sgc_enabled) in alloc_page.

Please keep me posted, and thanks as always for your work on this!

Take care,

> Thanks,
> Aurelien
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
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]