|
Home > Archive > Unix Programming > July 2007 > Cross platform pointer to program text area?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Cross platform pointer to program text area?
|
|
| Boltar 2007-07-04, 7:21 am |
| Hi
I wish to write an app that will checksum certain parts of itself once
its loaded into memory. Is there a cross platform way (ie no
assembler) in C to get the pointer to the start of the program text
area? If so would it be effected by shared libraries being loaded by
the ld or by dlopen()?
Thanks for any help
B2003
| |
| Rainer Temme 2007-07-04, 7:21 am |
| Boltar wrote:
> I wish to write an app that will checksum certain parts of itself once
> its loaded into memory. Is there a cross platform way (ie no
> assembler) in C to get the pointer to the start of the program text
> area? If so would it be effected by shared libraries being loaded by
> the ld or by dlopen()?
I believe it's not even save to assume that you can
read the text-segments on every platform. These
segments could have their access-flag set to
execute-only (if the underlying hardware supports this).
| |
| Boltar 2007-07-04, 7:21 am |
| On 4 Jul, 10:00, Rainer Temme <Rainer_Te...@nospam.hotmail_dot_com>
wrote:
> I believe it's not even save to assume that you can
> read the text-segments on every platform. These
> segments could have their access-flag set to
> execute-only (if the underlying hardware supports this).
Ugh , hadn't thought of that. My only other option is to just read
through the binary file using file I/O or mmap which seems a bit
clunky not to mention wasteful of memory.
B2003
| |
| Rainer Weikusat 2007-07-04, 7:21 am |
| Rainer Temme <Rainer_Temme@nospam.hotmail_dot_com> writes:
> Boltar wrote:
>
> I believe it's not even save to assume that you can
> read the text-segments on every platform. These
> segments could have their access-flag set to
> execute-only.
This would amount to a Harvard-architecture where the MMU selectively
allows or disallows read accesses, based on the path they came in (data
or instruction) and the access protection attribtute associated with a
specific 'virtual memory' section.
Does such a thing actually exist and if so, what is its name and which
UNIX(*) runs or used to run on it?
| |
| Logan Shaw 2007-07-04, 1:22 pm |
| Rainer Weikusat wrote:
> Rainer Temme <Rainer_Temme@nospam.hotmail_dot_com> writes:
[vbcol=seagreen]
[vbcol=seagreen]
> This would amount to a Harvard-architecture where the MMU selectively
> allows or disallows read accesses, based on the path they came in (data
> or instruction) and the access protection attribtute associated with a
> specific 'virtual memory' section.
>
> Does such a thing actually exist and if so, what is its name and which
> UNIX(*) runs or used to run on it?
I am not an expert, but I have done a little programming on ARM machines,
some of which have separate caches for data and instructions. I even
ran into an issue related to this: I was loading some code into memory[1],
and because I was writing it through the data cache, the changes weren't
making it into the instruction cache[2]. Therefore, when I tried to execute
it, it was executing garbage and the machine would crash.
Anyway, like I said, I'm not an expert, but I believe a separation between
instructions and data is a feature of the platform in general. In fact,
here's a product information page for an Intel ARM processor that appears
to have separate MMUs for data and instructions:
http://www.intel.com/design/iio/80200.htm
If you look at the block diagram, you can see what looks like two separate
MMUs, one on each of the two caches. If these have separate access
permissions -- as the bullet items under "Features and Benefits" imply
they do -- then...
As for whether any Unix variant runs on such a system or has, it's
certainly possible. There are a lot of embedded devices and portable
devices (PDAs, phones, etc.) that run on ARM processors, and Unix and
Linux are starting to be adopted in those areas. In particular, the
iPhone runs on ARM, apparently the Marvell PXA320. And the iPhone is
supposedly running OS X, which "is" Unix (there are reports that someone
has run crack against its /etc/passwd and recovered some passwords, so
it would appear that Apple hasn't stripped out the Unix parts of OS X
for the iPhone version).
Also, Palm is promising Linux stuff, probably on ARM. The Palm Foleo
(their "hey look, it's not a laptop even though it looks like one!"
product) will run Linux, and other devices are supposed to as well.
I suppose it's possible they could use some other processor, but all
their devices for the last several years have been ARM.
The point, though, is not about these specific devices. It's just
that ARM is a pseudo-Harvard architecture, and Unix/Linux on ARM is
a reality and may become more popular in the future.
- Logan
[1] Because Palm OS didn't do this for you with ARM code, you have to do
it manually.
[2] Because Palm OS doesn't supply you with any method to flush the cache!
| |
| Rainer Weikusat 2007-07-04, 7:17 pm |
| Logan Shaw <lshaw-usenet@austin.rr.com> writes:
[...]
> Anyway, like I said, I'm not an expert, but I believe a separation between
> instructions and data is a feature of the platform in general.
That's why it is called 'a Harvard architecture'. I happen to have a
copy of the ARM reference manual sittiing on my desk, because parts of
the software I am responsible for are written in ARM assembly
(some of them by me). The ARM v5 MMU architecture does not support
this.
| |
| Boltar 2007-07-05, 7:19 am |
| On 4 Jul, 18:59, Logan Shaw <lshaw-use...@austin.rr.com> wrote:
> supposedly running OS X, which "is" Unix (there are reports that someone
Depends what you mean by unix. Its certainly unixy but I wouldn't call
it unix mainly because of the munging (for no good reason IMO) they've
done of the standard unix file system layout. Not to mention the
proprietary graphics system and executable format. Though its all
shades of grey with the what-is-unix argument so you could argue one
way or another I suppose.
B2003
| |
| Rainer Weikusat 2007-07-05, 7:19 am |
| Boltar <boltar2003@yahoo.co.uk> writes:
> On 4 Jul, 18:59, Logan Shaw <lshaw-use...@austin.rr.com> wrote:
>
> Depends what you mean by unix. Its certainly unixy but I wouldn't call
> it unix mainly because of the munging (for no good reason IMO) they've
> done of the standard unix file system layout. Not to mention the
> proprietary graphics system and executable format. Though its all
> shades of grey with the what-is-unix argument so you could argue one
> way or another I suppose.
As far as I know, Mac OS X is basically a Mach-Microkernel running
'some 4.4BSD' with 'some FreeBSD patches' as monolithic system task
and something very similar used to be called 'UNIX(*)' not that long
ago (with Apple - as always - being some ten years behind current
technology).
| |
| Logan Shaw 2007-07-06, 1:23 am |
| Boltar wrote:
> On 4 Jul, 18:59, Logan Shaw <lshaw-use...@austin.rr.com> wrote:
[vbcol=seagreen]
> Depends what you mean by unix.
Yes, that's sort of why I put the quotation marks around "is". :-)
- Logan
| |
| Marco van de Voort 2007-07-27, 7:18 am |
| On 2007-07-05, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> As far as I know, Mac OS X is basically a Mach-Microkernel running
> 'some 4.4BSD' with 'some FreeBSD patches' as monolithic system task
> and something very similar used to be called 'UNIX(*)'
Mostly the unix userland is FreeBSD 5 as of 10.3 afaik yes. But some parts
(like the linker) are indeed still of old 4.4bsd descent.
> not that long ago (with Apple - as always - being some ten years behind
> current technology).
They had specific requests for backwards compat. Both binary format (and
dynamic linking) and filesystem related. Most of the rest seems relatively
modern.
|
|
|
|
|