| Message ID | 20230319151017.531737-14-bugaevc@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | The rest of the x86_64-gnu port | expand |
Hello, Sergey Bugaev, le dim. 19 mars 2023 18:09:56 +0300, a ecrit: > While we could/should implement MAP_32BIT for the Hurd port by setting > all the high bits of mask in a vm_map () call, neither MAP_32BIT nor > glibc.cpu.prefer_map_32bit_exec exist on the Hurd as of now. Compile > this code out to fix build failures. Rather use defined(MAP_32BIT)? That way it will nicely work for BSD ports as well, and when hurd eventually supports MAP_32BIT. > Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> > --- > sysdeps/x86/cpu-features.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sysdeps/x86/cpu-features.c b/sysdeps/x86/cpu-features.c > index 822688e2..78631d7a 100644 > --- a/sysdeps/x86/cpu-features.c > +++ b/sysdeps/x86/cpu-features.c > @@ -27,7 +27,7 @@ > extern void TUNABLE_CALLBACK (set_hwcaps) (tunable_val_t *) > attribute_hidden; > > -# ifdef __LP64__ > +# if defined (__LP64__) && defined (__linux__) > static void > TUNABLE_CALLBACK (set_prefer_map_32bit_exec) (tunable_val_t *valp) > { > @@ -715,7 +715,7 @@ no_cpuid: > #if HAVE_TUNABLES > TUNABLE_GET (hwcaps, tunable_val_t *, TUNABLE_CALLBACK (set_hwcaps)); > > -# ifdef __LP64__ > +# if defined (__LP64__) && defined (__linux__) > TUNABLE_GET (prefer_map_32bit_exec, tunable_val_t *, > TUNABLE_CALLBACK (set_prefer_map_32bit_exec)); > # endif > -- > 2.39.2 >
On Mon, Apr 3, 2023 at 2:09 AM Samuel Thibault <samuel.thibault@gnu.org> wrote: > Sergey Bugaev, le dim. 19 mars 2023 18:09:56 +0300, a ecrit: > > While we could/should implement MAP_32BIT for the Hurd port by setting > > all the high bits of mask in a vm_map () call, neither MAP_32BIT nor > > glibc.cpu.prefer_map_32bit_exec exist on the Hurd as of now. Compile > > this code out to fix build failures. > > Rather use defined(MAP_32BIT)? That way it will nicely work for BSD > ports as well, and when hurd eventually supports MAP_32BIT. Not really. What breaks compilation here is not missing MAP_32BIT, but rather the undefined set_prefer_map_32bit_exec tunable. It is defined declaratively in sysdeps/unix/sysv/linux/x86_64/64/dl-tunables.list (see commit 317f1c0a8a71a862b1e600ff5386b08e02cf4b95); so as-is, it really is x86_64 Linux specific. Is there some way to check if a specific tunable is defined, like #if HAVE_TUNABLE (prefer_map_32bit_exec)? AFAICS the generated dl-tunable-list.h defines the C enum members, but not any checkable preprocessor macros. Alternatively: maybe this part of cpu-features.c should be moved into sysdeps/unix/sysv/linux/x86_64/64/cpu-features.c and #include_next the common cpu-features.c? Sergey
On Mon, Apr 3, 2023 at 3:10 AM Sergey Bugaev <bugaevc@gmail.com> wrote: > > On Mon, Apr 3, 2023 at 2:09 AM Samuel Thibault <samuel.thibault@gnu.org> wrote: > > Sergey Bugaev, le dim. 19 mars 2023 18:09:56 +0300, a ecrit: > > > While we could/should implement MAP_32BIT for the Hurd port by setting > > > all the high bits of mask in a vm_map () call, neither MAP_32BIT nor > > > glibc.cpu.prefer_map_32bit_exec exist on the Hurd as of now. Compile > > > this code out to fix build failures. > > > > Rather use defined(MAP_32BIT)? That way it will nicely work for BSD > > ports as well, and when hurd eventually supports MAP_32BIT. > > Not really. What breaks compilation here is not missing MAP_32BIT, but > rather the undefined set_prefer_map_32bit_exec tunable. It is defined > declaratively in sysdeps/unix/sysv/linux/x86_64/64/dl-tunables.list > (see commit 317f1c0a8a71a862b1e600ff5386b08e02cf4b95); so as-is, it > really is x86_64 Linux specific. > > Is there some way to check if a specific tunable is defined, like #if > HAVE_TUNABLE (prefer_map_32bit_exec)? AFAICS the generated > dl-tunable-list.h defines the C enum members, but not any checkable > preprocessor macros. > > Alternatively: maybe this part of cpu-features.c should be moved into > sysdeps/unix/sysv/linux/x86_64/64/cpu-features.c and #include_next the > common cpu-features.c? > Or something like this.
On Mon, Apr 3, 2023 at 10:02 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> Or something like this.
Or like that, yeah!
On a second thought, I actually like Samuel's idea (ifdef MAP_32BIT):
instead of only building this piece of code when the tunable *is*
defined, we'd build it when the tunable *should be* defined (that is,
when your port has MAP_32BIT). And if you get build errors, that is
your not-so-gentle reminder to go and define the tunable for your
port.
What do you think?
Sergey
diff --git a/sysdeps/x86/cpu-features.c b/sysdeps/x86/cpu-features.c index 822688e2..78631d7a 100644 --- a/sysdeps/x86/cpu-features.c +++ b/sysdeps/x86/cpu-features.c @@ -27,7 +27,7 @@ extern void TUNABLE_CALLBACK (set_hwcaps) (tunable_val_t *) attribute_hidden; -# ifdef __LP64__ +# if defined (__LP64__) && defined (__linux__) static void TUNABLE_CALLBACK (set_prefer_map_32bit_exec) (tunable_val_t *valp) { @@ -715,7 +715,7 @@ no_cpuid: #if HAVE_TUNABLES TUNABLE_GET (hwcaps, tunable_val_t *, TUNABLE_CALLBACK (set_hwcaps)); -# ifdef __LP64__ +# if defined (__LP64__) && defined (__linux__) TUNABLE_GET (prefer_map_32bit_exec, tunable_val_t *, TUNABLE_CALLBACK (set_prefer_map_32bit_exec)); # endif
While we could/should implement MAP_32BIT for the Hurd port by setting all the high bits of mask in a vm_map () call, neither MAP_32BIT nor glibc.cpu.prefer_map_32bit_exec exist on the Hurd as of now. Compile this code out to fix build failures. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> --- sysdeps/x86/cpu-features.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)