Question regarding newlib/libgloss

[Andrei Zisu]

Sent from my iPhone

On 14 Oct 2019, at 14:43, Joel Sherrill <joel at rtems.org> wrote:




On Mon, Oct 14, 2019, 7:14 AM Andrei Zisu <Andrei.Zisu at pts.space> wrote:

Hello everyone,


I am currently learning about how RSB builds the toolchain.


Although this isn't my question to the list, for context, I am looking at to reusing the rtems toolchain for other non-rtems-based targets we have.


Looking at it, there's not a lot of difference to an arm-none-eabi compiler. However, it appears that libgloss is entirely disabled for rtems toolchains in the newlib configuration.


Looking through the history of newlib, I was able to trace the origin of this disabling to a change from 1996 by Joel Sherill which simply enables rtems toolchains.

And with some luck, I'm still here. :)

Yes, fan of the work.


Therefore, I was wondering what is the reasoning behind disabling this, or is it simply a change carried over from other targets which disabled it?

Libgloss provides the crt0, linker script, and system calls required for newlib to target a board.

The crt0 and linker script plus device drivers to support functionality beyond what libgloss targets are capable of is in an RTEMS BSP. The system calls are implemented primarily in libcsupport and support mounting, various file systems, network stack, etc.

However, I see that the toolchain is not built with --disable-newlib-supplied-syscalls. How does it avoid getting the syscalls? Through bsp_specs?


The RTEMS tool chain configuration is deliberately close to the bare metal one. It limits the chance of breaking something but it does change at least the locking and reentrancy support over the bare metal configuration.


What would the drawbacks of enabling it be? It seems to me that enabling it would not interfere since it is opt-in?

If you extract the setup, configure and make commands, you will be safe to use those to build the bare metal target.

You can probably make libgloss targets work with an RTEMS tool chain but no one has ever invested the effort. It might be interesting for use building bootloader and support code that doesn't use RTEMS.

To be fair, I see now that my targets don't actually depend on what libgloss has to offer (custom startup script and newlib syscalls). I was mistaken about this because I was looking for the origin of nano.specs and the nano libraries.

But looking at, for example, the way the AUR newlib toolchain is built [1], it seems that these are actually to different builds of newlib.

I am currently considering taking this approach for building the toolchain on top of the default rtems toolchain. Would this sort of work be of any interest to the community?

Yes, for example, the bootloader would be one of the targets.


FWIW I have some scripts based on the rsb commands from a few years ago. I use them to compare results and investigate bugs.


Best regards,


Andrei Zisu

________________________________


_______________________________________________
devel mailing list
devel at rtems.org<mailto:devel at rtems.org>
http://lists.rtems.org/mailman/listinfo/devel

[1] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/arm-none-eabi-newlib
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191014/75a4fadb/attachment-0001.html>