[ clisp-Bugs-1672132 ] mprotect configure test incorrect

[SourceForge.net <no...@so...>]

Bugs item #1672132, was opened at 2007-03-01 20:26
Message generated for change (Settings changed) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1672132&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: clisp
Group: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Adam Fedor (fgstep)
Assigned to: Bruno Haible (haible)
Summary: mprotect configure test incorrect

Initial Comment:
The configure test for mprotect appears to be incorrect, producing exactly the opposite result it is supposed to. Attached is the patch

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2007-03-04 19:44

Message:
Logged In: YES 
user_id=5735
Originator: NO

OK, so you are saying that the tests are too permissive.
fine, please add more tests (but first make sure that they will not cause
undue loss of mprotect functionality on linux etc)

----------------------------------------------------------------------

Comment By: Adam Fedor (fgstep)
Date: 2007-03-04 17:58

Message:
Logged In: YES 
user_id=1326233
Originator: YES

Err, OK I see that. But now the test makes absolutely no sense at all. All
it seems to be testing is that you are properly prohibited from looking at
or writing to memory that has been protected correctly.  It certainly
doesn't check to see if you can make memory writeable or even executable,
which is what trampoline.c expects to use it for. I'll defer to other bugs
(#1531290 for instance), which encapsulate what I really want fixed...

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2007-03-04 13:01

Message:
Logged In: YES 
user_id=5735
Originator: NO

I deleted my patch because I now think that the original code is correct.
please examine the comments:
/* this should cause an exception or signal */ ==>
action-if-succeed="no_mprotect=1"
/* this should not cause an exception or signal */ ==>
action-if-fail="no_mprotect=1"

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2007-03-04 13:01

Message:
Logged In: YES 
user_id=5735
Originator: NO

This bug report is now marked as "pending"/"works for me".
This means that we think that we cannot reproduce the problem
and cannot do anything about it.
Unless you - the reporter - act within 2 weeks
(e.g., by submitting a self-contained test case),
the bug will be permanently closed.
Sorry about the inconvenience - 
we hope your silence means that 
you are no longer observing the problem either.


----------------------------------------------------------------------

Comment By: Adam Fedor (fgstep)
Date: 2007-03-04 12:48

Message:
Logged In: YES 
user_id=1326233
Originator: YES

OK. I missed that one. Thanks.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2007-03-03 23:46

Message:
Logged In: YES 
user_id=5735
Originator: NO

then why are you changing the 2 places only?
see my patch (attached): now no_mprotect is handled identically in all 5
places.
File Added: mprotect.m4.diff

----------------------------------------------------------------------

Comment By: Adam Fedor (fgstep)
Date: 2007-03-02 00:37

Message:
Logged In: YES 
user_id=1326233
Originator: YES

The autoconf code for AC_TRY_RUN is roughly: 
AC_TRY_RUN(program, action-if-succeed, action-if-fail,
action-if-cross-compile), 
and in mprotect.m4, it's implemented roughly as:
AC_TRY_RUN('mprotect program', no_mprotect=1, , )
so no_mprotect gets set if the program suceeds (it's correct in the first
test but not the others). Later on, it's tested:  if test -z
"$no_mprotect"; cl_cv_func_mprotect_works=yes - so the test shows mprotect
as working if no_mprotect is NOT set, but the previous AC_TRY_RUN tests set
no_mprotect if it does works.  I can show you a config.log file where the
mprotect test clearly fails, but HAVE_WORKING_MPROTECT is defined. Perhaps
it's worked all these years for other reasons?

Actually, I found this on powerpc-apple-darwin8.8 and fixed it, but this
just causes other problems, which may be similar to bug #1535284. Perhaps I
just need to look at the wider issue of what's not working...


----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2007-03-02 00:00

Message:
Logged In: YES 
user_id=5735
Originator: NO

the current code have been detecting mprotect just fine for many years.
could you please be more specific - what are you unhappy about?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1672132&group_id=1355