Bug 241562 - failing test case: lib.libexecinfo.backtrace_test.backtrace_fmt_basic
Summary: failing test case: lib.libexecinfo.backtrace_test.backtrace_fmt_basic
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: tests (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Conrad Meyer
URL: https://reviews.freebsd.org/D22252
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-29 04:16 UTC by Li-Wen Hsu
Modified: 2019-11-07 16:13 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Li-Wen Hsu freebsd_committer 2019-10-29 04:16:01 UTC
https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13054/testReport/lib.libexecinfo/backtrace_test/backtrace_fmt_basic/

stderr:

*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:95: strings[0] != "myfunc3" (??? != myfunc3)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:96: strings[1] != "myfunc2" (??? != myfunc2)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:99: strings[j] != "myfunc1" (??? != myfunc1)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:99: strings[j] != "myfunc1" (??? != myfunc1)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:99: strings[j] != "myfunc1" (??? != myfunc1)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:99: strings[j] != "myfunc1" (??? != myfunc1)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:99: strings[j] != "myfunc1" (??? != myfunc1)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:99: strings[j] != "myfunc1" (??? != myfunc1)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:99: strings[j] != "myfunc1" (??? != myfunc1)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:99: strings[j] != "myfunc1" (??? != myfunc1)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:99: strings[j] != "myfunc1" (??? != myfunc1)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:99: strings[j] != "myfunc1" (??? != myfunc1)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:99: strings[j] != "myfunc1" (??? != myfunc1)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:99: strings[j] != "myfunc1" (??? != myfunc1)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:107: strings[j] != frames[i].name (??? != myfunc)
*** Check failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:107: strings[j] != frames[i].name (??? != atfu_backtrace_fmt_basic_body)
Comment 1 commit-hook freebsd_committer 2019-10-29 04:29:21 UTC
A commit references this bug:

Author: lwhsu
Date: Tue Oct 29 04:28:24 UTC 2019
New revision: 354144
URL: https://svnweb.freebsd.org/changeset/base/354144

Log:
  Temporarily disable failing case in CI:

  - lib.libexecinfo.backtrace_test.backtrace_fmt_basic

  PR:		241562
  Sponsored by:	The FreeBSD Foundation

Changes:
  head/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c
Comment 2 Conrad Meyer freebsd_committer 2019-10-29 06:00:40 UTC
Thanks for the report and quick CI bypass, Li-Wen Hsu.  I'll investigate tomorrow.  Of course, the test passed locally (outside of Kyua sandbox).

It looks like the CI build is stripping test binaries more aggressively than on my machine; when I strip(1) the test binary, I can reproduce the failure.  I have WITH_DEBUG_FILES=1 in my /etc/src.conf, but I don't believe that's important here -- I think the install(1) step is where the test binary gets stripped (further).

Here's an extremely high-level sketch:
OBJDIR:
backtrace_test.full:  34k
backtrace_test:       23k
backtrace_test.debug: 19k

Somehow, test + test.debug is substantially larger than test.full (+8k).

Meanwhile, the installed binary is only 20k.  So 3kB more has been stripped from the version I tested.  It looks like that's .symtab and .strtab, so, I guess that's not too surprising.

(The full binary has additional .debug_{str,loc,abbrev,info,ranges,macinfo,line,aranges} sections that neither stripped version has.)  The "debug" setaside has duplicate .shstrtab, .SUNW_ctf, .symtab, and .strtab (the latter two are only duplicates of the OBJDIR program) sections that likely explain the extra 8k.

"myfunc{1,2,3}" are in .symtab only, and that gets stripped.

The test looks pretty fragile but relies on finding all of the myfuncs, plus some assumptions about how ATF tests are named.  So at least one thing it needs is those functions in a symbol table (.dynsym or unstripped .symtab).

Again, thanks for the report and quick workaround!
Comment 3 Li-Wen Hsu freebsd_committer 2019-10-29 07:04:09 UTC
Thanks very much for the quick analysis!  And yes, I believe people adding and enabling tests after fully tested.  Although there might still be some difference in the development environment and CI environment so some issues observed is sometimes unavoidable.  After all, serving as a "fair 3rd party" is also one of the reasons to keep an CI system.

The CI build is using the default options so I believe the installation of the test files inherit the global default that installs stripped binaries.  I also got report that this makes debugging harder so I think it's time to check how to change this behavior to install unstripped test files.
Comment 4 commit-hook freebsd_committer 2019-10-29 18:25:15 UTC
A commit references this bug:

Author: cem
Date: Tue Oct 29 18:24:37 UTC 2019
New revision: 354151
URL: https://svnweb.freebsd.org/changeset/base/354151

Log:
  libexecinfo test: Don't strip installed test

  It turns out that a test of backtrace symbol resolution and formatting
  requires symbols.  Another option mightt be building with -rdynamic instead,
  but this works for now.

  Re-enabled skipped CI test, as it should now pass.

  PR:		241562
  Submitted by:	lwhsu
  Reported by:	lwhsu
  X-MFC-With:	r354126, r354135, r354144

Changes:
  head/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c
  head/lib/libexecinfo/tests/Makefile
Comment 5 Conrad Meyer freebsd_committer 2019-10-29 18:26:04 UTC
Sure!  For now, unstrip this test.  -rdynamic + stripped might be marginally smaller and also be sufficient for this test, but I did not investigate that option.
Comment 7 Conrad Meyer freebsd_committer 2019-10-30 20:02:59 UTC
This one is a different failure where the backtrace mechanism just doesn't work on i386.  It'll take longer to investigate.
Comment 8 commit-hook freebsd_committer 2019-11-01 09:17:46 UTC
A commit references this bug:

Author: lwhsu
Date: Fri Nov  1 09:16:58 UTC 2019
New revision: 354238
URL: https://svnweb.freebsd.org/changeset/base/354238

Log:
  Temporarily skip lib.libexecinfo.backtrace_test.backtrace_fmt_basic on i386

  PR:		241562
  Sponsored by:	The FreeBSD Foundation

Changes:
  head/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c
Comment 9 Conrad Meyer freebsd_committer 2019-11-05 21:44:21 UTC
First interesting piece: .eh_frame metadata is substantially smaller on
the i386 build; it only has a single FDE/CIE block:

====================================================================
# llvm-dwarfdump90 --eh-frame ./libexecinfo/backtrace_test | less
./libexecinfo/backtrace_test:   file format ELF32-i386

.debug_frame contents:


.eh_frame contents:

00000000 00000014 ffffffff CIE
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 1
  Data alignment factor: -4
  Return address column: 8
  Augmentation data:     1B

  DW_CFA_def_cfa: reg4 +4
  DW_CFA_offset: reg8 -4

00000018 00000018 0000001c FDE cie=0000001c pc=00000544...0000055d
  DW_CFA_advance_loc: 3
  DW_CFA_def_cfa_offset: +4
  DW_CFA_advance_loc: 2
  DW_CFA_offset: reg5 -8
  DW_CFA_def_cfa_register: reg5

====================================================================

In contrast, there are 14 of these sections in the amd64 test.
Shockingly, we seem to have a framepointer in the generated i386 code,
so it's *possible* that the defaults (DW_CFA_{def_cfa,offset}) are sufficient
to unwind out of the myfunc3 frame.  In LLVM, reg4 is EBP and register 8 is
beyond the valid range.  In contrast, on amd64, def_cfa/offset use reg7/16,
which are RSP and (?)RIP.

But that may not be the issue, given myfunc3 has a framepointer.  Another
point of comparison is that libexecinfo.so.1 seems to have DWARF .eh_frame
section on amd64, but not i386 (this one is entirely absent, rather than
merely short).
Comment 10 Conrad Meyer freebsd_committer 2019-11-05 23:42:30 UTC
It seems that register 8 is intended to be EIP, which matches up nicely with
x86_64, except llvm-libunwind does not define a register 8/EIP.  Just (pseudo
register) -1/IP.

Additionally, llvm-libunwind saves/restores EIP from an offset corresponding
to register 10 (which also doesn't exist).  Comments in the register save
code suggest SS and EFLAGS might be registers 8 and 9, but they are not saved.


Enabling the debug APIs:

# export LIBUNWIND_PRINT_APIS=1
# export LIBUNWIND_PRINT_UNWINDING=1
# export LIBUNWIND_PRINT_DWARF=1

and running the test shows this:

libunwind: __unw_init_local(cursor=0xffbfd340, context=0xffbfd300)
parseInstructions(instructions=0x2061bbf4)
DW_CFA_def_cfa(reg=4, offset=4)
DW_CFA_offset(reg=8, offset=-4)
DW_CFA_nop
DW_CFA_nop
parseInstructions(instructions=0x2061bcb0)
DW_CFA_advance_loc: new offset=1
DW_CFA_def_cfa_offset(8)
DW_CFA_offset(reg=5, offset=-8)
DW_CFA_advance_loc: new offset=3
DW_CFA_def_cfa_register(5)
DW_CFA_advance_loc: new offset=15
DW_CFA_offset(reg=6, offset=-20)
DW_CFA_offset(reg=7, offset=-16)
DW_CFA_offset(reg=3, offset=-12)
DW_CFA_advance_loc2: new offset=298

libunwind: _Unwind_Backtrace(callback=0x20455110)
libunwind: __unw_step(cursor=0xffbfd340)
parseInstructions(instructions=0x2061bbf4)
DW_CFA_def_cfa(reg=4, offset=4)
DW_CFA_offset(reg=8, offset=-4)
DW_CFA_nop
DW_CFA_nop
parseInstructions(instructions=0x2061bcb0)
DW_CFA_advance_loc: new offset=1
DW_CFA_def_cfa_offset(8)
DW_CFA_offset(reg=5, offset=-8)
DW_CFA_advance_loc: new offset=3
DW_CFA_def_cfa_register(5)
DW_CFA_advance_loc: new offset=15
DW_CFA_offset(reg=6, offset=-20)
DW_CFA_offset(reg=7, offset=-16)
DW_CFA_offset(reg=3, offset=-12)
DW_CFA_advance_loc2: new offset=298
libunwind:  _backtrace: ended because cursor reached bottom of stack, returning 5  // _URC_END_OF_STACK

failed: /usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:81: nptrs != (size_t)-1 not met

$ ldd backtrace_test
...
         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x20617000)

$ objdump -x /lib/libgcc_s.so.1:
...
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
...
 11 .eh_frame     00000c28  00004bdc  00004bdc  00004bdc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 12 .text         0000d588  00006000  00006000  00006000  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

So we're unwinding in libgcc_s.so.1.

(gdb) p/x 0x2061bbf4-0x20617000-0x00004bdc
$6 = 0x18
(Except... the instructions printed look like the CIE, which is at offset 0 nominally?)

(gdb) p/x 0x2061bcb0-0x20617000-0x00004bdc
$7 = 0xd4

0xd4 is this FDE, I think:

000000d4 00000024 000000d8 FDE cie=00000000 pc=00006550..000065e8
  DW_CFA_advance_loc: 1 to 00006551
  DW_CFA_def_cfa_offset: 8
  DW_CFA_offset: r5 (ebp) at cfa-8
  DW_CFA_advance_loc: 2 to 00006553
  DW_CFA_def_cfa_register: r5 (ebp)
  DW_CFA_advance_loc: 12 to 0000655f
  DW_CFA_offset: r6 (esi) at cfa-20
  DW_CFA_offset: r7 (edi) at cfa-16
  DW_CFA_offset: r3 (ebx) at cfa-12
  DW_CFA_advance_loc1: 136 to 000065e7
  DW_CFA_def_cfa: r4 (esp) ofs 4

It all matches, except advance_loc1 of 136 only advances to offset 151, not 298???  That looks more like the 0xac FDE directly above:

000000ac 00000024 000000b0 FDE cie=00000000 pc=00006420..0000654b
  DW_CFA_advance_loc: 1 to 00006421
  DW_CFA_def_cfa_offset: 8
  DW_CFA_offset: r5 (ebp) at cfa-8
  DW_CFA_advance_loc: 2 to 00006423
  DW_CFA_def_cfa_register: r5 (ebp)
  DW_CFA_advance_loc: 12 to 0000642f
  DW_CFA_offset: r6 (esi) at cfa-20
  DW_CFA_offset: r7 (edi) at cfa-16
  DW_CFA_offset: r3 (ebx) at cfa-12
  DW_CFA_advance_loc2: 283 to 0000654a
  DW_CFA_def_cfa: r4 (esp) ofs 4

Which, sure enough, is identical except loc2 and 283 line up with the printed output.
Ok, what's 0x6420?

00006420 T _Unwind_Backtrace

Right, ok, that makes sense.  Why does it think we ran out of stack?  gdb shows that the
frame above '_Unwind_Backtrace' is 'backtrace(3)' in libexecinfo.  I think this loops
back to my earlier observation:  libexecinfo.so.1 on i386 is missing an eh_frame section,
and the unwinder (silently) bails with error when it cannot locate unwind information for
a code pointer.
Comment 11 Conrad Meyer freebsd_committer 2019-11-05 23:54:42 UTC
i386 build (from CI):

cc -target i386-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp -B/usr/obj/usr/src/i386.i386/tmp/usr/bin -fpic -DPIC  -O2 -pipe   -I/usr/src/contrib/libunwind/include -g -MD  -MF.depend.backtrace.pico -MTbacktrace.pico -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable  -Qunused-arguments -c /usr/src/contrib/libexecinfo/backtrace.c -o backtrace.pico

cc -target i386-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp -B/usr/obj/usr/src/i386.i386/tmp/usr/bin -fpic -DPIC  -O2 -pipe   -I/usr/src/contrib/libunwind/include -g -MD  -MF.depend.symtab.pico -MTsymtab.pico -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable  -Qunused-arguments    -c /usr/src/contrib/libexecinfo/symtab.c -o symtab.pico

cc -target i386-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp -B/usr/obj/usr/src/i386.i386/tmp/usr/bin -fpic -DPIC  -O2 -pipe   -I/usr/src/contrib/libunwind/include -g -MD  -MF.depend.unwind.pico -MTunwind.pico -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable  -Qunused-arguments    -c /usr/src/contrib/libexecinfo/unwind.c -o unwind.pico

cc -target i386-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp -B/usr/obj/usr/src/i386.i386/tmp/usr/bin    -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel  -o libexecinfo.so.1.full -Wl,-soname,libexecinfo.so.1  `NM='nm' NMFLAGS='' lorder backtrace.pico symtab.pico unwind.pico |  tsort -q`  -lelf

========================================================================================

amd64 build (also CI):

cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -fpic -DPIC  -O2 -pipe   -I/usr/src/contrib/libunwind/include -g -MD  -MF.depend.backtrace.pico -MTbacktrace.pico -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable  -Qunused-arguments    -c /usr/src/contrib/libexecinfo/backtrace.c -o backtrace.pico

cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -fpic -DPIC  -O2 -pipe   -I/usr/src/contrib/libunwind/include -g -MD  -MF.depend.symtab.pico -MTsymtab.pico -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable  -Qunused-arguments    -c /usr/src/contrib/libexecinfo/symtab.c -o symtab.pico

cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -fpic -DPIC  -O2 -pipe   -I/usr/src/contrib/libunwind/include -g -MD  -MF.depend.unwind.pico -MTunwind.pico -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable  -Qunused-arguments    -c /usr/src/contrib/libexecinfo/unwind.c -o unwind.pico

cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin    -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel  -o libexecinfo.so.1.full -Wl,-soname,libexecinfo.so.1  `NM='nm' NMFLAGS='' lorder backtrace.pico symtab.pico unwind.pico |  tsort -q`  -lelf


I'm not seeing noticeably different flags (i.e., -fexceptions or -funwind-tables) at all.
Comment 12 Conrad Meyer freebsd_committer 2019-11-06 00:15:12 UTC
Ok, so, I believe this is a difference in Clang defaults across arch.

Class hierarchy:

FreeBSD.h: class LLVM_LIBRARY_VISIBILITY FreeBSD : public Generic_ELF
(Doesn't override ::IsUnwindTablesDefault().)

Gnu.h: class LLVM_LIBRARY_VISIBILITY Generic_ELF : public Generic_GCC

Gnu.h: class LLVM_LIBRARY_VISIBILITY Generic_GCC : public ToolChain

(Files are: clang/lib/Driver/Toolchain{.cpp,s/{FreeBSD,Gnu}.h}, clang/include/clang/Driver/Toolchain.h. )

Default implementation:
   246 bool ToolChain::IsUnwindTablesDefault(const ArgList &Args) const {
   247   return false;

Generic_GCC overrides:
  289   bool IsUnwindTablesDefault(const llvm::opt::ArgList &Args) const override;

  2538 bool Generic_GCC::IsUnwindTablesDefault(const ArgList &Args) const {
  2539   return getArch() == llvm::Triple::x86_64;
  2540 }

Fuck's sake.
Comment 13 Conrad Meyer freebsd_committer 2019-11-06 00:33:01 UTC
When that line was originally committed (in, uh, 2017), it came with this additional comment:

  // FIXME: all non-x86 targets need unwind tables, however, LLVM currently does
  // not know how to emit them.

https://github.com/llvm/llvm-project/commit/f561abab56801665997217099e5652e625e81cb2#diff-27605951dacea62a60c5338b839b6c25R227

However, the comment was since removed.  And the defaults left unchanged.
Comment 14 Conrad Meyer freebsd_committer 2019-11-06 00:48:02 UTC
https://reviews.freebsd.org/D22252 for the Clang change.
Comment 15 commit-hook freebsd_committer 2019-11-06 23:45:21 UTC
A commit references this bug:

Author: cem
Date: Wed Nov  6 23:44:38 UTC 2019
New revision: 354418
URL: https://svnweb.freebsd.org/changeset/base/354418

Log:
  clang: Enable unwind tables on !amd64

  There doesn't seem to be much sense in defaulting "on" unwind tables on
  amd64 and not on other arches.  It causes surprising differences between
  platforms, such as the PR below.

  Prior to this change, FreeBSD inherited the default implementation of the
  method from the Gnu.h Generic_Elf => Generic_GCC parent class, which
  returned true only for amd64 targets.  Override that and opt on always,
  similar to, e.g., NetBSD.

  PR:		241562
  Reported by:	lwhsu
  Reviewed by:	dim
  Discussed with:	emaste
  MFC after:	I'm not going to, but you should feel free
  Relnotes:	yes
  Differential Revision:	https://reviews.freebsd.org/D22252

Changes:
  head/contrib/llvm/tools/clang/lib/Driver/ToolChains/FreeBSD.cpp
  head/contrib/llvm/tools/clang/lib/Driver/ToolChains/FreeBSD.h
Comment 16 commit-hook freebsd_committer 2019-11-07 04:04:40 UTC
A commit references this bug:

Author: lwhsu
Date: Thu Nov  7 04:04:07 UTC 2019
New revision: 354428
URL: https://svnweb.freebsd.org/changeset/base/354428

Log:
  Revert r354238 as the issue has been fixed in r354418

  PR:		241562
  Sponsored by:	The FreeBSD Foundation

Changes:
  head/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c
Comment 17 Conrad Meyer freebsd_committer 2019-11-07 04:36:25 UTC
Thanks Li-Wen Hsu.  I hadn't had a chance to confirm it entirely resolved the test failure on i386, but it seems plausible.  (It was at least one issue.)
Comment 18 Li-Wen Hsu freebsd_committer 2019-11-07 12:06:37 UTC
(In reply to Conrad Meyer from comment #17)
Wait, do you mean that there are more issues remaining? Do you think it's possible for you to list (some of) them at least?  I am not saying fix them, but it would be nice if we can have the potential issues be tracked.
Comment 19 Conrad Meyer freebsd_committer 2019-11-07 15:20:29 UTC
(In reply to Li-Wen Hsu from comment #18)
No, I don't know of any issues remaining.  I just hadn't re-run the test yet.
Comment 20 Li-Wen Hsu freebsd_committer 2019-11-07 16:04:22 UTC
(In reply to Conrad Meyer from comment #19)
Thanks for the clarification.
Comment 21 Conrad Meyer freebsd_committer 2019-11-07 16:13:08 UTC
https://ci.freebsd.org/job/FreeBSD-head-i386-test/7302/testReport/lib.libexecinfo/

The test now passes, I think we’re good.