[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64
From:       Ulrich Weigand via KDE Bugzilla <bugzilla_noreply () kde ! org>
Date:       2016-09-26 16:39:48
Message-ID: bug-369175-17878-2V9GGAAcP9 () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=369175

--- Comment #25 from Ulrich Weigand <uweigand@de.ibm.com> ---
(In reply to Julian Seward from comment #24)
> (In reply to Ulrich Weigand from comment #23)
> > However, adding calls to fnptr_to_fnentry at a high level likewise seems
> > wrong, since once you've done that, you've forgotten where the function
> > descriptor was and have no chance of then retrieving the correct TOC value
> > to load into r2 before the call.  And in fact, the crash in comment #7 seems
> > a typical example of what happens when calling a function without setting up
> > its TOC pointer correctly.
> 
> Ulrich, you're right.  Valgrind actually kludges this on ppc64be, by completely
> ignoring the TOC pointer question and not saving or restoring r2 across calls.
> I suspect that the reason this works is that Valgrind itself is compiled into a
> statically linked executable, and so there is only ever one required r2 value,
> which is set up at start time and stays the same for ever more.  Does that
> sound plausible?

I see.  For the "host" side (valgrind itself), I guess that's a valid approach,
as long as you make sure that there is indeed never any shared library involved
(not even via dlopen), and the main executable actually only uses a single TOC
(the linker in fact supports generating executables using multiple TOCs).  With
code generated by a current compiler (in particular using the medium memory
model), you'll probably always get single-TOC executables anyway, but if you
actually rely on that property, I guess it cannot hurt to make sure by passing
--no-multi-toc to the linker.

Of course on the "target" side (the program running under valgrind), you'll
have shared libraries and thus multiple TOCs, so if you inject code on that
side, you may need to consider reloading the emulated r2 at some point.  That
probably isn't an issue with the "helpers" discussed in this bug though.

Given that, simply doing the fnptr_to_fentry actually may just be the right
fix.

-- 
You are receiving this mail because:
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]