headers
Valeriy E. Ushakov | 4 Feb 2006 16:21
Picon

Re: CVS commit: src/sys/sys

[Moved to tech-toolchain <at> ]

On Sat, Feb 04, 2006 at 08:58:12 +0000, David Laight wrote:

> On Sat, Feb 04, 2006 at 12:01:36AM +0000, Valeriy E. Ushakov wrote:
> > 
> > Module Name:	src
> > Committed By:	uwe
> > Date:		Sat Feb  4 00:01:36 UTC 2006
> > 
> > Modified Files:
> > 	src/sys/sys: endian.h
> > 
> > Log Message:
> > Move #include <machine/bswap.h> back into the same nesting inside ifdefs.
> > Assembler sources don't care about optimized inline versions of bswap.
> > Undo the changes to the namespace.
> > Hi, dsl.
> 
> Maybe we should use '#if __ASM' instead of '#ifdef LOCORE' ?

_LOCORE has been used throughout the tree for ages.  Why change it now?

SY, Uwe
--

-- 
uwe <at> ptc.spbu.ru                         |       Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/          |       Ist zu Grunde gehen
Permalink | Reply | 0 comments |
headers
Emmanuel Dreyfus | 5 Feb 2006 13:11
Picon

building i386 code in an amd64 kernel

Hello

For COMPAT_LINUX32, I need to build the i386 linux_sigcode in an amd64
kernel. How can I do this with our build system?

--

-- 
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu <at> netbsd.org
Permalink | Reply | 2 comments |
headers
Izumi Tsutsui | 5 Feb 2006 15:57
Picon
Gravatar

new ld got signal 11 in sys/arch/ews4800mips/stand/bootxx_bfs

After updating src on 20060204 to try binutils-2.16.1,
ews4800mips builds on NetBSD/i386 -current fails:

---
# pwd
/usr/src/sys/arch/ews4800mips/stand/bootxx_bfs
# /usr/tools/mipseb/bin/nbmake-ews4800mips
making sure the kern library is up to date...
`libkern.a' is up to date.
/usr/tools/mipseb/bin/mipseb--netbsd-ld -T \
/usr/src/sys/arch/ews4800mips/stand/bootxx_bfs/../common/bootxx.ldscript \
-S -N  -o bootxx_bfs.elf fileread_bfs.o entry.o bootxx.o \
boot_device.o floppy_2d.o floppy_2hd_ibmpc.o \
/usr/src/sys/arch/ews4800mips/stand/bootxx_bfs/obj.ews4800mips/lib/kern/libkern.a
*** Signal 11

Stop.
nbmake: stopped in /usr/src/sys/arch/ews4800mips/stand/bootxx_bfs
# gdb /usr/tools/mipseb/bin/mipseb--netbsd-ld obj.ews4800mips/mipseb--netbsd-l.core
GNU gdb 5.3nb1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386--netbsdelf"...
Core was generated by `mipseb--netbsd-l'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/libexec/ld.elf_so...done.
Loaded symbols for /usr/libexec/ld.elf_so
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Husemann | 5 Feb 2006 18:43
Picon

Re: building i386 code in an amd64 kernel

On Sun, Feb 05, 2006 at 01:11:21PM +0100, Emmanuel Dreyfus wrote:
> For COMPAT_LINUX32, I need to build the i386 linux_sigcode in an amd64
> kernel. How can I do this with our build system?

You need to pass -32 to as.

I would guess something like

  CPUFLAGS.linux_sigcode.S = -32

should do it (since we don't seem to have a per-filenam AFLAGS variant).

Martin
Permalink | Reply | 1 comment |
headers
Matthias Drochner | 6 Feb 2006 14:24
Picon
Picon
Favicon

Re: building i386 code in an amd64 kernel


martin <at> duskware.de said:
> You need to pass -32 to as. 

Or a .code32 pseudo-op I believe.

best regards
Matthias
Permalink | Reply | 0 comments |
headers
Nick Hudson | 6 Feb 2006 18:31

Re: new ld got signal 11 in sys/arch/ews4800mips/stand/bootxx_bfs

On Sunday 05 February 2006 14:57, Izumi Tsutsui wrote:
> After updating src on 20060204 to try binutils-2.16.1,
> ews4800mips builds on NetBSD/i386 -current fails:
[...]

> Any clue? Wrong ldscript?

binutils-current ld fails with

	ld: error: no memory region specified for loadable section `.rel.dyn'

I'll see if I can find the change that stops ld from crashing.

Nick
Permalink | Reply | 0 comments |
headers
Simon J. Gerraty | 12 Feb 2006 07:20

Re: make: allow setting variable mods in variable?

No one has any thoughts on this?
Any one have objections to allowing this?

>I occasionally have a complex set of variable mods that I want to use 
>in multiple places and it would be handy to specify these in variable
>as in (trivial example I know):

>MODS=S,A,a,

>V=Abc

>all:
>	 <at> echo V=${V:${MODS}}

>it would be nice if this printed 'abc' rather than an error about $
>being an unknown modifier.  The patch below does this (and all the
>unit tests still pass), but I'm not convinced it is right wrt cleanup.
>I'd appreciate a 2nd opinion.

>Thanks
>--sjg

>--- var.c.~1~	Sat Sep  3 15:15:09 2005
>+++ var.c	Fri Jan 20 16:58:52 2006
> <at>  <at>  -1890,6 +1890,7  <at>  <at>  Var_Parse(const char *str, GNode *ctxt, 
> 	  Boolean *freePtr)
> {
>     const char	   *tstr;    	/* Pointer into str */
>+    const char	   *tstr2;	/* Secondary tstr if we need to recurse  */
>     Var	    	   *v;	    	/* Variable in invocation */
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alan Barrett | 12 Feb 2006 07:48
Gravatar

Re: make: allow setting variable mods in variable?

On Sat, 11 Feb 2006, Simon J. Gerraty wrote:
> No one has any thoughts on this?

> >MODS=S,A,a,
> >V=Abc
> >all:
> >	 <at> echo V=${V:${MODS}}

Looks good to me.

--apb (Alan Barrett)
Permalink | Reply | 0 comments |
headers
Simon J. Gerraty | 12 Feb 2006 07:17

Re: stale dependency files breaking build considered harmful

>I updated sources on a machine that hadn't been updated since 12/1 or
>so, and on running build.sh the build failed because in two places
>(named, libc) files that were in a .depend file were no longer
>present.  It seems that 'dependall' reads .depend and fails before
>regenerating .depend, and that 'cleandir' is necessary to recover.
>Actually, I was able to recover by deleting .depend files.

>It is unfortuante that this sort of lossage occurs.  I'm not
>complaining about files being removed - that's normal.  I wonder if

There's a trade off to make, between speeding up the average build
and avoiding this sort of lossage.  Some years ago, our build at work 
ditched any sort of separate dependency management - the .depends are 
generated as a side effect of compiling.  True, as you note, this will
result in a build stoppage when a header is removed or renamed, but
that is quite a rare event (compared to the 100's of builds done daily).

Even this lossage is easily dealt with by the simple strategy of
running the build via a script which spots failure, idendifies the directory
where the build failed, (cd thatdir && make clean), then start again.
Of cours that doesn't help unless the build phases can be easily separated.

Absent all that, perhaps a target to do the .depend cleanup you descirbed
to cover the case where a tree is being built for the first time in months,
would be preferable to paying that overhead for every build.

--sjg
Permalink | Reply | 1 comment |
headers
Alan Barrett | 12 Feb 2006 08:08
Gravatar

make: making .WAIT recursive

As has been mentioned by others, .WAIT doesn't do what we want.

Given

	foo: a .WAIT b	; echo foo
	a:		; echo a
	b: b1 b2	; echo b
	b1:		; echo b1
	b2:		; echo b2

a parallel make will always make "a" before making "b", but it will not
always make "a" before making "b1" or "b2".

There's a similar issue with .ORDER.  Given

	foo: a b	; echo foo
	.ORDER: a b
	a:		; echo a
	b: b1 b2	; echo b
	b1:		; echo b1
	b2:		; echo b2

the existing behaviour is identical to the existing behaviour 
if the .WAIT example.

Would it be reasonable to make ".WAIT" apply recursively to all children
of the targets on the right hand side, but to leave ".ORDER" with its
existing non-recursive behaviour?  Or would it be better to retain the
existing behaviour of both .WAIT and .ORDER, but add new recursive
variants of both (say ".WAITRECURSIVE" and ".ORDERRECURSIVE", or better
(Continue reading)

Permalink | Reply | 33 comments |

Gmane