Hi Iain,
> I wil try what has been suggested - but I guess that also applying the patch
> series to current trunk ought to work?
Well, there is an additional patch needed before the patch series (attached
here).
>
> > When you then go to
> >
> > libgfortran/caf/shmem/shared_memory.c
> >
> > and search for "mmap" you'll see what I do. Yes, I know and tried
> > MMAP_FIXED. It works for some cases and in other corrupts the address space
> > on MacOS. (Works fine on Linux all the time). The base address is "send"
> > from the supervisor process to its workers (called images in Fortran) using
> > an environment variable. At the moment I am using the "proposal" method.
> > I.e., I give MacOS the base address where I want that shared memory segment
> > and just specify MMAP_SHARED.
>
> You might need to “propose” an address that is in a range that is not subject
> to other uses (i.e. especially that other uses could have ALSR applied which
> would mean that you’d see a random unavailablity). The sanitizers and the
> PCH code both need to take this into account.
Well, but it is shared(!) between processes. I would be fine with having the
shared memory segment on different addresses in different processes, but then
mutexes and condition variables do not function properly on macos anymore.
>
> > On Linux, I am done. I get the shared memory always on the desired address.
> >
>
> Well - I’d assume that on Linux editions with PIE executables and ASLR enabled
> you’d have to make similar considerations? (I am not so familiar with these
> facilities on Linux).
I have never ran into this. And I am on a recent kernel 6.16.something and the
randomize_va_space flag shows 2, which to what a quick search means, that ASLR
is enabled. Furthermore I am requesting the OS to hand me a shared memory
segment. I use shm_open and all the good stuff to let the OS know, that I am
really intending to share the memory between processes. Therefore I do see no
reason to have ASLR or what it is called on MacOS to interfere. But odd things
happen.
> > On MacOS the address is sometimes accepted on the first try, and sometimes
> > needs several thousand tries to be accepted. But finally MacOS accepts it.
> > This is so indeterministic to me.
>
> I expect that is totally intentional :) .. if you have an address in a range
> that conflicts with ALSR.
I imagine, I do get this only when the OS has put a segment of the program's
text/code into the space I now like the shared segment to be, but I haven't
found a way to tell the OS directly after the fork() to reserve the space. Then
after the execve of the same executable, the address space would be free, or
adviced or whatever. Do you have any idea how to accomplish that?
> >
> > I am really curious what I am doing wrong for MacOS being so exceptional.
>
> it’s plausibly not only the OS - but also the default conditions that apply
> on the OS - for macOS: PIE and ASLR are defaults (and on Arm64 macOS mandated
> by security policy). That might not be the situation on the Linux
> distribution you are using (IDK, just speculating).
Mhhh, may be the different OSes just do it differently. I am quite positive
that Linux uses ASLR and my fortran programs all are position independent. I
added -fPIE to a compile run and the resulting executable did not change to a
compile without it.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From a51cbe42d2c143e9dbe92b22ecb85a3a910c7baf Mon Sep 17 00:00:00 2001
From: Andre Vehreschild <[email protected]>
Date: Fri, 4 Jul 2025 11:26:46 +0200
Subject: [PATCH 01/11] Fortran: Evaluate all functions on the source image.
Formerly pure elemental functions were evaluated in the caf_accessor.
This had so many dependencies that there was no benefit. Evaluate
every function on the calling side now, which has the benefit, that
only one temporary has to be created instead of argument many.
gcc/fortran/ChangeLog:
* coarray.cc (check_add_new_component): Evaluate all functions
on the source image.
* trans-decl.cc (gfc_build_builtin_function_decls): The only
argument of team_number() is of type void* in the library ABI.
---
gcc/fortran/coarray.cc | 16 +++-------------
gcc/fortran/trans-decl.cc | 7 +++----
2 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/gcc/fortran/coarray.cc b/gcc/fortran/coarray.cc
index ef8fd4e42d0..07e4f91d2d5 100644
--- a/gcc/fortran/coarray.cc
+++ b/gcc/fortran/coarray.cc
@@ -696,21 +696,11 @@ check_add_new_component (gfc_symbol *type, gfc_expr *e, gfc_symbol *add_data)
check_add_new_component (type, actual->expr, add_data);
break;
case EXPR_FUNCTION:
- if (!e->symtree->n.sym->attr.pure
- && !e->symtree->n.sym->attr.elemental
- && !(e->value.function.isym
- && (e->value.function.isym->pure
- || e->value.function.isym->elemental)))
- /* Treat non-pure/non-elemental functions. */
- check_add_new_comp_handle_array (e, type, add_data);
- else
- for (gfc_actual_arglist *actual = e->value.function.actual; actual;
- actual = actual->next)
- check_add_new_component (type, actual->expr, add_data);
+ check_add_new_comp_handle_array (e, type, add_data);
break;
case EXPR_VARIABLE:
- check_add_new_comp_handle_array (e, type, add_data);
- break;
+ check_add_new_comp_handle_array (e, type, add_data);
+ break;
case EXPR_ARRAY:
case EXPR_PPC:
case EXPR_STRUCTURE:
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index b077cee86a3..50cb1f7831b 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -4237,10 +4237,9 @@ gfc_build_builtin_function_decls (void)
get_identifier (PREFIX ("caf_sync_team")), ". r w w w ", void_type_node,
4, pvoid_type_node, pint_type, pchar_type_node, size_type_node);
- gfor_fndecl_caf_team_number
- = gfc_build_library_function_decl_with_spec (
- get_identifier (PREFIX("caf_team_number")), ". r ",
- integer_type_node, 1, integer_type_node);
+ gfor_fndecl_caf_team_number = gfc_build_library_function_decl_with_spec (
+ get_identifier (PREFIX ("caf_team_number")), ". r ", integer_type_node,
+ 1, pvoid_type_node);
gfor_fndecl_caf_image_status = gfc_build_library_function_decl_with_spec (
get_identifier (PREFIX ("caf_image_status")), ". r r ",
--
2.51.0
