On 2025-03-19 09:45, Aurelien Jarno wrote: > So far my finding are quite limited. It seems the new GCC generates more > optimized code in general, and especially for the memmem() function, and > that changes the location of the memmove() function located just after in > the binary. Aligning it to 6 bits seems to fix the problem with -18 (it is > aligned to 5 bits), but strangely it is only aligned to 4 bits with -17... > Also padding it with the same number of nops at the beginning of the > function doesn't help, so this somehow excludes alignment issues of > functions located after it. Overall it seems that memmove() wrongly jumps to > memcpy() for cases it shouldn't, but I don't really see why and while > alignment would matter. > > I am puzzled by all of that I and don't really know how to debug that > further.
It could very well be that this is a bug in valgrind, from what you describe. My uninformed impression is that upstream support for armhf isn't great. I did once open an issue asking to support the latest (2018) Procedure Call Standard and received no replies, which makes me wonder if there's much upstream interest at all when it comes to 32bit arm: https://bugs.kde.org/show_bug.cgi?id=479699 On that topic, just as a sanity check I tried rebuilding libinsane without stack-clash-protection and still could reproduce #1100805. Here's my 2 cents: if there's no obvious compiler or C library change that may suggest a regression was introduced, just stop running valgrind in the libinsane autopkgtest on armhf and move on.
