Andrew Doran | 1 Apr 22:33 2011
Picon

Re: ld.elf_so locking

On Mon, Mar 14, 2011 at 04:37:21PM +0100, Joerg Sonnenberger wrote:

> Comments?

Only a few right now..

> There are currently two situations left where a recursion would currently
> result in a dead lock: a signal handler or constructor using __tls_get_addr
> requiring memory allocation when already in ld.elf_so and a signal
> handler occuring during exclusively locked calls like dlopen trying to
> access a shared lock e.g. to lazily resolve a relocation.
> 
> The second can be mostly be adressed by using sigprocmask in the

For stuff like that one idea is to have the signal mask directly in the
_lwp_ctl area, so that sigprocmask() isn't any kind of performance concern. 
The signal mask is thread private state in the kernel with a couple of
exceptions, Oe can be worked around and I think the other relates to SA (and
so can die).  As a perhipheral benefit this could be a nice boost to some
workloads since sigprocmask() is called a lot.

On a related note is there a thread-private area that we can reserve to
point to the _lwp_ctl block?

> +static volatile bool _rtld_mutex_may_recurse;
> +

Prefer "int" or sigatomic_t as bool may be sub-word sized and thus cause
atomicity problems.  Maybe this is not a concern (although volatile
suggests it is).
(Continue reading)

Joerg Sonnenberger | 2 Apr 03:28 2011
Picon

Hashing support for make

Hi all,
the attached patch implements the :th modifier. It is intended to cut
down the output for MKREPRO=yes. This reduces the amount of IO for
verbose builds and also avoids copying data, so it should over all be at
least performance neutral.

The hash function is Murmurhash3, choosen because it is compact, fast and
relatively collision resistent.

Joerg
Attachment (hash.diff): text/x-diff, 5244 bytes
David Holland | 2 Apr 05:54 2011
Picon

Re: Hashing support for make

On Sat, Apr 02, 2011 at 03:28:36AM +0200, Joerg Sonnenberger wrote:
 > the attached patch implements the :th modifier. It is intended to cut
 > down the output for MKREPRO=yes. This reduces the amount of IO for
 > verbose builds and also avoids copying data, so it should over all be at
 > least performance neutral.

Other than the name of the modifier, I like it.

As for the name of the modifier, how about just "hash"? While ~all of
the existing modifiers are cryptic, they're the names of operations
and transforms, and I think it's generally better for them to be like
function names than like sed commands.

Changing old ones is problematic, but I think ideally new ones should
be words.

--

-- 
David A. Holland
dholland <at> netbsd.org

Joerg Sonnenberger | 6 Apr 03:00 2011
Picon

Moving to --sysroot=$D for compiler invocations

Hi all,
attached is a patch to clean up some issues with the --sysroot support
in our GCC patches. It also changes the infrastructure to switch to
using --sysroot=$D instead of the combination of -B, -nostdinc,
-isystem, -nostdlib, -L, -Wl,-rpath etc. This makes it a lot cleaner and
easire to integrate other modern compiler drivers.

There is one down side: it currently breaks PCC. I'm working on that
separately, but PCC already has issues with the use of two -B options,
so I don't consider this a show stopper.

Joerg
Attachment (src.diff): text/x-diff, 15 KiB
der Mouse | 8 Apr 18:54 2011

make(1) variable expansion inconsistency

Quite some time back, I wrote about problems building some software
because make(1) was overriding Makefile-set variables with
command-line-set variables only sometimes.

This is all on 4.0.1.

I believe I know when the "sometimes" is.  Consider this Makefile:

	V = makefile
	foo: xyz-${V}
	F:= xyz-${V}
	bar: ${F}
	xyz-cmd: .PHONY
		echo building xyz-cmd
	xyz-makefile: .PHONY
		echo building xyz-makefile

Now, consider "make V=cmd foo" and "make V=cmd bar".  They should be
identical, right?

Nope.

% make V=cmd foo
echo building xyz-cmd
building xyz-cmd
% make V=cmd bar
echo building xyz-makefile
building xyz-makefile
% 

(Continue reading)

der Mouse | 8 Apr 20:57 2011

Re: make(1) variable expansion inconsistency

A little while ago, I wrote (of make(1)) that

> It appears that variable expansion on dependency lines allows
> command-line settings to override Makefile settings, but that
> variable expansion when doing a var:=value setting doesn't.

PR now filed: toolchain/44844.  It includes the fix I'm using.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Joerg Sonnenberger | 8 Apr 21:17 2011
Picon

Re: make(1) variable expansion inconsistency

On Fri, Apr 08, 2011 at 12:54:47PM -0400, der Mouse wrote:
> Now, consider "make V=cmd foo" and "make V=cmd bar".  They should be
> identical, right?

$ nbmake-amd64 V=cmd bar
echo building xyz-cmd
building xyz-cmd

Works for me on current. I doubt anyone cares about fixes for bugs
specific to netbsd-4's make...

Joerg

der Mouse | 8 Apr 21:45 2011

Re: make(1) variable expansion inconsistency

> Works for me on current.  I doubt anyone cares about fixes for bugs
> specific to netbsd-4's make...

Last I heard, NetBSD still supported 4.x (and will until 6.0 comes out).

Is my understanding wrong?

Or does NetBSD no longer care about bugfixes for supported software?

Or what?

(Your jump from "not present on current" to "specific to netbsd-4"
leads to an incorrect conclusion as well as being logically invalid.
The bug _isn't_ specific to netbsd-4's make; it appears in 1.4T and
probably everything in between, quite likely even some other BSD-family
makes.  But all this is a side note.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Simon J. Gerraty | 9 Apr 01:34 2011
Picon

make: time stamps

In my build at work, we like to have timestamps at various places,
to help track where all the time is going.
This is currently done by running date(1), but it would be more
efficient to do it from make itself.
The patch below adds :tL (localtime) and :tU (UTC) as modifiers to cause
us to treat the current value as a fmt string for strftime.

So:

$ bmake -r -V '${The time is %c:L:tU}' -V '${Which is %Y-%m-%d %T %Z:L:tL}'
The time is Fri Apr  8 23:31:01 2011
Which is 2011-04-08 16:31:01 PDT
or
TIME_FMT=' <at>  %s [%Y-%m-%d %T]'
bmake -V '${TIME_FMT:tL}'                               <
 <at>  1302305562 [2011-04-08 16:32:42]

Index: var.c
===================================================================
RCS file: /cvs/juniper/src/buildtools/bmake/var.c,v
retrieving revision 1.37
diff -u -p -r1.37 var.c
--- var.c	7 Mar 2011 17:22:18 -0000	1.37
+++ var.c	8 Apr 2011 23:21:53 -0000
 <at>  <at>  -2291,6 +2291,21  <at>  <at>  VarChangeCase(char *str, int upper)
    return Buf_Destroy(&buf, FALSE);
 }

+static char *
+VarStrftime(const char *fmt, int zulu)
(Continue reading)

Simon J. Gerraty | 9 Apr 07:05 2011
Picon

Re: make(1) variable expansion inconsistency

der Mouse writes:
>Last I heard, NetBSD still supported 4.x (and will until 6.0 comes out).

Whether that is so or not, is probably irrelevant in this case.

4.x's make(1) is clearly adequate for building 4.x

Anyone who wants more, can easily either build -current make,
or bmake (basically the same thing).

--sjg


Gmane