Mediatek DSP fixups #844
Mediatek DSP fixups #844
Conversation
|
Yeah... how about a respin that after running |
The new directory structure in the upstream Cadence tarballs wasn't as compatible as I thought. Binutils will produce a working assembler, but only if it does NOT see the new xtensa-config.h (which was added in a path it doesn't look at). Also gcc ends up hitting the in-tree/non-overlayed xtensa-config.h and produces a big endian compiler! Don't be fancy. Move stuff around to match the older overlays exactly. Also add the "defs.h" inclusion as generated by make-overlay.sh, and rename the copy of xtensa-xtregs.c in gdbserver to .cc as required by current binutils and done by other sdk-ng overlays. And I'd forgotten the copy of core-isa.h for newlib (which SOF doesn't use, but should still be present in the SDK). Signed-off-by: Andy Ross <andyross@google.com> squashme defs.h
There is no "predicted branches" extension in any version of the Xtensa ISA reference I have. Newer versions of Cadence tooling have removed (and presumably deprecated) this symbol, but binutils still relies on seeing it (even just to evaluate to a zero to diable the feature). Really the proper fix would be to patch binutils upstream, but let's have compatible headers here first. Signed-off-by: Andy Ross <andyross@google.com>
The name of the rmap array changed in upstream bintuils commit
2b16913cdca2 ("gdb: make gdbarch_alloc take ownership of the tdep").
At the same time it seems like the xtensa_tdep definition (which
contra the filename is actually a C++ object definition and not a
function prototype!) moved into this file from elsewhere in binutils.
The xtensa_rmap symbol is only used by newer binutils versions than
the Zephyr SDK builds, but add an alias so it builds with upstream
crosstools-ng, and commit it here as a reference if we want to port
the other Xtensa overlays.
Signed-off-by: Andy Ross <andyross@google.com>
|
And I see we now have a build. And I can confirm it generates working binaries for all four devices with these two in-flight PRs applied: zephyrproject-rtos/zephyr#82350 Once those merge we can uncomment the test lines in the Github integration. |
|
Quick ping here. The updated HAL and Zephyr PRs have merged now, so the toolchain generated by this PR has been verified to work to build successfully with all the relevant platforms. |
| @@ -113,7 +113,7 @@ const xtensa_mask_t xtensa_mask39 = { 1, xtensa_submask39 }; | |||
|
|
|||
|
|
|||
| /* Register map. */ | |||
| static xtensa_register_t rmap[] = | |||
| xtensa_register_t rmap[] = | |||
There was a problem hiding this comment.
oof. global with such a generic name doesn't seem ideal. I assume this is required for ABI though?
There was a problem hiding this comment.
Yeah, these overlays get dropped on top of the binutils source code (that starts out populated with an old Xtensa "sample_controller" file). It's... not super clean. FWIW the Espressif-contributed work on LLVM is capable of generating a single toolchain where all these deltas are captured by a config struct instead. It appears to build Zephyr last I checked, though I haven't had time to see what would be needed to turn it into a "Lite Xtensa SDK".
(Worth nothing that there is no lldb work there that I've seen, so we'd still need to build binutils and gdb I guess. Though there might be some savings)
There was a problem hiding this comment.
FWIW the Espressif-contributed work on LLVM is capable of generating a single toolchain where all these deltas are captured by a config struct instead. It appears to build Zephyr last I checked, though I haven't had time to see what would be needed to turn it into a "Lite Xtensa SDK".
Interesting. Since LLVM will be part of Zephyr SDK from 0.18.0, we can potentially explore this option. At least, we can drop the GCC builds for the Xtensa toolchain variants whose users do not explicitly require GCC (well, if LLVM works, why should they?)
|
@andyross It looks like macOS is unhappy with these changes ... https://github.com/zephyrproject-rtos/sdk-ng/actions/runs/12245593957/job/34159828915 |
| @@ -496,4 +496,6 @@ static xtensa_register_t rmap[] = | |||
| XTREG_END | |||
| }; | |||
|
|
|||
| extern xtensa_register_t xtensa_rmap[] __attribute__((alias("rmap"))); | |||
Fixed needed to get a real working toolchain out of the recently merged overlays. Not quite sure how I convinced myself that was going to work. My own builds with upstream ct-ng were doing OK, but it's possible it was confounded by a union of the two directory schemes (or maybe we're a little behind?).