Unreviewed patch

Unreviewed patch

[Momchil Velikov]

HEAD fails to build for ``sh-elf'' target.
http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00433.html

~velco

Re: Unreviewed patch / {PATCH] Do not override configure decision about inhibit_libc

[Joern Rennecke]

Momchil Velikov wrote:
> 
> HEAD fails to build for ``sh-elf'' target.
> http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00433.html
> 
> ~velco

The sole purpose of embed-bb.c is to provide the
infrastructure for arc profiling to newlib targets, where
unfortunately, inhibit_libc is set. 
 
How do you build a usable sh-elf compiler without newlib
in the first place?

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: Unreviewed patch / {PATCH] Do not override configure decision about inhibit_libc

[Momchil Velikov]

>>>>> "Joern" == Joern Rennecke <joern.rennecke@superh.com> writes:
Joern> How do you build a usable sh-elf compiler without newlib
Joern> in the first place?

Huh ? The compiler by itself does not require newlib nor does the
produced code, right ?

~velco

Re: Unreviewed patch / {PATCH] Do not override configure decision about inhibit_libc

[Joern Rennecke]

Momchil Velikov wrote:
> 
> >>>>> "Joern" == Joern Rennecke <joern.rennecke@superh.com> writes:
> Joern> How do you build a usable sh-elf compiler without newlib
> Joern> in the first place?
> 
> Huh ? The compiler by itself does not require newlib nor does the
> produced code, right ?

It you need header files for the compiler if you compile code
that include any of them.  And you need the c library if any
function of it is used.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: Unreviewed patch / {PATCH] Do not override configure decision about inhibit_libc

[Momchil Velikov]

>>>>> "Joern" == Joern Rennecke <joern.rennecke@superh.com> writes:

Joern> Momchil Velikov wrote:
>> 
>> >>>>> "Joern" == Joern Rennecke <joern.rennecke@superh.com> writes:
Joern> How do you build a usable sh-elf compiler without newlib
Joern> in the first place?
>> 
>> Huh ? The compiler by itself does not require newlib nor does the
>> produced code, right ?

Joern> It you need header files for the compiler if you compile code
Joern> that include any of them.  And you need the c library if any
Joern> function of it is used.

I can think of at least three legitimate cases:

I. Use the compiler in a freestanding environment - no libraies or
headers exist at all.

II. Build and install the libraries after building the compiler - way
more convenient than installing headers only, building the compiler,
going back and building the libraries.

III. In a cross compilation environment, the headers may not be on the
same machine.

~velco

Re: Unreviewed patch / {PATCH] Do not override configure decision about inhibit_libc

[Joern Rennecke]

Momchil Velikov wrote:
> 
> >>>>> "Joern" == Joern Rennecke <joern.rennecke@superh.com> writes:
> 
> Joern> Momchil Velikov wrote:
> >>
> >> >>>>> "Joern" == Joern Rennecke <joern.rennecke@superh.com> writes:
> Joern> How do you build a usable sh-elf compiler without newlib
> Joern> in the first place?
> >>
> >> Huh ? The compiler by itself does not require newlib nor does the
> >> produced code, right ?
> 
> Joern> It you need header files for the compiler if you compile code
> Joern> that include any of them.  And you need the c library if any
> Joern> function of it is used.
> 
> I can think of at least three legitimate cases:
> 
> I. Use the compiler in a freestanding environment - no libraies or
> headers exist at all.

Is there a demand for this configuration?  In that case, we should
have something more fine-grained that inhibit_libc, which suppresses
the profiling support along with eprintf.
	
> II. Build and install the libraries after building the compiler - way
> more convenient than installing headers only, building the compiler,
> going back and building the libraries.

It's also more convenient that writing all the binaries by hand.  But
still moe convenient is just to use a unified source tree and build
everything in one go.
> 
> III. In a cross compilation environment, the headers may not be on the
> same machine.

Why would you want to build the libraries on a different machine than
the compiler?
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: Unreviewed patch / {PATCH] Do not override configure decision about inhibit_libc

[Momchil Velikov]

>>>>> "Joern" == Joern Rennecke <joern.rennecke@superh.com> writes:
Joern> Momchil Velikov wrote:
>> I can think of at least three legitimate cases:
>> 
>> I. Use the compiler in a freestanding environment - no libraies or
>> headers exist at all.

Joern> Is there a demand for this configuration?  In that case, we should
Joern> have something more fine-grained that inhibit_libc, which suppresses
Joern> the profiling support along with eprintf.

I'd think disabling profiling in the environments, which do not
support stdio is prefferable to disabling the use of GCC in these
environments.

~velco

Re: Unreviewed patch / {PATCH] Do not override configure decision about inhibit_libc

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

Momchil Velikov wrote:
> Joern> Is there a demand for this configuration?  In that case, we should
> Joern> have something more fine-grained that inhibit_libc, which suppresses
> Joern> the profiling support along with eprintf.
> 
> I'd think disabling profiling in the environments, which do not
> support stdio is prefferable to disabling the use of GCC in these
> environments.

Yes, but currently inhibit_libc is set automatically for all newlib
toolchains, so if we disabled profiling using inhibit_libc, profiling
would be disabled altogether for newlib toolchains.  We have to get rid of
this automatic setting of inhibit_libc so that inhibit_libc actually
means somehing again.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

[-- Attachment #2: dont-inhibit-newlibc --]
[-- Type: text/plain, Size: 2375 bytes --]

Thu Jul 25 22:40:05 2002  J"orn Rennecke <joern.rennecke@superh.com>

	* configure.in (inhibit_libc): For newlib, set to -Dinhibit_eprintf.
	* libgcc2.c (__eprintf): Also inhibited by inhibit_eprintf.

Index: configure.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/configure.in,v
retrieving revision 1.610
diff -p -r1.610 configure.in
*** configure.in	14 Jul 2002 01:59:13 -0000	1.610
--- configure.in	25 Jul 2002 21:39:58 -0000
*************** fi
*** 1144,1157 ****
  # have its own set of headers then define
  # inhibit_libc
  
! # If this is using newlib, then define inhibit_libc in LIBGCC2_CFLAGS.
! # This prevents libgcc2 from containing any code which requires libc
! # support.
  inhibit_libc=
! if [test x$host != x$target] && [test x$with_headers = x]; then
!        inhibit_libc=-Dinhibit_libc
  else
!        if [test x$with_newlib = xyes]; then
                 inhibit_libc=-Dinhibit_libc
         fi
  fi
--- 1144,1157 ----
  # have its own set of headers then define
  # inhibit_libc
  
! # If this is using newlib, then define inhibit_libc in LIBGCC2_CFLAGS to
! # -Dinhibit_eprintf.  We should not be using __eprintf because newlib
! # has its own version of assert.h
  inhibit_libc=
! if [test x$with_newlib = xyes]; then
!        inhibit_libc=-Dinhibit_eprintf
  else
!        if [test x$host != x$target] && [test x$with_headers = x]; then
                 inhibit_libc=-Dinhibit_libc
         fi
  fi
Index: libgcc2.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/libgcc2.c,v
retrieving revision 1.144
diff -p -r1.144 libgcc2.c
*** libgcc2.c	22 Jul 2002 00:15:49 -0000	1.144
--- libgcc2.c	25 Jul 2002 21:39:58 -0000
*************** __gcc_bcmp (const unsigned char *s1, con
*** 1214,1220 ****
     for binary backward compatibility.  Note that it is not included in
     the shared version of libgcc.  */
  #ifdef L_eprintf
! #ifndef inhibit_libc
  
  #undef NULL /* Avoid errors if stdio.h and our stddef.h mismatch.  */
  #include <stdio.h>
--- 1214,1220 ----
     for binary backward compatibility.  Note that it is not included in
     the shared version of libgcc.  */
  #ifdef L_eprintf
! #if ! defined (inhibit_libc) && ! defined (inhibit_eprintf)
  
  #undef NULL /* Avoid errors if stdio.h and our stddef.h mismatch.  */
  #include <stdio.h>

Re: Unreviewed patch / {PATCH] Do not override configure decision about inhibit_libc

[Richard Zidlicky]

On Thu, Jul 25, 2002 at 01:41:16PM +0100, Joern Rennecke wrote:
> Momchil Velikov wrote:
> > 
> > >>>>> "Joern" == Joern Rennecke <joern.rennecke@superh.com> writes:
> > 
> > Joern> Momchil Velikov wrote:
> > >>
> > >> >>>>> "Joern" == Joern Rennecke <joern.rennecke@superh.com> writes:
> > Joern> How do you build a usable sh-elf compiler without newlib
> > Joern> in the first place?
> > >>
> > >> Huh ? The compiler by itself does not require newlib nor does the
> > >> produced code, right ?
> > 
> > Joern> It you need header files for the compiler if you compile code
> > Joern> that include any of them.  And you need the c library if any
> > Joern> function of it is used.
> > 
> > I can think of at least three legitimate cases:
> > 
> > I. Use the compiler in a freestanding environment - no libraies or
> > headers exist at all.
> 
> Is there a demand for this configuration? 

yes. Keeping everything in sync is lot of pain, right now I came
across a problem where distcc fails with '-g' option because the 
remote compiler was configured for different binutils..

Richard

Unreviewed patch

[kaz Kojima]

Tom Tromey <tromey@redhat.com> wrote:
> As you've discovered, libffi is a bit under maintained.  I'm not
> really the person to do it -- I'd do little more than rubber stamp
> patches that come in.  I'm happy to do that, though, in the absence of
> a better process.  Hopefully some more qualified person out there will
> speak up (and we'll end up with a libffi entry in MAINTAINERS).
> 
> I believe we've agreed in the past that port maintainers can make
> port-specific libffi changes.  So I think you can check in your fix on
> that basis.

I'd like to check my patch in. Thanks.

I totally agree with your and Anthony's suggestion about the approvement 
for libffi changes, though in this specific case I hesitate over because
sh64-linux is for the SHmedia processor with a new and very different ISA
from the other SH family and I'm rather new to SHmedia.
So I thought and still think that it would be nice if SHmedia experts see
my patch.

BTW, libjava works to some extent with the sjlj configuration using this
libffi port. I'll report it to the java list.

Regards,
	kaz

Re: Unreviewed patch

[Joseph S. Myers]

On Thu, 12 Jun 2003, Anthony Green wrote:

> > I believe we've agreed in the past that port maintainers can make
> > port-specific libffi changes.  So I think you can check in your fix on
> > that basis.
> 
> The situation is a little frustrating because it's not made explicit in
> the MAINTAINERS file.  I once tried to clear this up with the SC through
> one of its members, but got no reply.

cvswrite.html currently says:

          Maintainers of a port maintain the files in config/port/, the
          configure fragments for the port, documentation for the port
          and test cases for features or bugs specific to this port. Port
          maintainers do not have approval rights in other files.

Perhaps this should be expanded to list target-specific files outside the
gcc directory.  In that case, the FIXME in sourcebuild.texi asking for a
list of such places, in the checklist of what's needed in a target port,
could be filled in at the same time.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Unreviewed patch

[Gerald Pfeifer]

On Thu, 12 Jun 2003, Anthony Green wrote:
>> I believe we've agreed in the past that port maintainers can make
>> port-specific libffi changes.  So I think you can check in your fix
>> that basis.
> The situation is a little frustrating because it's not made explicit in
> the MAINTAINERS file.  I once tried to clear this up with the SC through
> one of its members, but got no reply.

That's unfortunate.

> My suggestion is that the following people should be able to approve
> libffi changes:
>
> 0. Global maintainers
> 1. GCC port maintainers, since many times they will be the only ones who
> understand the asm code.
> 2. Tromey, as the maintainer of libgcj, since this is an important part
> of it.
> 3. Me, as the original author.
> BTW - I think we should also add MAINTAINERS entries for zlib, boehm-gc
> and fastjar.

Would you mind suggesting appropriate additions to the MAINTAINERS file?
I'll happily forward them to the SC and make sure to follow it.

On Thu, 12 Jun 2003, Joern Rennecke wrote:
> I'm somewhat unsure about the status of libffi.  On the one
> hand it is a separate project, and as such it appears that only
> Anthony Green can approve patches.
> On the other hand the libffi home page says 'libffi is now largely
> maintained as part of GCC.' , and if it is actually maintained as
> part of GCC, that would mean that global and target port maintainers
> of gcc can approve patches.

The point is, is it largely maintained as part of GCC, or is it now
part of GCC (like, for example, libstdc++ and libgcj which became
fully integrated)?

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Unreviewed patch

[Anthony Green]

On Thu, 2003-06-12 at 07:15, Tom Tromey wrote:
>  Hopefully some more qualified person out there will
> speak up (and we'll end up with a libffi entry in MAINTAINERS).
> 
> I believe we've agreed in the past that port maintainers can make
> port-specific libffi changes.  So I think you can check in your fix on
> that basis.

The situation is a little frustrating because it's not made explicit in
the MAINTAINERS file.  I once tried to clear this up with the SC through
one of its members, but got no reply.

My suggestion is that the following people should be able to approve
libffi changes:

0. Global maintainers
1. GCC port maintainers, since many times they will be the only ones who
understand the asm code.
2. Tromey, as the maintainer of libgcj, since this is an important part
of it.
3. Me, as the original author.

BTW - I think we should also add MAINTAINERS entries for zlib, boehm-gc
and fastjar.

AG

-- 
Anthony Green <green@redhat.com>
Red Hat, Inc.

Re: Unreviewed patch

[Tom Tromey]

>>>>> "kaz" == kaz Kojima <kkojima@rr.iij4u.or.jp> writes:

kaz> libffi sh64-*-linux* support:
kaz> <URL:http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02321.html>

As you've discovered, libffi is a bit under maintained.  I'm not
really the person to do it -- I'd do little more than rubber stamp
patches that come in.  I'm happy to do that, though, in the absence of
a better process.  Hopefully some more qualified person out there will
speak up (and we'll end up with a libffi entry in MAINTAINERS).

I believe we've agreed in the past that port maintainers can make
port-specific libffi changes.  So I think you can check in your fix on
that basis.

Tom