On Thu, Feb 13, 2025 at 01:47:26PM +0100, Jens Remus wrote:
> On 13.02.2025 10:41, Thomas Weißschuh wrote:
> > Commit 14be4e6f3522 ("selftests: vDSO: fix ELF hash table entry size for s390x")
> > changed the type of the ELF hash table entries to 64bit on s390x.
> > However the *GNU* hash tables entries are always 32bit.
> > The "bucket" pointer is shared between both hash algorithms.
> > On s390x the GNU algorithm assigns and dereferences this 64bit pointer as a
> > 32bit pointer, leading to compiler warnings and runtime crashes.
>
> Nit: The compiler complains about assignments between incompatible pointer
> types (e.g. "Elf64_Xword *" and "Elf64_Word *"). The size of the pointers
> themselves is not different, as it is usually defined by the architecture
> regardless of the type of data pointed at. The real issue is that the
> 32-bit GNU hash entries are erroneously accessed as if they were 64-bit
> entries via "bucket" on s390x.
Well, yes of course. It should have been
"pointer to 64bit as a pointer to 32bit"
I'll wait for some more feedback and roll it into v2.
Or I'd be happy if whoever picks it up fixes the wording.
> > Introduce a new dedicated "gnu_bucket" pointer which is used by the GNU hash.
> >
> > Fixes: e0746bde6f82 ("selftests/vDSO: support DT_GNU_HASH")
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxxxx>
> > ---
> > tools/testing/selftests/vDSO/parse_vdso.c | 10 +++++-----
> > 1 file changed, 5 insertions(+), 5 deletions(-)
>
> Reviewed-by: Jens Remus <jremus@xxxxxxxxxxxxx>
>
> Thanks for taking care!
You're welcome.
To be honest I'm a bit concerned that nobody noticed this before.
The test programs segfault instantly.
