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).

On 4 Jul, 10:00, Rainer Temme
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 Temme writes:
> 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.

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?

Rainer Weikusat wrote:
> Rainer Temme writes:
>> 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.

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

Logan Shaw 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.

On 4 Jul, 18:59, Logan Shaw 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

Boltar writes:
> On 4 Jul, 18:59, Logan Shaw 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.

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).

Boltar wrote:
> On 4 Jul, 18:59, Logan Shaw wrote:
>> supposedly running OS X, which "is" Unix (there are reports that someone

> Depends what you mean by unix.

Yes, that's sort of why I put the quotation marks around "is". :-)

- Logan

Boltar wrote:

> On 4 Jul, 18:59, Logan Shaw 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.

The official answer is that OS X 10.4 (Tiger) is not, but
OS X 10.5 (Leopard) is, a UNIX(R) system:

http://www.opengroup.org/openbrand/r.../brand3555.htm

--
Geoff Clare

On 2007-07-05, Rainer Weikusat wrote:
>> 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(*)'

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.