Question regarding newlib/libgloss

[Joel Sherrill]

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

>
>
> 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.
>

Thanks.

>
>> 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?
>

Answering from a phone but there should be a configure file setting which
is forced and does the same thing. Maybe configure.host. The RTEMS port
predates many of the configure options.



>
>
> 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.
>

I can see this as being useful if it is a general pattern across all the
targets. But you would have a lot of functionality enabled which doesn't
work in bare metal mode. No big deal if you avoid it

Also the crt0.c provided by default with RTEMS tool builds is intended to
make autoconf probes happy. It isn't functional.

I expect it is just a matter of passing the right arguments and avoiding
using the things what you can't work without RTEMS.

--joel



>
>
> 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
>> 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/99aab437/attachment.html>