toolchain/58197: [RB] Generated CTF data depends on the building host

[jbglaw%lug-owl.de@localhost]

>Number:         58197
>Category:       toolchain
>Synopsis:       [RB] Generated CTF data depends on the building host
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 25 18:10:01 +0000 2024
>Originator:     Jan-Benedict Glaw
>Release:        current
>Organization:
>Environment:
NetBSD nnetbsd-template.intern.jbglaw.lug-owl.de 10.99.10 NetBSD 10.99.10 (GENERIC) #0:   mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64

Linux lili 5.16.0-4-amd64 #1 SMP PREEMPT Debian 5.16.12-1 (2022-03-08) x86_64 GNU/Linux
>Description:
While working on reproducibility, I found CTF data to be differently generated on NetBSD build hosts vs. Linux-based build hosts.

As a random example (taken from a epoc32/earmv4 build), this is the diff from a `ctfdump t_strcoll` call done from build results created on a Linux and a NetBSD host:


--- t_strcoll-l.ctf     2024-04-24 20:27:26.047114634 +0000
+++ t_strcoll-n.ctf     2024-04-24 20:27:30.545341234 +0000
@@ -10,18 +10,18 @@
   cth_objtoff  = 8
   cth_funcoff  = 30
   cth_typeoff  = 72
-  cth_stroff   = 632
+  cth_stroff   = 524
   cth_strlen   = 316

 - Label Table ----------------------------------------------------------------

-     50 *** No Label Provided ***
+     37 *** No Label Provided ***

 - Data Objects ---------------------------------------------------------------

-  [0] 45       tests (67)
-  [1] 38       atfu_ordering_tc (71)
-  [2] 22       atfu_ordering_tc_pack (74)
+  [0] 35       tests (67)
+  [1] 30       atfu_ordering_tc (71)
+  [2] 15       atfu_ordering_tc_pack (74)
   [3] 0        _DYNAMIC (93)
   [4] 0        _GLOBAL_OFFSET_TABLE_ (96)
   [5] 0        __progname (112)
@@ -33,11 +33,11 @@

 - Functions ------------------------------------------------------------------

-  [2] FUNC (h_ordering) returns: 1 args: (47)
-  [3] FUNC (atfu_ordering_head) returns: 1 args: (50)
-  [4] FUNC (atfu_ordering_body) returns: 1 args: (40)
-  [5] FUNC (atfu_tp_add_tcs) returns: 32 args: (37)
-  [7] FUNC (main) returns: 49 args: (49, 48)
+  [2] FUNC (h_ordering) returns: 1 args: (36)
+  [3] FUNC (atfu_ordering_head) returns: 1 args: (31)
+  [4] FUNC (atfu_ordering_body) returns: 1 args: (31)
+  [5] FUNC (atfu_tp_add_tcs) returns: 24 args: (29)
+  [7] FUNC (main) returns: 37 args: (37, 11)

 - Types ----------------------------------------------------------------------

@@ -47,70 +47,57 @@
   <4> STRUCT atf_tc (4 bytes)
        pimpl type=3 off=0

-  [5] CONST (anon) refers to 4
-  [6] POINTER (anon) refers to 5
-  [7] FUNCTION (anon) returns: 1 args: (6)
-  [8] POINTER (anon) refers to 7
-  <9> TYPEDEF atf_tc_cleanup_t refers to 8




Ad hoc, I have no clue *where* these differences arise from. A typical candidate would be a qsort() call (where order preservation for equal elements is different between NetBSD and Linux), but the only call in ctfmerge just sorts input files (no problem here), so I guess it's somewhere buried in the used libelf. Maybe somebody has an ad-hoc idea on where to search.
>How-To-Repeat:
Build on Linux for a target using CTF debugging information (eg. earm) and compare some differing binaries.
>Fix:
No idea right now. As I'm quite unfamiliar with the code, that would imply some extensive digging.