Re: [Update] devel/arm-none-eabi 7.4.1 -> 7.5.0
Somebody claiming to be Joe Nelson wrote: > Hi Dave and Tracey, seems like you have experience in this area. Can you give > me any advice? > > I'm cross-compiling for an ST Nucleo F411RE, which requires these CFLAGS: > > -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 > > On my system, 'arm-none-eabi-gcc -print-multi-directory' can't find a match > for > them. By comparison, on Debian, arm-none-eabi-gcc finds 'thumb/v7e-m+fp/hard'. > > Is there a way to update the port on my system to include this multilib > flavor? The arm-none-eabi-gcc you have might be able to build working binaries anyways; code generation isn't affected, and the thumb builds of the libraries it has will still very probably work, but you won't have library support for newer features of the Cortex-M4 core. (Also, notably, the library configuration doesn't know about thumb- only cores and builds a few libgcc routines that use arm-mode instructions and won't work - but the only place I've seen that happen is a software division call that the M4 has hardware instructions for.) If that doesn't work, the patch at https://marc.info/?l=openbsd-ports=159897831109275=2 enables the R/M profile multilib options to get library support for Cortex-M cores. (The binutils part of the patch there is already committed; newlib configures itself based on the GCC multilib config, so it needs an update to get support for the ARMv8 configurations as well as a rebuild to pick up the new config.) (The reasons why this is necessary for Cortex-M cores and not already in the ports tree are complicated but round to "ARM multilib config is complicated, and this port is critical system infrastructure in a way that does not care about embedded cross-compiling".) dave -- Dave Vandervies dj3va...@terse.ca Plan your future! Make God laugh!
Re: [Update] devel/arm-none-eabi 7.4.1 -> 7.5.0
On Fri, Jan 06, 2023 at 01:48:14PM -0600, Joe Nelson wrote: > Hi Dave and Tracey, seems like you have experience in this area. Can you give > me any advice? > > I'm cross-compiling for an ST Nucleo F411RE, which requires these CFLAGS: > > -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 > > On my system, 'arm-none-eabi-gcc -print-multi-directory' can't find a match > for > them. By comparison, on Debian, arm-none-eabi-gcc finds 'thumb/v7e-m+fp/hard'. > > Is there a way to update the port on my system to include this multilib > flavor? > Thanks for your help. > > --- > System/package information: > > * OpenBSD 7.2 > * arm-none-eabi-gcc-linaro-7.4.2019.02p0 > * arm-none-eabi-newlib-2.2.0.1p1 > > $ arm-none-eabi-gcc --print-multi-lib > .; > thumb;@mthumb > fpu;@mfloat-abi=hard > interwork;@mthumb-interwork > fpu/interwork;@mfloat-abi=hard@mthumb-interwork > thumb/interwork;@mthumb@mthumb-interwork look at gcc-linaro/patches/patch-gcc_config_arm_t-arm-elf MULTILIB_OPTIONS+= mno-thumb-interwork/mthumb-interwork is enabled. Perhaps that's the problem? -- Tracey Emery
Re: [Update] devel/arm-none-eabi 7.4.1 -> 7.5.0
On Fri, Jan 06, 2023 at 01:48:14PM -0600, Joe Nelson wrote:
> Hi Dave and Tracey, seems like you have experience in this area. Can you give
> me any advice?
>
> I'm cross-compiling for an ST Nucleo F411RE, which requires these CFLAGS:
>
> -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16
>
> On my system, 'arm-none-eabi-gcc -print-multi-directory' can't find a match
> for
> them. By comparison, on Debian, arm-none-eabi-gcc finds 'thumb/v7e-m+fp/hard'.
>
> Is there a way to update the port on my system to include this multilib
> flavor?
> Thanks for your help.
>
> ---
> System/package information:
>
> * OpenBSD 7.2
> * arm-none-eabi-gcc-linaro-7.4.2019.02p0
> * arm-none-eabi-newlib-2.2.0.1p1
>
> $ arm-none-eabi-gcc --print-multi-lib
> .;
> thumb;@mthumb
> fpu;@mfloat-abi=hard
> interwork;@mthumb-interwork
> fpu/interwork;@mfloat-abi=hard@mthumb-interwork
> thumb/interwork;@mthumb@mthumb-interwork
I'm guessing you'd use --with-multilib-list={whatever-secret-sauce} your
Nucleo needs. However, I don't know what your secret sauce is.
--
Tracey Emery
Re: [Update] devel/arm-none-eabi 7.4.1 -> 7.5.0
Somebody claiming to be Tracey Emery wrote: > Hello ports, > > I'm not sure anyone is particularly interested in this but me, and the > patch is pretty gross and a significant change, so I'm sure it'll take > awhile before anyone really wants to review this. I have a version of arm-none-eabi-* in mystuff that requests the R/M profile multilib config, which I use regularly at my day job. (For some Cortex-M parts, and some operations, having the appropriate multilib configuration available can be necessary to avoid pulling in library routines with illegal instructions.) While you're doing surgery on the build process to support a particular Cortex-M-targeted environment anyways might not be the worst possible time to pull that in as well. Previous work: https://marc.info/?l=openbsd-ports=159897831109275=2 It's a fairly small change in the Makefile (adding '--with-multilib-list=rmprofile' to CONFIGURE_ARGS for the arm-none-eabi flavour) but propagates to the PLIST for both gcc and newlib (which configures itself based on the GCC multilib configuration.) > In order to be able to work with Raspberry Pi Pico boards, and the like, > we need to have C++ headers. This patch adds a bootstrap and flavors the > whole port so that those can be built. > > I changed this to be more inline with the various Espressif xtensa > ports, in which the cross-compile tools are within their own > subdirectories of LOCALBASE. I'm not a fan of having my cross-compilers not be in the default $PATH. (I've never worked with xtensa parts so have not been paying attention to why it's done that way there.) > Now, I don't know if this is the right direction for the aarch64 > flavour, as I don't have anything to test that with, but it builds and > the arm flavour compiles code for the Raspberry Pi Pico SDK and it runs > on a board on at least amd64. I think one of the reasons my patch to enable R/M profile multilib didn't get any love was that the aarch64 flavour is needed for building the aarch64 bootloader, which makes it a critical system component. (I'm not sure whether or how it would work out to split the port into parallel copies so that the system boot people and the embedded devs don't interfere with each other, but that might be less worse than having the embedded devs maintain their own local versions?) > If this makes it, I'll send a port for the Raspberry Pi SDK which seems > to work great! And if not, I'm happy keeping this local. > > If you are currently using either or both flavours of this port > currently, please test this out to your devices. That would be greatly > appreciated! > > Thoughts? ok? A quick glance through the rewiring for the bootstrap build looks sensible to me. It might be a few weeks before I manage to allocate time to actually try it out on nontrivial builds. dave -- Dave Vandervies dj3va...@terse.ca Plan your future! Make God laugh!
