Upgrade GA CI Linux VM's to Ubuntu 18.04 for rseq testing and other features

We're using the old Ubuntu 16.04 in our GA CI suite and it's too old to support rseq (4.18 is needed). Xref https://github.com/DynamoRIO/dynamorio/pull/4929#issuecomment-864151571, https://github.com/DynamoRIO/dynamorio/pull/4929#issuecomment-864160943

This issue covers upgrading to at least 18.04. IIRC we tried in the past and hit flaky tests and other problems? We may hit things like #4830.

added Component-Tests label

mentioned in merge request !4929 (merged)

Looks like we'll be forced to upgrade soon:

The ubuntu-16.04 environment is deprecated and will be removed on September 20, 2021. Migrate to ubuntu-latest instead. For more details see https://github.com/actions/virtual-environments/issues/32

assigned to @abhinav92003

mentioned in merge request !4981 (closed)

We decided that we should probably go straight to 20.04 rather than 18.04.

mentioned in merge request !5072 (merged)

Based on https://github.com/actions/virtual-environments/issues/3287#issue-870886726, there will be two short brownout periods where Ubuntu 16.04 builds will fail.

The brownouts are scheduled for the following dates and times:

September 6, 2021 5:00pm UTC – 10:00pm UTC
September 14, 2021 5:00pm UTC – 10:00pm UTC

mentioned in issue #5079

mentioned in issue #2417

The api.detach_state 64-bit failure:

<Detaching from application /home/bruening/dr/git/build_x64_dbg_tests/suite/tests/bin/api.detach_state (59264)>

Thread 2 "api.detach_stat" received signal SIGUSR2, User defined signal 2.
<Detaching from process, entering final cleanup>

Thread 2 "api.detach_stat" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7913700 (LWP 59268)]
0x00007ffff79adf4d in _IO_str_init_static_internal (sf=sf@entry=0x7ffff7912928, ptr=ptr@entry=0x7ffff7912bb8 "", size=size@entry=15, pstart=pstart@entry=0x7ffff7912bb8 "") at strops.c:41
41	strops.c: No such file or directory.
(gdb) x/10i $pc
=> 0x7ffff79adf4d <_IO_str_init_static_internal+61>:	movaps %xmm0,(%rsp)
   0x7ffff79adf51 <_IO_str_init_static_internal+65>:	callq  0x7ffff79abfa0 <__GI__IO_setb>
   0x7ffff79adf56 <_IO_str_init_static_internal+70>:	movdqa (%rsp),%xmm0
   0x7ffff79adf5b <_IO_str_init_static_internal+75>:	mov    %r13,0x8(%rbp)
   0x7ffff79adf5f <_IO_str_init_static_internal+79>:	movups %xmm0,0x18(%rbp)
   0x7ffff79adf63 <_IO_str_init_static_internal+83>:	test   %r12,%r12
   0x7ffff79adf66 <_IO_str_init_static_internal+86>:	je     0x7ffff79adfb0 <_IO_str_init_static_internal+160>
   0x7ffff79adf68 <_IO_str_init_static_internal+88>:	movq   %r12,%xmm0
   0x7ffff79adf6d <_IO_str_init_static_internal+93>:	movq   %rbx,%xmm1
   0x7ffff79adf72 <_IO_str_init_static_internal+98>:	mov    %r12,0x10(%rbp)
(gdb) info reg
rsp            0x7ffff79128d8      0x7ffff79128d8
(gdb) bt
#0  0x00007ffff79adf4d in _IO_str_init_static_internal (sf=sf@entry=0x7ffff7912928, ptr=ptr@entry=0x7ffff7912bb8 "", size=size@entry=15, pstart=pstart@entry=0x7ffff7912bb8 "") at strops.c:41
#1  0x00007ffff79a610a in __vsnprintf_internal (string=0x7ffff7912bb8 "", maxlen=<optimized out>, format=0x555555559236 "%s%d.%s", args=args@entry=0x7ffff7912aa8, mode_flags=mode_flags@entry=0)
    at vsnprintf.c:113
#2  0x00007ffff797bf76 in __GI___snprintf (s=<optimized out>, maxlen=<optimized out>, format=<optimized out>) at snprintf.c:31
#3  0x000055555555713b in check_simd_value (prefix=0x55555555926f "xmm", idx=0, suffix=0x55555555926c "lo", value=2559278670753769365, expect=2559278670753769365)
    at /home/bruening/dr/git/src/suite/tests/api/detach_state.c:239
#4  0x00005555555571f6 in check_gpr_vals (xsp=0x7ffff7912c18, selfmod=false) at /home/bruening/dr/git/src/suite/tests/api/detach_state.c:285
#5  0x0000555555557e8d in check_gprs_from_cache_spin () at suite/tests/detach_state.c_asm.asm:968

Looks like the test asm functions don't maintain 16-byte alignment on entry.

Also seeing this:

SYSLOG_WARNING: spurious rep/repne prefix @0x0000557833f6b9c0 (f3 0f 1e fa): 
  0x0000557833f6b9c0  f3 0f 1e fa          nop    %edx
  0x0000557833f6b9c4  55                   push   %rbp %rsp -> %rsp 0xfffffff8(%rsp)[8byte]
  0x0000557833f6b9c5  48 89 e5             mov    %rsp -> %rbp
  0x0000557833f6b9c8  48 83 ec 20          sub    $0x0000000000000020 %rsp -> %rsp
        wrote all 6 flags now!

=> #4040: endbr64.

mentioned in merge request !5093 (merged)

mentioned in issue #2243 (closed)

mentioned in merge request !5095 (merged)

mentioned in merge request !5097 (merged)

mentioned in merge request !5098 (merged)

mentioned in issue #4924 (closed)

mentioned in merge request !5099 (merged)

mentioned in merge request !5100 (merged)

mentioned in issue #5101 (closed)

mentioned in merge request !5102 (merged)

mentioned in merge request !5105 (merged)

For the drcpusim failures:

<Invalid Klamath instruction "nop" @ tool.cpuid+0x1190.  Aborting.>

It's not actually a nop: DR doesn't decode CET instructions yet (#4040):

bruening@ubuntu:~/dr/git/build_x86_dbg_tests$ objdump -d suite/tests/bin/tool.cpuid | grep -A 4 'main>:'
00001747 <main>:
    1747:	f3 0f 1e fb          	endbr32 
    174b:	8d 4c 24 04          	lea    0x4(%esp),%ecx

Compiling -march=pentium2 does not remove it which seems crazy. Compiling -fcf-protection=none does remove it.

Compiling -fcf-protection=none does remove it.

Actually it doesn't remove all of them: there are still some at _start and other places; have not yet found a way to remove those.

mentioned in merge request !5108 (merged)

mentioned in issue #5109

I split the drcpusim failures as #5109 since there seems to be no simple quick fix.

mentioned in merge request !5110 (merged)

The histogram failure:

T2391962   0xf3bcc954  e8 8c 01 00 00       call   $0xf3bccae5
T2391962     write 4 byte(s) @ 0xffb70adc
T2391962   0xf3bccae5  0f 18 1d 03 00 00 00 prefetcht2 0x03
T2391962 <entry type 5>
T2391962   0xf3bccaec  90                   nop
T2391962   0xf3bccaed  90                   nop
T2391962   0xf3bccaee  0f 0b                ud2a
T2391962   0xf3bccaf0  90                   nop
Trace invariant failure: Interruption marker mis-placed

It looks like a 64-bit sign extension problem:

  0xf3bcc954 call   $0xf3bccae5 %esp -> %esp 0xfffffffc(%esp)[4byte]
[drmemtrace]: Appended memref type 1 size 4 to 0xffb70adc
[drmemtrace]: Appending delayed branch for thread 1
[drmemtrace]: Appending 8 instrs in bb 0xf7f70ae5 in mod 1 +0x1ae5 = /home/bruening/dr/git/build_x86_dbg_tests/suite/tests/bin/drmemtrace.signal_invariants
  0xf3bccae5 prefetcht2 0x03[1byte]
[drmemtrace]: Checking whether reached signal/exception 0xf3bccaee vs cur fffffffff3bccae5(tls=0x5777f744 ver=4 vs 4)
[drmemtrace]: Filling in elided rip-rel addr with 0x3
[drmemtrace]: Appended memref type 5 size 1 to 0x3
[drmemtrace]: Checking whether reached signal/exception 0xf3bccaee vs cur fffffffff3bccae5(tls=0x5777f744 ver=4 vs 4)
  0xf3bccaec nop
[drmemtrace]: Checking whether reached signal/exception 0xf3bccaee vs cur fffffffff3bccaec(tls=0x5777f744 ver=4 vs 4)
  0xf3bccaed nop
[drmemtrace]: Checking whether reached signal/exception 0xf3bccaee vs cur fffffffff3bccaed(tls=0x5777f744 ver=4 vs 4)
  0xf3bccaee ud2a
[drmemtrace]: Checking whether reached signal/exception 0xf3bccaee vs cur fffffffff3bccaee(tls=0x5777f744 ver=4 vs 4)
  0xf3bccaf0 nop
[drmemtrace]: Checking whether reached signal/exception 0xf3bccaee vs cur fffffffff3bccaf0(tls=0x5777f744 ver=4 vs 4)
  0xf3bccaf1 nop
[drmemtrace]: Checking whether reached signal/exception 0xf3bccaee vs cur fffffffff3bccaf1(tls=0x5777f744 ver=4 vs 4)
  0xf3bccaf2 nop
[drmemtrace]: Checking whether reached signal/exception 0xf3bccaee vs cur fffffffff3bccaf2(tls=0x5777f744 ver=4 vs 4)
  0xf3bccaf3 ret    %esp (%esp)[4byte] -> %esp
[drmemtrace]: Checking whether reached signal/exception 0xf3bccaee vs cur fffffffff3bccaf3(tls=0x5777f744 ver=4 vs 4)
[drmemtrace]: Missing memref from predication, 0-iter repstr, filter, or reached end of memrefs output by scatter/gather seq (next type is 0xc2000000f3bccaee)
[drmemtrace]: Checking whether reached signal/exception 0xf3bccaee vs cur fffffffff3bccaf3(tls=0x5777f744 ver=4 vs 4)
[drmemtrace]: Appending delayed branch for thread 1
[drmemtrace]: Signal/exception between bbs
[drmemtrace]: Appended marker type 0 value 0xf3bccaee
[drmemtrace]: Thread 2391962 timestamp 0x002f2b08592984c8
[drmemtrace]: Appended marker type 3 value 0x2
[drmemtrace]: Appending 2 instrs in bb 0xf7f70ad9 in mod 1 +0x1ad9 = /home/bruening/dr/git/build_x86_dbg_tests/suite/tests/bin/drmemtrace.signal_invariants
  0xf3bccad9 prefetcht0 0x01[1byte]

So this cast of 32-bit app_pc ends up being sign-extended:

reinterpret_cast<uint64_t>(modvec_()[in_entry->pc.modidx].orig_seg_base)

mentioned in merge request !5111 (merged)

mentioned in merge request !5113 (closed)

mentioned in merge request !5114 (closed)

mentioned in merge request !5117 (merged)

mentioned in issue #5131 (closed)

mentioned in merge request !5132 (merged)

closed