libsys/arm: include ARM EABI unwind bits into libsys
ClosedPublic
Actions

Authored by fuz on Wed, Feb 11, 10:14 PM.

Details

Reviewers

jrtc27
kib
markj
andrew
mmel

Commits

rGeac62e18e83a: libc/arm: use __builtin_trap() instead of abort() in aeabi_unwind stubs
rGf16349f12d8a: libsys/arm: include ARM EABI unwind bits into libsys
rG1782bc9a0a8d: libc/arm: use __builtin_trap() instead of abort() in aeabi_unwind stubs
rG6265f30cd6b5: libsys/arm: include ARM EABI unwind bits into libsys

Summary

libsys required ARM EABI unwind symbols like __aeabi_unwind_cpp_pr0.
These symbols are normally provided by libc, but if a binary does
not link libc, the symbol ends up not being resolved.

Among other problems, this prevented gcc14 and newer from building
on arm.

Add the relevant symbols as hidden symbols into libsys to avoid this
problem.

We also switch from abort() to __builtin_trap() in the aeabi_unwind
stubs to avoid a dependency on abort.

(this patch was posted by jrtc27 who has asked me to move it along)

PR: 292539
Submitted by: jrtc27
Tested by: Mark Millard <marklmi26-fbsd@yahoo.com>

Test Plan

lang/gcc14 builds fine with this change set.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

fuz created this revision.Wed, Feb 11, 10:14 PM

Herald added a reviewer: andrew. · View Herald TranscriptWed, Feb 11, 10:14 PM

Herald added a subscriber: imp. · View Herald Transcript

fuz requested review of this revision.Wed, Feb 11, 10:14 PM

Harbormaster completed remote builds in B70629: Diff 171800.Wed, Feb 11, 10:14 PM

mmel added a subscriber: mmel.Thu, Feb 12, 5:37 AM

Should not these symbols also be marked as weak? Hidden symbols are not 'overloaded' in the same library. kib, jrtc27 any comment about this, please?

In D55255#1263672, @mmel wrote:

Should not these symbols also be marked as weak? Hidden symbols are not 'overloaded' in the same library. kib, jrtc27 any comment about this, please?

I see no use in marking these symbols as weak, They are hidden, which means that they are directly bound to the references, also they are not exported. So they are not interposable.
It might be useful, though, to only link aeabi_uwind_cpp into dso and not include it into libsys.a. If this is your concern that the object file might be found by the static linker.
BTW the same point for libc.

Sorry for my poorly formulated question.
The hidden but not weak aeabi_unwind_cpp_pr* symbols means that we don't expect or want to process exceptions generated in libsys because the unwinder always ends in an abort/trap. So why don't we simply compile libsys with -fno-exceptions?

I'm not questioning the patch itself; I just want to understand its context.
Thanks.

We do want the unwind info generated for libsys. Although libsys cannot generate exceptions synchronously, it still might be the last frame for stack where signal is delivered for process that slept in the slow syscall. The unwinding info is needed for any dwarf stack unwinders then, like gdb, libunwind, etc, even in its armv7 variant, as far as I understand.

So -fno-exceptions is not a choice there.

I understand that libsys might be the last frame.
However, this also means that the unwinder is supposed to call the function aeabi_unwind_cpp_pr0, found in the .ARM.exidx section of the corresponding object.
In your case, this is buildin_trap().
Is this right?

This is the last question, I promise.

In D55255#1263689, @mmel wrote:

I understand that libsys might be the last frame.
However, this also means that the unwinder is supposed to call the function aeabi_unwind_cpp_pr0, found in the .ARM.exidx section of the corresponding object.
In your case, this is buildin_trap().
Is this right?

This is the last question, I promise.

Are unwinders really supposed to call anything to just get the backtrace, as opposed to really unwind (e.g. to catch C++ exception)?

I'm not sure if anyone knows the exact, precise response. ARMv7 unwinding is pure mesh. All of my attempts to understand it ended with me turning off the computer and opening a bottle of good wine.
I think it's possible to write a backtrace that doesn't use it, but I also think it's used by the unwinder library, which is also used for backtraces.
My motivation was to be careful about security. If the executable implements real unwinder personalities, we should also use it for libsys

In any case, we've come too far. This patch is clearly a step in the right direction, and I don't want to block it.

Thanks for your effort.

This revision is now accepted and ready to land.Thu, Feb 12, 11:19 AM

In D55255#1263686, @mmel wrote:

Sorry for my poorly formulated question.
The hidden but not weak aeabi_unwind_cpp_pr* symbols means that we don't expect or want to process exceptions generated in libsys because the unwinder always ends in an abort/trap. So why don't we simply compile libsys with -fno-exceptions?
. . .

In my experiments for armv7 specifically, that option did not disable having the unwind tables nor the associated eabi_unwindow_cpp_pr* symbols. The only option I found that did disable at least some of that in the object files also happened to disable all of it: -fno-asynchronous-unwind-tables . See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292539#c13 .