NetBSD Problem Report #49214

From dholland@netbsd.org  Thu Sep 18 08:03:02 2014
Return-Path: <dholland@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 66B50CE692
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 18 Sep 2014 08:03:02 +0000 (UTC)
Message-Id: <20140918080302.2FBD914A223@mail.netbsd.org>
Date: Thu, 18 Sep 2014 08:03:02 +0000 (UTC)
From: dholland@netbsd.org
Reply-To: dholland@netbsd.org
To: gnats-bugs@gnats.NetBSD.org
Subject: make(1) parsing bug with dynamic sources
X-Send-Pr-Version: 3.95

>Number:         49214
>Category:       bin
>Synopsis:       make(1) parsing bug with dynamic sources
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    dholland
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 18 08:05:00 +0000 2014
>Last-Modified:  Fri Nov 28 20:21:30 +0000 2014
>Originator:     David A. Holland
>Release:        NetBSD 7.99.1 (20140918)
>Organization:
>Environment:
System: NetBSD homeworld.netbsd.org 6.1_STABLE NetBSD 6.1_STABLE (NBMAIL) #0: Tue Jun 10 18:49:40 UTC 2014 spz@franklin.NetBSD.org:/home/netbsd/6/amd64/obj/sys/arch/amd64/compile/NBMAIL amd64
Architecture: x86_64
Machine: amd64
>Description:

Observe the following:

   ------
% cat woops
blah: ;
foo: $(.TARGET:S/foo/mo oo/)
	echo $(.ALLSRC)
bar $(.TARGET:S/foo/mo oo/): blah
	echo $(.ALLSRC)
% make -f woops foo
make: Unclosed substitution for @ (/ missing)
make: don't know how to make oo/). Stop

make: stopped in [dir]
% make -f woops bar
echo blah
blah
%
   ------

The space inside the variable is only parsed correctly when the
variable is on the target side of the rule.

But there's a second problem: what does it even mean for $(.TARGET) to
be used on the target side of the rule? It's not sensible and produces
odd behavior. The unexpanded variable string becomes itself a rule
name, and then trying to use $(.TARGET) blows up because it's self-
referential:

   ------
% cat woops2
blah:;
foo $(.TARGET:S/foo/moo/): blah
	echo $(.ALLSRC)
bar $(.TARGET:S/bar/baz/): blah
	echo $(.TARGET)

% make -f woops2 '$(.TARGET:S/foo/moo/)'
echo blah
blah
% make -f woops2 '$(.TARGET:S/bar/baz/)'
Variable @ is recursive.

make: stopped in [dir]
   ------

This situation arises because $(.TARGET) and a handful of other rules
are allowed to be expanded dynamically in the sources list for each
target in a rule; therefore they're expanded late and not during the
main parsing pass.

However, it seems that someone accidentally added the code to
recognize them and call Var_Parse on them to properly find the end of
the variable reference to the targets half of the dependency rule
parser in ParseDoDependency instead of the source half. (This is
entirely understandable as the code's quite a maze.)

They aren't valid at all as targets and should be rejected if found on
the targets side.

A passing note that a problem might exist appeared in the PR 49085
patch from Jarmo Jaakkola, although this issue is otherwise unrelated
to that PR.

>How-To-Repeat:
as above
>Fix:

move the logic as needed

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: bin-bug-people->dholland
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Thu, 18 Sep 2014 08:19:45 +0000
Responsible-Changed-Why:
mine


>Unformatted:

Home	PR Database Search