Embedded targets problem

Embedded targets problem

[Dmitry]

Fellows,
I am trying to port my stuff to current gcc version (taken from CVS).

It looks like new 'gcov' stuff breaks embedded targets builds.
This is probably cause gcov refers to some includes such as 'stdio.h' and 
'fcntl.h' which not always exist for small machines.

The relevant ChangeLog entry is:
2002-09-11  Nathan Sidwell  <nathan@codesourcery.com>
        Reimplement gcov format.
        * gcov-io.h: Replace.
        * gcov.c: Reimplement.
        * gcov-iov.c: New file.
        * gcov-dump.c: New file.
        * libgcc2.c (L_bb): Replace with ...
        (L_gcov): ... this.
        (struct bb_function_info, struct bb): Remove.

Is it possible to avoid this appart from patching Makefile?

gcc-3.2.X builds fine.


Thanks,
Dmitry.

Re: Embedded targets problem

[Joel Sherrill]

Dmitry wrote:
> 
> Fellows,
> I am trying to port my stuff to current gcc version (taken from CVS).
> 
> It looks like new 'gcov' stuff breaks embedded targets builds.
> This is probably cause gcov refers to some includes such as 'stdio.h' and
> 'fcntl.h' which not always exist for small machines.

This shouldn't break any embedded target which either uses newlib and
is configured --with-newlib or has a modest C library that gcc is made 
aware via the proper configure options.  Are you trying to build with
no references to the C library at all?

> The relevant ChangeLog entry is:
> 2002-09-11  Nathan Sidwell  <nathan@codesourcery.com>
>         Reimplement gcov format.
>         * gcov-io.h: Replace.
>         * gcov.c: Reimplement.
>         * gcov-iov.c: New file.
>         * gcov-dump.c: New file.
>         * libgcc2.c (L_bb): Replace with ...
>         (L_gcov): ... this.
>         (struct bb_function_info, struct bb): Remove.
> 
> Is it possible to avoid this appart from patching Makefile?
> 
> gcc-3.2.X builds fine.
> 
> Thanks,
> Dmitry.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Embedded targets problem

[Dmitry]

> > It looks like new 'gcov' stuff breaks embedded targets builds.
> > This is probably cause gcov refers to some includes such as 'stdio.h' and
> > 'fcntl.h' which not always exist for small machines.
>
> This shouldn't break any embedded target which either uses newlib and
> is configured --with-newlib or has a modest C library that gcc is made
Well, my (msp430) target has no newlib and this (--with-newlib) configure 
option does not help much. And yes, we have some sort of libc which obviously 
cannot be compiled without a cross gcc buld.

> aware via the proper configure options.  Are you trying to build with
> no references to the C library at all?
Yes, I am trying to build cross gcc and cross compile 'libgcc2.c' without any 
target-specific library installed

I think the problem comes from Makefile.in where 
LIB2FUNCS_ST = _eprintf _gcov __gcc_bcmp

defined and cannot be overriden by any config options.

Is it possible yo apply a small patch which will fix this problem?

[2003-01-03]	whoever
	* Makefile.in	(LIB2FUNCS_ST): define this only in case 
'config/target/t-target' has not defined LIB2FUNCS_ST allowing small machines 
avoid building unsupported functions.

Index: Makefile.in
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.963
diff -c -3 -p -r1.963 Makefile.in
*** Makefile.in 7 Jan 2003 17:05:05 -0000       1.963
--- Makefile.in 9 Jan 2003 08:15:28 -0000
*************** LIB2FUNCS_2 = _floatdixf _fixunsxfsi _fi
*** 799,805 ****
      _addvdi3 _subvsi3 _subvdi3 _mulvsi3 _mulvdi3 _negvsi2 _negvdi2 _ctors

  # Defined in libgcc2.c, included only in the static library.
! LIB2FUNCS_ST = _eprintf _gcov __gcc_bcmp

  FPBIT_FUNCS = _pack_sf _unpack_sf _addsub_sf _mul_sf _div_sf \
      _fpcmp_parts_sf _compare_sf _eq_sf _ne_sf _gt_sf _ge_sf \
--- 799,805 ----
      _addvdi3 _subvsi3 _subvdi3 _mulvsi3 _mulvdi3 _negvsi2 _negvdi2 _ctors

  # Defined in libgcc2.c, included only in the static library.
! LIB2FUNCS_ST?= _eprintf _gcov __gcc_bcmp

  FPBIT_FUNCS = _pack_sf _unpack_sf _addsub_sf _mul_sf _div_sf \
      _fpcmp_parts_sf _compare_sf _eq_sf _ne_sf _gt_sf _ge_sf \

Re: Embedded targets problem

[Joel Sherrill]

Dmitry wrote:
> 
> > > It looks like new 'gcov' stuff breaks embedded targets builds.
> > > This is probably cause gcov refers to some includes such as 'stdio.h' and
> > > 'fcntl.h' which not always exist for small machines.
> >
> > This shouldn't break any embedded target which either uses newlib and
> > is configured --with-newlib or has a modest C library that gcc is made
> Well, my (msp430) target has no newlib and this (--with-newlib) configure
> option does not help much. And yes, we have some sort of libc which obviously
> cannot be compiled without a cross gcc buld.

newlib is not the only option for building cross compilers.
You can use an existing prebuilt C library when building gcc
as well.  This is the procedure you have to use when building
a cross to a target which has a proprietary C library such
as Solaris.  

Before you build the cross gcc, put the header files for your
C library in ${prefix}/${target}/sys-include and the 
libraries under ${prefix}/${prefix}/lib.  gcc should find them
as part of the build then.


> > aware via the proper configure options.  Are you trying to build with
> > no references to the C library at all?
> Yes, I am trying to build cross gcc and cross compile 'libgcc2.c' without any
> target-specific library installed

If these can be built with your target's library, then just preinstall
it.
Or... effectively do what --with-newlib does.  Let it turn on a path
to your target's C library so that gcc knows where the include files
are in the source tree.  If you integrate this way, then you would have
to make your C library part of the top level build procedure.  But it
should just be a matter of adapting what was done with newlib.

> I think the problem comes from Makefile.in where
> LIB2FUNCS_ST = _eprintf _gcov __gcc_bcmp
> 
> defined and cannot be overriden by any config options.
> 
> Is it possible yo apply a small patch which will fix this problem?

If this is all you want to do, why not define inhibit_libc in your
target's
config/t-XXX file?  I think it does exactly what you want to do.

> [2003-01-03]    whoever
>         * Makefile.in   (LIB2FUNCS_ST): define this only in case
> 'config/target/t-target' has not defined LIB2FUNCS_ST allowing small machines
> avoid building unsupported functions.
> 
> Index: Makefile.in
> ===================================================================
> RCS file: /cvsroot/gcc/gcc/gcc/Makefile.in,v
> retrieving revision 1.963
> diff -c -3 -p -r1.963 Makefile.in
> *** Makefile.in 7 Jan 2003 17:05:05 -0000       1.963
> --- Makefile.in 9 Jan 2003 08:15:28 -0000
> *************** LIB2FUNCS_2 = _floatdixf _fixunsxfsi _fi
> *** 799,805 ****
>       _addvdi3 _subvsi3 _subvdi3 _mulvsi3 _mulvdi3 _negvsi2 _negvdi2 _ctors
> 
>   # Defined in libgcc2.c, included only in the static library.
> ! LIB2FUNCS_ST = _eprintf _gcov __gcc_bcmp
> 
>   FPBIT_FUNCS = _pack_sf _unpack_sf _addsub_sf _mul_sf _div_sf \
>       _fpcmp_parts_sf _compare_sf _eq_sf _ne_sf _gt_sf _ge_sf \
> --- 799,805 ----
>       _addvdi3 _subvsi3 _subvdi3 _mulvsi3 _mulvdi3 _negvsi2 _negvdi2 _ctors
> 
>   # Defined in libgcc2.c, included only in the static library.
> ! LIB2FUNCS_ST?= _eprintf _gcov __gcc_bcmp
> 
>   FPBIT_FUNCS = _pack_sf _unpack_sf _addsub_sf _mul_sf _div_sf \
>       _fpcmp_parts_sf _compare_sf _eq_sf _ne_sf _gt_sf _ge_sf \

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Embedded targets problem

[Dmitry]

> If this is all you want to do, why not define inhibit_libc in your
> target's
> config/t-XXX file?  I think it does exactly what you want to do.

This  disables only __eprintf()

Cheers,
Dmitry.

Re: Embedded targets problem

[Joel Sherrill]

Dmitry wrote:
> 
> > If this is all you want to do, why not define inhibit_libc in your
> > target's
> > config/t-XXX file?  I think it does exactly what you want to do.
> 
> This  disables only __eprintf()

Sorry to be thick headed but if inhibit_libc doesn't cover something
it should, then that's a problem.  So going back to your list:

_eprintf  - inhibit_libc covers this OK
_gcov 	  - where is this symbol?  I don't see it.
_gcc_bcmp - has no IO, only depends on size_t being defined and
            that comes from gcc so what is wrong with this one?
            I would think it should compile without a C library being
there.

But inhibit_libc does appear to cover the basic block profiling 
stuff around line 1292.  


> Cheers,
> Dmitry.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Embedded targets problem

[Joel Sherrill]

Dmitry wrote:
> 
> probably we're got libgcc2.c versions mismatch.
> I'm using current cvs version.

OK.  That makes sense and explans the differences.

Then I contend that _gcov should be wrapped by inhibit_libc
just like the old code that was there.  This is a regression.
The gcov support should still be wrapped by a conditional
on inhibit_libc.  

--joel

> cheers,
> ~d
> 
> On Thursday 09 January 2003 17:19, Joel Sherrill wrote:
> > Dmitry wrote:
> > > > If this is all you want to do, why not define inhibit_libc in your
> > > > target's
> > > > config/t-XXX file?  I think it does exactly what you want to do.
> > >
> > > This  disables only __eprintf()
> >
> > Sorry to be thick headed but if inhibit_libc doesn't cover something
> > it should, then that's a problem.  So going back to your list:
> >
> > _eprintf  - inhibit_libc covers this OK
> > _gcov           - where is this symbol?  I don't see it.
> > _gcc_bcmp - has no IO, only depends on size_t being defined and
> >             that comes from gcc so what is wrong with this one?
> >             I would think it should compile without a C library being
> > there.
> >
> > But inhibit_libc does appear to cover the basic block profiling
> > stuff around line 1292.
> >
> > > Cheers,
> > > Dmitry.
> 
> --
> /********************************************************************
>      ("`-''-/").___..--''"`-._     (\   Dimmy the Wild      UA1ACZ
>       `6_ 6  )   `-.  (     ).`-.__.`)  Enterprise Information Sys
>       (_Y_.)'  ._   )  `._ `. ``-..-'   Nevsky prospekt,   20 / 44
>     _..`--'_..-_/  /--'_.' ,'           Saint Petersburg,   Russia
>    (il),-''  (li),'  ((!.-'             +7 (812)  3468202, 5585314
>  ********************************************************************/

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985