https://sourceware.org/bugzilla/show_bug.cgi?id=22452
--- Comment #10 from H. Brueckner ---
(In reply to Mark Wielaard from comment #9)
> (In reply to H. Brueckner from comment #8)
> > (In reply to Mark Wielaard from comment #5)
> > > (In reply to Mark Wielaard from comment #4)
> > > > So, if you
https://sourceware.org/bugzilla/show_bug.cgi?id=22452
--- Comment #11 from Andreas Krebbel ---
x86 enables generation of .debug_frame by using:
KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
in the kernel Makefile. This makes GCC to add ".cfi_sections .debug_frame" to
the assembler output wh
https://sourceware.org/bugzilla/show_bug.cgi?id=22452
--- Comment #12 from Mark Wielaard ---
(In reply to H. Brueckner from comment #10)
> (In reply to Mark Wielaard from comment #9)
> > But the output does confirm what I feared. The R_390_PC32 .rela.eh_frame
> > relocations are not "simple". The
https://sourceware.org/bugzilla/show_bug.cgi?id=22452
--- Comment #13 from Andreas Krebbel ---
The .eh_frame section in an .o file uses PC-relative relocations in order to
get its offset to the code determined during final link step. It probably does
this to avoid runtime relocations which would
The notes in a core file that contain the auxv entries might not be
naturally aligned. The code already tried to account for that, but
the GCC 8 undefined behaviour sanitizer found we were till dereferencing
the actual auxv entry pointer directly. Fix this by calculating all pointers
by hand and no
https://sourceware.org/bugzilla/show_bug.cgi?id=22452
--- Comment #14 from H. Brueckner ---
Hi Mark, Andreas,
(In reply to Andreas Krebbel from comment #11)
> x86 enables generation of .debug_frame by using:
>
> KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
>
> in the kernel Makefile. This
