John David Anglin <dave.anglin@xxxxxxxx> writes:
> On 2023-11-17 9:55 a.m., Helge Deller wrote:
>> On 11/11/23 00:02, John David Anglin wrote:
>>> On 2023-11-10 5:16 p.m., Sam James wrote:
>>>> John David Anglin <dave.anglin@xxxxxxxx> writes:
>>>>
>>>>> On 2023-11-10 4:32 p.m., Sam James wrote:
>>>>>> John David Anglin <dave.anglin@xxxxxxxx> writes:
>>>>>>
>>>>>>> On 2023-11-10 3:38 p.m., Helge Deller wrote:
>>>>>>>> On 11/10/23 21:12, John David Anglin wrote:
>>>>>>>>> On 2023-11-10 3:01 p.m., Helge Deller wrote:
>>>>>>>>>>>> On HPPA, we still need executable stacks, so this option doesn't work
>>>>>>>>>>>> and leads to a segfault on boot.
>>>>>>>>>> For kernel we don't need it any longer.
>>>>>>>>>> But there might be dependencies on glibc version and/or combination.
>>>>>>>>>> So, I've currently lost overview if we still need executable stacks...
>>>>>>>>> FWIW, I recently changed gcc-14 to enable GNU stack notes and fixed a bug in the
>>>>>>>>> 32-bit PA 2.0 trampoline template. All execute stack tests in glibc now pass with gcc-14.
>>>>>>>> Yes, I saw your commits.
>>>>>>>> So, any code compiled with >= gcc-14 should be fine with non-writeable stacks?
>>>>>>> Not exactly. An executable stack is still needed for nested functions. They are still called
>>>>>>> via a stack trampoline. The GNU stack note indicates whether an object needs an executable
>>>>>>> stack or not. These notes are collected by linker. The glibc loader determines whether to setup
>>>>>>> an executable stack or not.
>>>>>>>> It would be easier if it would be a glibc dependency (for distribution maintainers)...
>>>>>>> I'm not aware of any glibc dependency...
>>>>>>>
>>>>>>> I think once gcc-14 becomes the default compiler, we will have to enable GNU stack notes in
>>>>>>> previous gcc versions. We will still have executable stacks until everything is rebuilt.
>>>>>> We will need to update that default in Binutils too, I think. That
>>>>>> configure arg is working OK for me, but I did not try systemd yet.
>>>>> Currently, there are no architecture dependencies in the ld --enable-warn-execstack and --enable-default-execstack
>>>>> configure options. The -z execstack and -z noexecstack ld options can override the GNU notes, or lack thereof. We
>>>>> may have to fix some assembly code. Maybe binutils should be built with --enable-warn-execstack once we switch
>>>>> to gcc-14. I don't think we want --enable-default-execstack after switching to gcc-14.
>>>> Are you sure? I just did some more digging now...
>>>> * It looks like targets can set elf_backend_default_execstack in
>>>> bfd/elf-*.c to override the default, see e.g. 81cd0a49c9e5f28c0fec391e449ea3272077c432 for cris.
>>>> * See acd65fa610df09a0954b8fecdadf546215263c5d where HPPA's default got changed.
>>>> * ld/configure.tgt still has some suppression for HPPA's default for
>>>> warnings.
>>>>
>>>> I think we may need to, in due course, set elf_backend_default_execstack
>>>> in bfd/elf32-hppa.c, and then drop those bits in ld/configure.tgt too?
>>> You are right about both. We have in ld/configure.tgt:
>>> if test "${ac_default_ld_warn_execstack}" = 2; then
>>> case "${targ}" in
>>> # The HPPA port needs to support older kernels that
>>> # use executable stacks for signals and syscalls.
>>> # Many MIPS targets use executable stacks.
>>> hppa*-*-* | \
>>> mips*-*-*)
>>> ac_default_ld_warn_execstack=0
>>> ;;
>>> *)
>>> ;;
>>> esac
>>> fi
>>>
>>> We also may need:
>>> #define elf_backend_default_execstack 0
>>> in elf32-hppa.c at some point.
>>>
>>> I think when GNU stack notes are present, they determine whether the stack in an executable will be executable or not.
>>> But I could be wrong 🙁
>>>
>>> I'll try building binutils with gcc-14.
>>
>> Did it worked?
> Build succeeds but there are about a dozen fails in ld testsuite which need investigation.
>
> I got waylaid:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>
> Jeff thinks the patch which I committed to gcc trunk to improve handling of REG+D addresses
> will fail: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637018.html
>
> There have been many problems with this over the years but I would prefer to see what breaks
> with current implementation. It fixes python build and we no longer need to disable inlining of
> small functions. A lot of water has passed under the bridge since Jeff worked on the issue.
OK, I'll go ahead with testing then and let you know if there's any
issue. I didn't want to start if it was going to be reverted shortly or
something.
Am keen on seeing if I notice any differences with Python build time and
runtime performance too...
>>
>> Btw, I added a small section about executable stacks in the TODO
>> section of the wiki:
>> https://parisc.wiki.kernel.org/index.php/TODO#executable_stack
Nice, thanks!
>
> Dave
