[Top][All Lists]
[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