Re: [PATCH] libgloss/arm: Remove abort.

[Jeff Johnston <jjohnstn at redhat dot com>]

Richard Earnshaw wrote:
> On Thu, 2006-06-01 at 23:03, Jeff Johnston wrote:
>
> > Shaun Jackman wrote:
> >
> > > On 6/1/06, Jeff Johnston <jjohnstn@redhat.com> wrote:
> > >
> > >
> > > > That is no problem, however, I just realized that I missed the fact that
> > > > the libc/sys/arm directory needs to be changed as well because the flag
> > > > will affect those users that don't disable newlib supplying syscalls.
> > > > Since it is a bit more than a minor touch-up, any chance you could post
> > > >  another patch with the additional changes to libc/sys/arm?
> > >
> > >
> > > I don't fully understand why the duplication of libgloss/arm and
> > > libc/sys/arm still exists. Keeping the two in sync is a royal pain.
> > > Can we finally remove libc/sys/arm and be done with it? Adding
> > > libgloss to the specs file would hide it from the user. Alternatively,
> > > libgloss could be inserted into libc.a at the same time libc.a is
> > > collected from all the component lib.a.
> > >
> > > Cheers,
> > > Shaun
> >
> > We have talked about this before.  Gcc has to change over to use 
> > libgloss by default.  Adding libgloss into the specs file would do it in 
> > conjunction with making non-newlib-supplied-syscalls the default from 
> > then on.  Adding libgloss back into libc.a is not going to happen.
>
>
> If I change gcc, won't it break the ability to use old versions of
> newlib?  Also, won't it mean that people who don't want to use newlib as
> their C library will have to provide a stub libgloss.a?

Yes, if an alternate spec file or compatibility option isn't provided. 
The code in libc/sys/arm is going to be deprecated, then removed.  I was 
hoping that switching the compiler over would create the most minimal 
impact to end-users (i.e. same compile statement, link statements). 
Perhaps I am thinking too fast a schedule here.

I had started by adding a configuration option that allowed one to use 
libgloss instead of the /libc/sys/arm.  At present, the default for arm 
is to allow newlib-supplied syscalls.

To start deprecating /libc/sys/arm I will make the default arm 
configuration disallow newlib-supplied syscalls.  If the user wants 
/libc/sys/arm, then the user has to then add the special 
--enable-newlib-supplied-syscalls configuration option.  Without some 
change to gcc, the end-user would require adding -lxxx to their link 
statements.

Maybe introducing a configuration option in gcc would be the way to go 
here.  One configures gcc to use libgloss by default.  It would be 
helpful if newlib could figure this out in its configuration.

Regarding the question about other C libraries, the configuration option 
could be made to simply be a choice of using newlib (possibly the 
existing --with-newlib option??).  It makes sense in that when using 
newlib, libgloss is there and gcc knows it has to handle linking 
differently.  For other libraries, it goes with the current strategy.

What do you think?

-- Jeff J.

> I need to understand more about this change if you want gcc to be
> changed in this regard.
>
> R.