On 25/11/16 18:50, Paul Eggert wrote:
> Pádraig Brady wrote:
>> for UBSAN we should probably build with
>> _STRING_ARCH_unaligned defined globally
>> to avoid warning for the cases we already handle.
> 
> Yes. Translating this for non-experts: the problem here is a bug in the 
> bug-finding procedure, not a bug in GNU coreutils or in Gnulib.

Sorry I was a bit terse. coreutils/gnulib should currently be compiled with
  -D_STRING_ARCH_unaligned=0 -D_STRING_INLINE_unaligned=0
when using UBSAN, to use only alignment portable code.
Methods for avoiding false UBSAN warnings automatically are discussed below...

> Recent glibc (since 2016-02-18) does not define _STRING_ARCH_unaligned, which 
> means that this code in gnulib md5.c etc. is no longer exercised on recent 
> platforms.

Oh interesting. I see details in:
https://sourceware.org/bugzilla/show_bug.cgi?id=19462
There it suggests that _STRING_ARCH_unaligned is now internal
to glibc and _STRING_INLINE_unaligned is the newer stable equivalent.
Attached patch to do this for coreutils is attached.

> So in some sense the originally-reported bug is already fixed (via an 
> unexpected glibc change), though this does mean Gnulib md5 etc. is now slower on 
> x86-64 etc., which is a performance bug on newer platforms. If we fix the 
> performance bug I suppose we'll start getting false alarms from UBSAN again.

We can explicitly avoid the UBSAN warnings with something like:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.23-80-g5760532
which might be acceptable given the few places it matters.
That's a bit of a big hammer though, defining away all of UBSAN for those routines.

Alternatively we might define the non-portable faster path away,
if we could detect we where compiling in UBSAN mode.
That's easy enough for -fsanitize=address, though it doesn't
look like there is currently a way to detect -fsanitize=undefined?
http://stackoverflow.com/q/39371798/4421

Another approach would be to support ../configure --with-asan --with-ubsan
which would define things appropriately.

cheers,
Pádraig.