https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
Bug ID: 111165
Summary: [13 regression] builtin strchr miscompiles on
Debian/x32 with dietlibc
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tg at mirbsd dot org
Target Milestone: ---
Debian bug reported as:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050589
I’ve got no idea how to quickly reduce that down, but perhaps anyone has got an
idea.
In an x32 (amd64ilp32) environment, with dietlibc/x32 as packaged in Debian (no
shared libraries), building mksh and then running the command 'x=q; x=${ echo
a; typeset e=2; return 3; echo x$e;}; echo .$x.' with the resulting binary
results in the output “..” instead of “.a.”.
This does not occur when either
- giving -fno-builtin-strchr
- wrapping strchr as outlined below
(which makes me think of register corruption occurring here)
- using amd64 instead of x32 (amd64ilp32)
- using glibc, klibc or musl (though klibc/x32 is in reality amd64 so it can be
discounted)
- using GCC 12.3.0
The codepath is a bit convoluted, setjmp/longjmp are involved.
Wrapping strchr by adding…
char *ucstrchr(char *, int);
const char *cstrchr(const char *, int);
#undef strchr
#define strchr poisoned_strchr
… to a .h file that’s globally included, and adding the following…
#undef strchr
char *ucstrchr(char *s, int c)
{
return (strchr(s, c));
}
const char *cstrchr(const char *s, int c)
{
return (strchr(s, c));
}
… to one .c file *also* works around the bug, for some reason. (mksh is built
with -fno-lto because of other GCC issues I filed regarding this.)
IIRC the builtins are hidden within the LISPy machine definitions or something;
I’m afraid at this point this is beyond my own ability to reduce down, but do
ask me (ideally via eMail to both <1050589-submit...@bugs.debian.org> and
<1050...@bugs.debian.org> (to keep the bug in Cc), but
@mirabi...@toot.mirbsd.org on Fediverse is fine too) if you need any further
details.
(All testing has been done with GCC and dietlibc as packaged in Debian;
especially the latter has quite the deviation from upstream, but I have looked
at diffs and logs and don’t think those are relevant here.)
