Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#54939 - [valgrind] sends 32-bit programs under test SIGILL

Attached to Project: Community Packages
Opened by David Phillips (phillid) - Thursday, 27 July 2017, 00:08 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Saturday, 27 January 2018, 18:59 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Jan Steffens (heftig)
Laurent Carlier (lordheavy)
Anatol Pomozov (anatolik)
Bartłomiej Piotrowski (Barthalion)
Levente Polyak (anthraxx)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:

Attempting to test a 32-bit program with valgrind from [multilib-testing] will result in valgrind giving the attached output. It complains about unhandled instruction bytes. When the program under test is a 64-bit program, valgrind appears to behave itself nicely.


Additional info:
* valgrind-multilib 3.13.0-2 from [multilib-testing]
* Program under test compiled with gcc-multilib 7.1.1-4


Steps to reproduce:

A simple, self-contained test case is to run `echo "int main(int argc, char* argv[]){}" | gcc -m32 -x c - && valgrind ./a.out`.

I have tested against valgrind-multilib valgrind-multilib 3.13.0-1 and gcc-multilib 7.1.1-4, and the issue is not present.
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Saturday, 27 January 2018, 18:59 GMT
Reason for closing:  Fixed
Comment by Jan Steffens (heftig) - Thursday, 27 July 2017, 04:14 GMT
Same thing happens with regular i686 valgrind.
Comment by Jan Steffens (heftig) - Thursday, 27 July 2017, 04:19 GMT
Hmm, should try rebuilding valgrind without -fno-plt.
Comment by David Phillips (phillid) - Thursday, 27 July 2017, 08:42 GMT
Rebuilt valgrind-multilib 3.13.0-2 from abs a modification to remove -fno-plt from CFLAGS and CXXFLAGS to no avail. Still exhibits the broken behaviour.
Comment by David Phillips (phillid) - Thursday, 27 July 2017, 08:52 GMT
Hmm, looking at the svn history for the package, it would seem that pkgrel 1 to 2 was just that; a pkgrel bump for a rebuild against different libraries. Perhaps the problem lies there, in those other libraries.
Comment by David Phillips (phillid) - Thursday, 27 July 2017, 10:41 GMT
I just rebuilt lib32-glibc without -fno-plt and rebuilt valgrind-multilib against that (not sure if necessary, but covered myself) and the issue has disappeared.

EDIT: I should clarify that I built valgrind-multilib with the -fno-plt flag included.
Comment by David Phillips (phillid) - Thursday, 24 August 2017, 07:48 GMT
Identical problem still exists in valgrind-3.13.0-3 with lib32-glibc-2.26-1 that are now in [multilib-testing]
Comment by Bartłomiej Piotrowski (Barthalion) - Saturday, 27 January 2018, 18:59 GMT
Seems to be working with current multilib-enabled toolchain. Closing.

Loading...