From: Josh Fryman <fryman@cc.gatech.edu>
To: linux-kernel@vger.kernel.org
Subject: Re: silly memory question ...
Date: Tue, 28 Aug 2001 10:47:56 -0400 [thread overview]
Message-ID: <3B8BAF1C.EC336B17@cc.gatech.edu> (raw)
In-Reply-To: <Pine.LNX.3.95.1010828101642.13417A-100000@chaos.analogic.com>
hi all,
thanks to all of you for your suggestions... it turns out this
is an ARM-specific issue, and maybe some other platforms as well.
(or maybe just my specific ARM kernel/glibc combo. ;)
it turns out x86 ignores some "modes" for pages in memory. or
maybe ld.so doesn't bother to set them. anyway, the code snippet
below "fixes" the pages i need fixed to become R/W/X.
on *my* ARM, you can't default execute data pages; you can't
write text pages; etc, etc. (my kernel is 2.4.0 with glibc 2.1.2.)
i don't know what other platforms enforce this, but hopefully
this is as educational for those suggesting solutions as it has
been for me. if i had specified i was running on ARM originally,
it may have made things clearer.
thanks again,
josh
// fix permissions on __app_code - we need R/W/X, not just R/X ...
// ARM-specific problem, but this fix should work on ALL platform targets
printf("Fixing TEXT segment permissions for R/W/X....\n");
for (i=0; i<APP_CODE_K*1024/PAGESIZE; i++)
{
code = (ui32*) ((((ui32)__app_code + i*PAGESIZE) - 1) & ~(PAGESIZE-1));
if (mprotect( code, PAGESIZE, PROT_READ|PROT_WRITE|PROT_EXEC) )
{
printf("mprotect() on 0x%08x failed!\nerrno (%d) indicates status: ", code, errno);
switch (errno)
{
case EINVAL: printf("EINVAL: not valid ptr, or not multiple of PAGESIZE (%d)\n", PAGESIZE);
break;
case EFAULT: printf("EFAULT: memory can not be accessed.\n");
break;
case EACCES: printf("EACCES: memory can not be given specified access modes.\n");
break;
case ENOMEM: printf("ENOMEM: internal kernel structures could not be allocated.\n");
break;
default: printf("??????: unknown error result.\n");
}
exit( CLNT_MPROT_FAIL );
}
}
note:
the dummy "nop" function "__app_code()" is APP_CODE_K in size of
KBs of NOPs.
note 2:
i hope the KiB/MiB/whatever standard suggestion is never adopted
and revoked really soon now.
next parent reply other threads:[~2001-08-28 14:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.3.95.1010828101642.13417A-100000@chaos.analogic.com>
2001-08-28 14:47 ` Josh Fryman [this message]
2001-08-27 18:24 silly memory question Josh Fryman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B8BAF1C.EC336B17@cc.gatech.edu \
--to=fryman@cc.gatech.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox