Re: Properly building newlib to install spec files

[Jozef Lawrynowicz <jozef dot l at mittosystems dot com>]

On Tue, 22 Oct 2019 11:49:06 -0400
Orlando Arias <orlandoarias@gmail.com> wrote:

> Greetings,
> 
> On 10/22/19 3:07 AM, Mojca Miklavec wrote:
> > Dear Orlando,
> > 
> > On Sun, 20 Oct 2019 at 21:21, Orlando Arias wrote:  
> >>
> >> Greetings,
> >>
> >> I was under the impression that the nosys.specs file was no longer provided for the msp430-elf target in light of the CIO interface being added [1][2]. Please correct me if I'm wrong on this.
> >>
> >> Cheers,
> >> Orlando.
> >>
> >> [1] https://sourceware.org/ml/newlib/2015/msg00926.html
> >> [2] https://sourceware.org/ml/newlib/2015/msg00923.html  
> > 
> > In the meantime I figured out that I only had a link to an outdated
> > (and probably removed) file on TI's web server, the site
> >     http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/index_FDS.html
> > still works and provides working links to a newer version of gcc, so I
> > was able to proceed with testing msp430 as well.
> > 
> > After installing gcc 8.3.0 with newlib 2.4.0 (the ones for which they
> > provide patches inside msp430-gcc-8.3.0.16-source-patches.tar.bz2) in
> > the same way that got me the spec files installed for arm, those same
> > spec files in fact seem to be missing for msp430-elf-gcc.
> > 
> > I don't quite remember where I got these instructions from. I was
> > definitely following a few tutorials in the past to get me started
> > with msp430 and some arm chips, but I'm not sure if the requirement to
> > specify the spec file came from one of the tutorials for arm, or maybe
> > random notes from internet about how to test msp430 when I tried to
> > update the msp430 toolchain inside our package manager, like for
> > example:
> >     https://gist.github.com/0/631c9006a672458eaa48
> > 
> > Bottomline: I'm perfectly happy at the moment that I hopefully got the
> > arm toolchain fixed (which was both reported by two of our users, plus
> > me when I needed to do something with arm), while I'm not yet sure if
> > I actually need it for msp430, and it's unlikely that I'll soon have
> > time to play with msp430 boards again. In short: I'm probably happy
> > until the next user complains. (I don't know much about
> > cross-compilers or msp430, so I cannot argue whether the spec files
> > need to be added back or not.)
> > 
> > Mojca
> >   
> 
> Thank you for taking the time to look over this. I myself maintain the
> [most of the] packages for the msp430-elf toolchain in the AUR [Arch
> Linux User Repository]. I noted a while back that the nosys.specs file
> was missing from the newlib package, tracing back to the patches I
> pointed out in my earlier e-mail. That file did use to ship with newlib
> for the msp430-elf target.
> 
> At the time, I had some users asking about what happened to the file in
> question, but unfortunately the best I could tell them was that it was
> removed, and gave them a different linker command to use in their
> projects. That is, pass the linker -lnosys if necessary or provide own
> implementations for the missing BSP functions, the latter of which
> should generally be the course of action, given that -lnosys provides
> the CIO routines which are mostly useless outside debugging [CIO,
> Console I/O, implements something similar to ARM semihosting, adding
> traps for the debugger to emulate certain operations]. I was wondering
> if I had done something wrong.
> 
> I looked over the instructions in your GitHub link, and I noted that
> they use newlib-2.2.0-1. Looking at the release directory [1] for
> newlib, that particular release predates the patches that removed
> nosys.specs from the distribution. That is why their linking command
> seems to work. Otherwise, the procedure they outline is effectively the
> same as the one I use in the packages I maintain.

Hi,

I can only speculate why specs were removed, but I don't miss them.

Unlike ARM there's not too much relative variation in the size of MSP430
devices. The upper limit on the amount of usable memory is ~1MB.
ARM devices can be much, much larger, so being able to choose between Newlib
Nano configuration and the default is desirable, hence nano.specs.

For MSP430 we are always going to be size-constrained so it's best to always use
Newlib Nano.

As you discovered, nosys still exists but it is enabled by using the GCC -msim
option. The real use case for stubbing out system calls is when running programs
in the simulator.

In the default configuration which assumes the program will run on real
hardware, most system calls (except write() and unlink()) are stubbed out
and just loop forever. So there will be very little (if any) code size
bloat from using the default configuration over -msim.

When TI CIO functionality is added to the other syscalls, there could be a
use case to provide an option (--specs or otherwise) which enables them to be
stubbed out again.

Hope this helps,
Jozef

> 
> Again, thank you.
> 
> Cheers,
> Orlando.
> 
> [1] ftp://sourceware.org/pub/newlib/index.html
>