headers
Valeriy E. Ushakov | 1 Nov 2003 05:22
Picon

Re: CVS commit: src/sys/conf

On Sun, Oct 26, 2003 at 19:24:06 +0000, Christos Zoulas wrote:

> Module Name:	src
> Committed By:	christos
> Date:		Sun Oct 26 19:24:06 UTC 2003
> 
> Modified Files:
> 	src/sys/conf: Makefile.kern.inc
> 
> Log Message:
> Delete -Wno-uninitialized. Tested on sparc64 and i386. Rationale:
> Gcc-3.3 produces valid warnings in most cases and uncovers bugs. In the
> cases where a variable is known to be initialized, we initialize it and
> add: /* XXX: gcc */. If a $MACHINE_ARCH's compiler is busted, it can add
> -Wno-uninitialized in the MD Makefile.

May be it makes sense to add 

CWARNFLAGS+=	${CWARNFLAGS.${.IMPSRC:T}}

so that MD Makefile can see -Wno-uninitialized only for specific files?

SY, Uwe
--

-- 
uwe <at> ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen
Permalink | Reply | 0 comments |
headers
Richard Earnshaw | 1 Nov 2003 12:19
Favicon

softfloat fixuns woes


In the a.out-on-ARM days we used to build libc with implementations of 
__fixunsdfsi and __fixunssfsi, but since we've switched to ELF we've 
dropped these two functions from our libc.  However, we haven't dropped 
__fixdfdi or __fixunsdfdi and there is a linkage chain between these two 
and __fixunsdfsi which is normally resolved by linking against libgcc.a.

This has two nasty consequences:

1) It means that every application linked against libc.so gets 
__fixunsdfsi linked into the main binary, even though it might never need 
it.

2) It completely breaks when using the new assembler/linker and a FSF 
build of gcc-3.4, where libgcc is built with all the support functions 
marked as .hidden (libraries are clearly intended to be built 
self-contained or linked against the shared libgcc.so).  And the latest 
versions of ld enforce this correctly.

It seems to me that the only solution here is to add the relevant 
__fixunsdfsi function back into our libc.so.

__fixunssfsi is similar, but the one use of this is in gmon.o, but that's 
a bug (the '#ifndef notdef' conditional is reversed).

Comments?

R.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Valeriy E. Ushakov | 2 Nov 2003 15:41
Picon

Re: softfloat fixuns woes

[uwe: cc to current-users dropped, as this follow-up concerns toolchain
technicalities and is not of much interest to current users]

On Sat, Nov 01, 2003 at 11:19:16 +0000, Richard Earnshaw wrote:

> 2) It completely breaks when using the new assembler/linker and a FSF 
> build of gcc-3.4, where libgcc is built with all the support functions 
> marked as .hidden (libraries are clearly intended to be built 
> self-contained or linked against the shared libgcc.so).  And the latest 
> versions of ld enforce this correctly.

Uh, oh.  Now I'm totally confused.

When I discussed the sh3 problem documented in toolchain/22452 with
Kaz Kojima, he mentioned this approach to me, i.e. mark them .hidden,
link -lgcc{,_pic} everywhere (however I didn't realize that in gcc-3.4
all symbols in libgcc are marked as .hidden).

At about the same time we had a PR about C++ exception handling not
working properly with shared libraries and Nick Hudson fixed it by
*NOT* linking -lgcc_pic into shared libraries.  However, note, that
our -lgcc_pic doesn't yet have its symbols .hidden - so may be that's
causing that PR about exceptions.  [sorry about being unspecific, but
I don't have the PR number written down and our web interface to gnats
sucks]

If marking all libgcc symbols .hidden, including the exception
handling code &c makes the exceptions work when libgcc_pic is linked
into every shared library - this will make both PRs (toolchain/22452
and the one about exceptions) fixed at once and also will save us the
(Continue reading)

Permalink | Reply | 11 comments |
headers
Jason Thorpe | 2 Nov 2003 18:17

Re: softfloat fixuns woes


On Sunday, November 2, 2003, at 06:41  AM, Valeriy E. Ushakov wrote:

> . if we want to keep our implementations for those libgcc functions we
>   will be linking our sources and libgcc sources, so we need to ensure
>   the licenses are compatible (e.g. no ad clause, etc).

As long as:

	* libgcc sources are not compiled into any other library

	* libgcc is linked into the resulting library or program
	  in order to support use of GCC

...then there should be no problem with the libgcc license (which is 
"GPL + exception when used with GCC").  Here is the exception clause:

  -- snip --
In addition to the permissions in the GNU General Public License, the
Free Software Foundation gives you unlimited permission to link the
compiled version of this file into combinations with other programs,
and to distribute those combinations without any restriction coming
from the use of this file.  (The General Public License restrictions
do apply in other respects; for example, they cover modification of
the file, and distribution when not linked into a combine
executable.)
  -- snip --

Now, I suppose the question is "what about a shared libgcc?"  This is 
where interpretation of "link the compiled version of this file into
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Laight | 3 Nov 2003 00:14
Picon

nbmake dependall fails to 'depend' arch/i386/stand/netboot/lib

A build today failed because I have some .depend files lurking that
reference deleted include files (IIRC index.S), in any case I updated
bsd.dep.mk to check that all the files in .depend exist [1].
A repeated build failed in the same place!

Digging deeper it seems that 'nbmake dependall' fails to do the 'depend'
for the libraries (lib/sa, lib/z, lib/i386 and lib/kern).

A 'nbmake depend' works fine.

However I can't quite work out what is going on...
The relevant makefiles (eg src/sys/arch/i386/stand/netboot/Makefile)
are just too painful!

Anyone any thoughts/fixes?

	David

[1] another email...

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 0 comments |
headers
David Laight | 3 Nov 2003 00:22
Picon

rebuilding stale .depend files

It gets rather anoying when a build fails because the old
.depend file references a now deleted file.

The patch forces the .depend file to be regenerated if any of the
referenced files has been deleted.

Note that it has to use exists(file) because .PATH has to be applied.
(the shell read handles the continuation lines...)

Thoughts?

	David

Index: bsd.dep.mk
===================================================================
RCS file: /cvsroot/src/share/mk/bsd.dep.mk,v
retrieving revision 1.62
diff -u -p -r1.62 bsd.dep.mk
--- bsd.dep.mk	2003/10/28 01:25:33	1.62
+++ bsd.dep.mk	2003/11/02 23:08:49
 <at>  <at>  -29,6 +29,27  <at>  <at>  __DPSRCS.notd=	${__DPSRCS.all:O:u:N*.d}
 ${__DPSRCS.d}: ${__DPSRCS.notd} ${DPSRCS}
 .endif									# }

+# Force .d files to be regenerated if they reference a missing file.
+# (stops some errors on update builds)
+missing=
+.if (make(dependall)||make(depend)) && !empty(__DPSRCS.d) && exists(.depend) # {
+deps !=	IFS=':'; while read t d; do \
+		echo $$d; \
(Continue reading)

Permalink | Reply | 8 comments |
headers
James Chacon | 3 Nov 2003 05:12
Picon

Re: rebuilding stale .depend files

On Sun, Nov 02, 2003 at 11:22:26PM +0000, David Laight wrote:
> It gets rather anoying when a build fails because the old
> .depend file references a now deleted file.

I agree here. A build with UPDATE=1 should be able to figure out dependencies
and continue.

> 
> The patch forces the .depend file to be regenerated if any of the
> referenced files has been deleted.
> 
> Note that it has to use exists(file) because .PATH has to be applied.
> (the shell read handles the continuation lines...)
> 
> Thoughts?

How much overhead does this add to a build? i.e. have you measured pre-patch
and post-patch for a static tree?

James
Permalink | Reply | 5 comments |
headers
David Laight | 3 Nov 2003 09:39
Picon

Re: rebuilding stale .depend files

On Sun, Nov 02, 2003 at 10:12:02PM -0600, James Chacon wrote:
> On Sun, Nov 02, 2003 at 11:22:26PM +0000, David Laight wrote:
> > It gets rather anoying when a build fails because the old
> > .depend file references a now deleted file.
> 
> I agree here. A build with UPDATE=1 should be able to figure out dependencies
> and continue.

You don't want it to work out all the dependencies again - that would
take too long.  But is is very annoying when a broken .depend file is used.

> > The patch forces the .depend file to be regenerated if any of the
> > referenced files has been deleted.
> > 
> > Note that it has to use exists(file) because .PATH has to be applied.
> > (the shell read handles the continuation lines...)
> > 
> > Thoughts?
> 
> How much overhead does this add to a build? i.e. have you measured pre-patch
> and post-patch for a static tree?

Times for make depend in src/sys/arch/i386/stand:
new:       25.77 real        16.84 user        13.94 sys
old:       15.47 real        14.61 user         3.96 sys

I think the difference is almost entirely down to the shell doing
single character reads - and is more than I thought it would be.

FWIW an 'nbmake all' in the same directory is:
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Laight | 3 Nov 2003 13:19
Picon

Re: rebuilding stale .depend files

> > How much overhead does this add to a build? i.e. have you measured
> > pre-patch and post-patch for a static tree?
> 
> Times for make depend in src/sys/arch/i386/stand:
> new:       25.77 real        16.84 user        13.94 sys
> old:       15.47 real        14.61 user         3.96 sys
> 
> I think the difference is almost entirely down to the shell doing
> single character reads - and is more than I thought it would be.

Using:
deps != sed 's/^.*://;s/ \\$$//' .depend
(instead of getting the shell to do it) halves the overhead.
It would be even better if make didn't use /bin/sh to execute sed.

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 0 comments |
headers
Havard Eidnes | 3 Nov 2003 18:19
Picon

Re: rebuilding stale .depend files

> It gets rather anoying when a build fails because the old
> .depend file references a now deleted file.

Yep.

> The patch forces the .depend file to be regenerated if any of the
> referenced files has been deleted.

Please remember that the .depend file is regenerated from the
individual .d files these days, and the offending .d file does also
need to be regenerated.

Regards,

- Håvard
Permalink | Reply | 1 comment |

Gmane