Bug 1450992

Created attachment 1279010 [details]
reproducer file taken from the GDB testsuite

That is a longterm problem of GDB that its support of instruction sets for recording is lacking behind new Intel processors.  glibc does use all the new instructions for minor optimizations of its functions like memcpy(3).

I guess detection of the new instructions by glibc may depend on Linux kernel version but I have no technical information about that.

It is up to someone whether GDB support of all latest instruction sets for recording is a supported feature or not.  It is not so difficult to extend/fix it, one needs to write down the opcodes coding of all the new instructions.

Created attachment 1321885 [details]
libstring.c

gcc -o src/libstring.so src/libstring.c -Wall -g -shared -fPIC -O2
gdb -ex 'set env LD_BIND_NOW=1' -ex "set env LD_PRELOAD=$HOME/src/libstring.so" -ex start -ex record -ex c --args PROG ARGS

But then it will stop anyway for example at:
Process record and replay target doesn't support syscall number 318
30	  return SYSCALL_CANCEL (getrandom, buffer, length, flags);
https://sourceware.org/bugzilla/show_bug.cgi?id=22081

*** Bug 1136403 has been marked as a duplicate of this bug. ***

This seems to be a problem with current libc.so.6 in Fedora 31 with gdb 8.3 with basic string functions

(gdb) record
(gdb) c
Continuing.
Process record does not support instruction 0xc5 at address 0x7ffff7167849.
Process record: failed to record execution log.

Program stopped.
0x00007ffff7167849 in __strlen_avx2 () from /lib64/libc.so.6
(gdb)

Is there any workaround for this as an end user?

(In reply to Ellie from comment #12)
> This seems to be a problem with current libc.so.6 in Fedora 31 with gdb 8.3
> with basic string functions
> 
> (gdb) record
> (gdb) c
> Continuing.
> Process record does not support instruction 0xc5 at address 0x7ffff7167849.
> Process record: failed to record execution log.
> 
> Program stopped.
> 0x00007ffff7167849 in __strlen_avx2 () from /lib64/libc.so.6
> (gdb)
> 
> Is there any workaround for this as an end user?

Unfortunately not (or at least not that I'm aware of).  This happens because GDB doesn't have support for reverse-debugging this instruction (and some others, FWIW).  If you want to use reverse debugging and your binary contains this instruction, you will not be able to.

I am seeing this even with -O0 though, so is there even a way to avoid this? The backtrace makes it look like the libc.so.6 system-wide binary is the culprit. If it is, can a gdb end user even realistically avoid running into this issue? It feels to me like gdb's reverse debugging as packaged is currently fundamentally incompatible with how Fedora's own base system is shipped. That seems like a problem if that is the case

Created attachment 1667028 [details]
glibc nomulti.patch

(In reply to Ellie from comment #14)
> If it is, can a gdb end user even realistically avoid running into this issue?

I see in Comment 5 I already coded some workaround.

Besides that you can build your own glibc without the multi-arch optimization and LD_PRELOAD it.  You also need LD_BIND_NOW as ld.so also has some multiarch optimization of its own.

$ echo -e '#include <string.h>\nint main(int argc,char **argv) {\nsize_t l=strlen(argv[0]);\nreturn l;}' >strlen.c;gcc -Wall -g -o strlen strlen.c;gdb -q ./strlen -ex start -ex record -ex n
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd028) at strlen.c:3
3	size_t l=strlen(argv[0]);
Process record does not support instruction 0xfae64 at address 0x7ffff7fe86bc.
Process record: failed to record execution log.
Program stopped.
_dl_runtime_resolve_xsave () at ../sysdeps/x86_64/dl-trampoline.h:117
(gdb) _

vs.

$ echo -e '#include <string.h>\nint main(int argc,char **argv) {\nsize_t l=strlen(argv[0]);\nreturn l;}' >strlen.c;gcc -Wall -g -o strlen strlen.c;gdb -q ./strlen -ex 'set env LD_BIND_NOW=1' -ex start -ex record -ex n
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd008) at strlen.c:3
3	size_t l=strlen(argv[0]);
Process record does not support instruction 0xc5 at address 0x7ffff7f23849.
Process record: failed to record execution log.
Program stopped.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:57
(gdb) _

vs.

$ echo -e '#include <string.h>\nint main(int argc,char **argv) {\nsize_t l=strlen(argv[0]);\nreturn l;}' >strlen.c;gcc -Wall -g -o strlen strlen.c;gdb -q ./strlen -ex 'set env LD_BIND_NOW=1' -ex 'set env LD_LIBRARY_PATH=/home/jkratoch/redhat/fedora/glibc/f31/BUILDROOT/glibc-2.30-10nomulti.fc31.x86_64/lib64' -ex start -ex record -ex n
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffcfc8) at strlen.c:3
3	size_t l=strlen(argv[0]);
4	return l;}
(gdb) _

Well I get that some experts can work around this, but this doesn't seem super achievable for regular users like me.

The libstring.so workaround looks nice and quick, but you're losing me with the other variants and I think most others will also be lost. As a result, there's a practical accessibility problem for this feature right now which is a bit of a shame. I often just do printf debugging instead of gdb, and this would be one of THE features to get me to use it way more if it worked

An idea: would it be possible prepackage a separate libc compatible with this maybe? libc-unoptimized.so.6, or such. The dnf package could then be described somewhere (and that mention ideally linked from the gdb error itself) for quick install & use

TBH fixing this bug is not a big deal to consider some packaging of workarounds.  It is just so boring to follow the instruction encodings tables/documentation nobody wants to do that.

Moving to DTS.

Correctly moving this bug to RHEL8.

Closing this bug. Perhaps when upstream addresses it, we can reopen this RHEL bug.