Access to separate running program's global and initialised variable

[rjd324]

on a classic 68k machine using hunk. presumably the "loader" is LoadSeg. if the memory arrangement for classic machines is a flat physical-only memory region with those hunks loaded into free areas - then after a program has been loaded into memory and is executing, and it contains some initialised data and i print the address of that data - presumably this gives me the physical address of that data (the data hunk base+any offset?). why can a completely separate program not forcefully obtain the value of that global if it knows the address of that global in the physical address space. when i try this on a 1.3 machine , program A (with the global initialised to "42" and marked as volatile with no optimization - btw i am using Aztec C v5) prints some ptr value and the program waits for getchar(). program B - completely separate - is built once i know the ptr value. a forceful cast is performed and a dereference of that address. the value that is returned is 0. i cannot generate the assembly code because i cannot find the option to generate the asm through the CC binary. it used to be -T in previous versions, but this is not the case with v5 aztec and i cannot find the manual for that version.

[Samurai_Crow]

If you are trying to do message passing, there are routines in exec.library to automate the semaphore generation and use throughout the process. The message passing routines take full advantage of pointer passing by reference already. Just make sure you use ReplyMsg() as quickly as you can after reading the value in the memory window of the SendMsg() port. Otherwise it'll freeze the multitasking.

[Thomas Richter]

I'm sorry, I am not clear what is supposed to be attempted here. Given the simplicity of AmigaOs, every process has access to the data of every other process, all provided the address is known at which the data to be accessed is available. However, note that data under control of process A may change any time A likes to, and thus if B wants to read or modify such data, some synchronization mechanism is necessary. That could be message passing.

However, unlike others claim, not Replying to a message does not impact multitasking. This is unrelated to it. It is not like PutMsg() disabling multitasking and GetMsg() reenabling it. ReplyMsg() is just a matter of the communication protocol between two tasks which *typically* requires that if A sends a message to B, that then B returns the message once it is done with the data from A, but this is - again - a matter of convention of the communication between A and B and nothing the exec kernel enforces. For example, the communication of dos.library with its handlers never requires a ReplyMsg(). It is all PutMsg() back and forth (thus, a different protocol, but still message ping-pong).

[Samurai_Crow]

Thanks for clarifying.

[thomas]

Originally Posted by rjd324

the value that is returned is 0.

Not sure what you did wrong. These work for me:

#include <stdio.h>

int main (void)

{
int a = 42;

printf ("addr of a = %lx\n",&a);
printf ("value of a = %d\n",a);
getchar();

return (0);
}

#include <stdio.h>

int main (int argc, char **argv)

{
int *a;

if (argc != 2)
	{
	printf ("argument missing\n");
	return (20);
	}


sscanf (argv[1],"%lx",&a);

printf ("addr of a = %lx\n",a);
printf ("value of a = %d\n",*a);

return (0);
}

1> p1
addr of a = 402b9584
value of a = 42

2> p2 402b9584
addr of a = 402b9584
value of a = 42
2>

[rjd324]

Yes, it also works for me. I was running into the classic undefined behaviour of printf-ing a pointer format value without actually giving the address that I wanted to print, so I was not getting the correct address.

===

Now I ask about MMU. If an MMU does exist and it is tied to the CPU and always acts as a "filter" then are exceptions are being raised and just not handled by the OS or the specific software being run? I know about TR's MuLib - but the the AmigaOS does not use it. What would I have to do in order to catch the fact that program B was accessing memory from program A (even though it was only a READ).

EDIT: Though, something needs to presumably configure the MMU to begin with.

[Karlos]

Originally Posted by Thomas Richter

I'm sorry, I am not clear what is supposed to be attempted here. Given the simplicity of AmigaOs, every process has access to the data of every other process, all provided the address is known at which the data to be accessed is available. However, note that data under control of process A may change any time A likes to, and thus if B wants to read or modify such data, some synchronization mechanism is necessary. That could be message passing.

However, unlike others claim, not Replying to a message does not impact multitasking. This is unrelated to it. It is not like PutMsg() disabling multitasking and GetMsg() reenabling it. ReplyMsg() is just a matter of the communication protocol between two tasks which *typically* requires that if A sends a message to B, that then B returns the message once it is done with the data from A, but this is - again - a matter of convention of the communication between A and B and nothing the exec kernel enforces. For example, the communication of dos.library with its handlers never requires a ReplyMsg(). It is all PutMsg() back and forth (thus, a different protocol, but still message ping-pong).

That's interesting. A bit like UDP versus TCP, to use a crude network analogy?

[Thomas Richter]

Originally Posted by rjd324

Now I ask about MMU. If an MMU does exist and it is tied to the CPU and always acts as a "filter" then are exceptions are being raised and just not handled by the OS or the specific software being run?

They are handled by the MMULib, if it is present, and then forwarded to whatever program wants to listen. MuForce is one of those programs.

Originally Posted by rjd324

I know about TR's MuLib - but the the AmigaOS does not use it.

It is typically installed along with the operating system nowadays.

Originally Posted by rjd324

What would I have to do in order to catch the fact that program B was accessing memory from program A (even though it was only a READ).

The MMU would allow to make the read from A go to a different physical location than a read from B (and that would happen if the two involved tasks run in different MMUContexts).

[Thomas Richter]

Originally Posted by Karlos

That's interesting. A bit like UDP versus TCP, to use a crude network analogy?

Not really. The dos.library also expects its messages getting replied, it just does not use ReplyMsg(), but PutMsg() to the original port. But, of course, one can also consider protocols where the message does not go back to the sender, I just don't recall where in AmigaOs such one-way communication would be used.

[rjd324]

Originally Posted by Thomas Richter

The MMU would allow to make the read from A go to a different physical location than a read from B (and that would happen if the two involved tasks run in different MMUContexts).

Thanks.

So read accesses never trigger a violation?
And write if it tried to write to that location rather than just read?

---

Does MuLib interrogate allocated hunks and figure out what a task's hunks are allowed to access? Unlike elf I do not think there is a concept of read only sections...

[Thomas Richter]

Originally Posted by rjd324

So read accesses never trigger a violation?

No. That depends on how the MMU is configured. You can configure a page (usually 1K or 4K) either as invalid (so both read and write accesses will trigger an exception) or swapped (also, read and write accesses will trigger an exception, though a different one), or write-protected (only write accesses will trigger an exception) or write-protected (writes will be ignored).

Originally Posted by rjd324

S

Does MuLib interrogate allocated hunks and figure out what a task's hunks are allowed to access? Unlike elf I do not think there is a concept of read only sections...

The library is just a foundation to control the MMU. There are other tools around it. There is MuGuardianAngel, which will configure the MMU such that any read or write to memory regions that are not allocated will trigger an exception, and there is MuLink, which prepares executable programs such that any attempt to write to a loaded "code" hunk is ignored, and there is MuProtectModules, which will write protect all code loaded through LoadModules.


Thus, the library is only the "lower level" or the foundation of other tools that use it to implement multiple functionalities.