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.weisssc...@linutronix.de>
> > ---
> >   tools/testing/selftests/vDSO/parse_vdso.c | 10 +++++-----
> >   1 file changed, 5 insertions(+), 5 deletions(-)
> 
> Reviewed-by: Jens Remus <jre...@linux.ibm.com>
> 
> 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.

Reply via email to