abseil / abseil/abseil-cpp

Symbolize.SymbolizeWithMultipleMaps fails in absl_symbolize_test on s390x with LTO

Aperta
#1,133 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub
bug priority: p3
Lingua principale
C++
Stelle
18.1k
Fork
3.2k
Merge medio
20h 36m
PR unite (30g)
1

Descrizione

**Describe the bug**

In the Fedora Linux [distribution package](https://src.fedoraproject.org/rpms/abseil-cpp/) for `abseil-cpp`, we find that `Symbolize.SymbolizeWithMultipleMaps` in `absl_symbolize_test` fails on the `s390x` architecture. When the test fails, a message like
```
/builddir/build/BUILD/abseil-cpp-20210324.2/absl/debugging/symbolize_test.cc:315: Failure
Expected equality of these values:
"kPadding1"
buf
Which is: ""
/builddir/build/BUILD/abseil-cpp-20210324.2/absl/debugging/symbolize_test.cc:349: Failure
Expected equality of these values:
expected[i]
Which is: "kPadding1"
buf
Which is: ""
/builddir/build/BUILD/abseil-cpp-20210324.2/absl/debugging/symbolize_test.cc:349: Failure
Expected equality of these values:
expected[i]
Which is: "kPadding1"
buf
Which is: ""
```
is printed.

When LTO is disabled in the build, the test does not fail.

**Steps to reproduce the bug**

The error can be observed in the RPM build infrastructure for Fedora Linux, but there is nothing particularly special about how we are building the library, and there are no significant downstream patches involved. I expect that this error can probably be reproduced on any `s390x` system when combined with LTO.

**What version of Abseil are you using?**

20111102.0

**What operating system and version are you using**

Fedora Linux Rawhide/37 (development version)

**What compiler and version are you using?**

```
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-libstdcxx-backtrace --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-12.0.1-20220308/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver --enable-offload-defaulted --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220308 (Red Hat 12.0.1-0) (GCC)
```

**What build system are you using?**

```
cmake version 3.23.0-rc2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
```

**Additional context**

We are using https://github.com/abseil/abseil-cpp/archive/20111102.0/abseil-cpp-20111102.0.tar.gz with:

- CMake build system (using `ninja` backend)
- System copies of `gtest`/`gmock` 1.11.0
- A [small patch](https://src.fedoraproject.org/rpms/abseil-cpp/blob/c43daf75e50307a61f4a64f7d44b9e5ddff8a0d4/f/abseil-cpp-20211102.0-gtest-unreleased-features.patch) for #1063
- System compiler GCC 12.0.1

While I don’t have convenient interactive access to real `s390x` hardware, I can easily test patches or try experiments on real hardware by submitting “scratch” RPM builds.

I have attached a [complete failing build log](https://github.com/abseil/abseil-cpp/files/8255334/build.log) including compiler flags.

No other architectures (of `x86_64`, `i686`, `aarch64`, and `ppc64le`) are affected.

Guida per i contributori

Apri la guida per i contributori

Direzione di ricerca

Il test che fallisce si trova in absl/debugging/symbolize_test.cc, intorno alle righe 315 e 349, e verifica la simbolizzazione di 'kPadding1'. Il problema è specifico dell'architettura s390x con LTO abilitato. Inizia riproducendo il problema in un ambiente s390x con LTO, esamina l'implementazione della simbolizzazione in absl/debugging/symbolize.cc e comprendi in che modo LTO influisce sulla visibilità dei simboli su s390x. Controlla il log di build per i flag del compilatore e considera le interazioni con l'LTO di GCC sui sistemi big-endian.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
cmake, cpp, linux
Ambito
backend, compilers, testing
Tipo di issue
Bug
Difficoltà
4/5
Tempo stimato
3-5 giorni
Stato di attività
Ferma
Chiarezza
Specificata chiaramente
Idoneità per principianti
35/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.