Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aarch64: error: inline assembly requires more registers than available #702

Open
am11 opened this issue Jan 15, 2024 · 5 comments · May be fixed by #748
Open

aarch64: error: inline assembly requires more registers than available #702

am11 opened this issue Jan 15, 2024 · 5 comments · May be fixed by #748
Labels
aarch64 Problems specific to the aarch64 ARCH bug
Milestone

Comments

@am11
Copy link
Contributor

am11 commented Jan 15, 2024

Hm, clang has a different error:

error: inline assembly requires more registers than available
   65 |         "ldr x0,  %[x0]\n\t"
      |         ^

Originally posted by @sfc-gh-sgiesecke in #608 (comment)


Hitting the same issue in dotnet-runtime, where arm64 legs are cross-compiled using clang.

@am11
Copy link
Contributor Author

am11 commented Jan 17, 2024

Looks like gcc also fails with -O0 here:

from https://github.com/libunwind/libunwind/actions/runs/7543438232/job/20534462217

aarch64/Gos-linux.c:41:7: error: 'asm' operand has impossible constraints
   41 |       __asm__ __volatile__ (
      |       ^~~~~~~

clang fails with all -O{0,2,3}.. it can only handle 14 registers in input operands at a time. Keeping any 14 in

: [x0] "m"(uc->uc_mcontext.regs[0]),
[x1] "m"(uc->uc_mcontext.regs[1]),
[x2] "m"(uc->uc_mcontext.regs[2]),
[x3] "m"(uc->uc_mcontext.regs[3]),
[x19] "m"(uc->uc_mcontext.regs[19]),
[x20] "m"(uc->uc_mcontext.regs[20]),
[x21] "m"(uc->uc_mcontext.regs[21]),
[x22] "m"(uc->uc_mcontext.regs[22]),
[x23] "m"(uc->uc_mcontext.regs[23]),
[x24] "m"(uc->uc_mcontext.regs[24]),
[x25] "m"(uc->uc_mcontext.regs[25]),
[x26] "m"(uc->uc_mcontext.regs[26]),
[x27] "m"(uc->uc_mcontext.regs[27]),
[x28] "m"(uc->uc_mcontext.regs[28]),
[x29] "m"(uc->uc_mcontext.regs[29]), /* FP */
[x30] "m"(uc->uc_mcontext.regs[30]), /* LR */
[d8] "m"(GET_FPCTX(uc)->vregs[8]),
[d9] "m"(GET_FPCTX(uc)->vregs[9]),
[d10] "m"(GET_FPCTX(uc)->vregs[10]),
[d11] "m"(GET_FPCTX(uc)->vregs[11]),
[d12] "m"(GET_FPCTX(uc)->vregs[12]),
[d13] "m"(GET_FPCTX(uc)->vregs[13]),
[d14] "m"(GET_FPCTX(uc)->vregs[14]),
[d15] "m"(GET_FPCTX(uc)->vregs[15]),
[sp] "m"(uc->uc_mcontext.sp)
(and adjusting template and clobbers above and below) fixes the error.

@bregma, this is a build regression in v1.8.0. Given the limitations of both clang and gcc, it seems like we have three options:

  1. split the inline asm block in two parts
  2. switch from inline assembly to dedicated assembly file .S
  3. revert the original change and rework it for the next release

@TannerFirl
Copy link

TannerFirl commented Feb 29, 2024

I'm hitting this error, so won't be able to upgrade to v1.8 til its resolved. Does anyone have a patch for this?

@am11
Copy link
Contributor Author

am11 commented Feb 29, 2024

I reverted #503 in dotnet/runtime to fix it like this: dotnet/runtime@d63c235 (#96969).

@jamel
Copy link

jamel commented Apr 16, 2024

Hit similar issue when compile Libunwind with Clang-14.0.6 on Aarch64 (graviton) Amazon Linux 2.

Here is the exact compilation command that fails:

$ clang -DHAVE_CONFIG_H -I. -I../include -I../include -I../include/tdep-aarch64 -I. -D_GNU_SOURCE -DNDEBUG -Wall -Wsign-compare -D__EXTENSIONS__ -c aarch64/Los-linux.c -o aarch64/.libs/Los-linux.o
In file included from aarch64/Los-linux.c:4:
aarch64/Gos-linux.c:45:9: error: inline assembly requires more registers than available
        "ldr x0,  %[x0]\n\t"
        ^
aarch64/Gos-linux.c:45:9: error: inline assembly requires more registers than available
aarch64/Gos-linux.c:45:9: error: inline assembly requires more registers than available
aarch64/Gos-linux.c:45:9: error: inline assembly requires more registers than available
aarch64/Gos-linux.c:45:9: error: inline assembly requires more registers than available
aarch64/Gos-linux.c:45:9: error: inline assembly requires more registers than available
aarch64/Gos-linux.c:45:9: error: inline assembly requires more registers than available
aarch64/Gos-linux.c:45:9: error: inline assembly requires more registers than available
aarch64/Gos-linux.c:45:9: error: inline assembly requires more registers than available
aarch64/Gos-linux.c:45:9: error: inline assembly requires more registers than available
10 errors generated.

@bregma bregma added this to the 1.9.0 milestone Apr 18, 2024
@bregma bregma added aarch64 Problems specific to the aarch64 ARCH bug labels Apr 18, 2024
@sdebnath
Copy link

This issue is tagged for 1.9.0. Would be great to get a fix as a patch in 1.8 series. Same issue as #742

@bregma bregma linked a pull request Apr 22, 2024 that will close this issue
jonpryor pushed a commit to xamarin/xamarin-android that referenced this issue May 16, 2024
)

Context: #8800
Context: 8bc7a3e
Context: 6836818
Context: libunwind/libunwind#702

Begin adding native method call tracing infrastructure based on
[libunwind][0], initially used in tracing the reasons for why
[Blazor][1] apps break when LLVM marshal methods are enabled
(8bc7a3e, 6836818).  The utility of such infrastructure, however,
is beyond just that particular task; it should be available for
general use by both us and applications.

Method call tracing support is not enabled by default.
To enable it, set the `$(_AndroidEnableNativeStackTracing)` MSBuild
property to `true`.  This will enable the ability to print native, 
managed and Java stack traces by invoking the `monodroid_log_traces`
function from either managed or native application code.

Additionally, change the directory layout for native code.

Previously, `src/monodroid` would produce *five* native libs:

  * `libmono-android.debug.so`
  * `libmono-android.release.so`
  * `libxa-internal-api.so`
  * `libxamarin-app.so`
  * `libxamarin-debug-app-helper.so`

This made for a large `src/monodroid/CMakeLists.txt`, complicating
maintenance.  We had considered trying to move these into separate
`src/LIBRARY-NAME` directories, but it makes things easier with
CMake if we introduce an intermediate directory.

Introduce a new `src/native` directory, to hold native binaries:

  * `src/native/monodroid`: new location for `libmono-android.*.so`

  * `src/native/xamarin-debug-app-helper`: source for
    `libxamarin-debug-app-helper.so`, containing code moved from
    previous `src/monodroid`

  * `src/native/xamarin-app-stub`: source for the "stub"
    `libxamarin-app.so`; the "real" one is produced in the app build.

Some `src/native/*` directories produce libraries (`.so` files). and
some produce *static* archives (`.a` files) to simplify using code
across native libraries.

A [cmake-presets file][2] is processed by `xaprepare`, to create a
`src/native/CMakePresets.json` which contains all the version-specific
bits replacements such as Android API levels, paths to utilities etc.

Developers can create a `src/native/CMakeUserPresets.json` file to
provide local modifications to config options within
`src/native/CMakePresets.json.in`.

Other changes:

  * `src/native/libunwind/fixes/aarch64/Gos-linux.c` is an altered
    copy of [`libunwind/src/aarch64/Gos-linux.c`][3] in order to
    workaround libunwind/libunwind#702.

  * *Begin* turning some instance member functions into static member
    functions, as we don't otherwise need instances of those classes.

  * Begin using `std::source_location` for better crash messages,
    instead of using `__FILE__` and `__LINE__`.

  * Fix endless recursion from a typo in `Util::ends_with()` overload.

[0]: https://github.com/libunwind/libunwind
[1]: https://learn.microsoft.com/aspnet/core/blazor/hybrid/tutorials/maui?view=aspnetcore-8.0
[2]: https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html
[3]: https://github.com/libunwind/libunwind/blob/9cc4d98b22ae57bc1d8c253988feb85d4298a634/src/aarch64/Gos-linux.c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
aarch64 Problems specific to the aarch64 ARCH bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants