From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) by sourceware.org (Postfix) with ESMTPS id 42B493858004 for ; Tue, 3 Nov 2020 09:13:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 42B493858004 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rasmusvillemoes.dk Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rv@rasmusvillemoes.dk Received: by mail-ed1-x543.google.com with SMTP id ay21so4108070edb.2 for ; Tue, 03 Nov 2020 01:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=e2VWo4AVCG0p9A10t68sOV5kA+9NUiINAwOX0aH9Wnw=; b=J3fm6XrICTkMZvLbqGCk44OCCWsmBLnrPHJ5cic/irbzyC1l7ZP+rIp63TsPPdzrHA 5hfCJoB7PJFn1jGYeCs0dKrgZyBW6AdANc+ONwcD3R1zHjqvM0F1/lHYXMjUWK4t31vw ai9zUL6HeyWtnZoXsqjRZftoBmlFyHLkoE9qo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=e2VWo4AVCG0p9A10t68sOV5kA+9NUiINAwOX0aH9Wnw=; b=AgnyiORWGv2zsTTphS6Txxq3fGRVsHAx9U7bOtJjG7u8EhIoqTAbZ62NTD+kJec9sZ RIKOc2OHJGUrsgQR10oapJYdH84fBiAADCzgNl/k5MMuqTXfoJiZuS4sKChdxMS9Vmxz RZBtBgH7NI3La+IBrKV5j1nuzrDOthRr84dRDmSqj3PTcqJtjLNa/4AV1os+RxVq5jcn 6IQdeI6NSLaJlxiesORniQrtPgjXDiCR9ZAIua7bufdiI0ga7PYLuYyUKB8p8zYxHA1b 4FUKWXm9KI4vr6iiKNKl3hlm/Gz0YSOHhmKYTbUy0dr8LHKN0rXQfzycvF9Wfb+2zCqx RNpg== X-Gm-Message-State: AOAM531okmLJTRbGgvWEdNfPRskZHNSyl6+3JMfUMWnXmelglOhPbYML 246KOUpA6pJz2KCm6i0eo8bvvw9thy1VZTs8Gdw= X-Google-Smtp-Source: ABdhPJyTRAZbtk2lFO29kldi1oP5o7fH5fyfUiEPfo2QT/o/7EKN/r2WRhfTHsQVbRcB82xu2Z00aw== X-Received: by 2002:aa7:cd8e:: with SMTP id x14mr21478943edv.173.1604394826097; Tue, 03 Nov 2020 01:13:46 -0800 (PST) Received: from [172.16.11.132] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id t3sm11459439edv.59.2020.11.03.01.13.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Nov 2020 01:13:45 -0800 (PST) Subject: Re: [PATCH] allow empty string as argument to -Map To: Nick Clifton , binutils@sourceware.org References: <20200526070140.25380-1-rv@rasmusvillemoes.dk> <01faf722-46fc-e0a6-6a58-2490e07937d6@redhat.com> <7ad73b09-c551-9a17-f0fa-0839919158b4@rasmusvillemoes.dk> <0fc094c4-c915-511c-c5da-2654811fbeec@redhat.com> <2ec24e2e-42aa-162f-f8c4-f7588956093b@redhat.com> <2e944a37-8d3d-17a2-ea94-97782972678a@rasmusvillemoes.dk> <890f98cc-8c4d-8286-890c-d8071669f4a1@redhat.com> From: Rasmus Villemoes Message-ID: <4c7c5e55-33d3-ab28-c220-728f7e13d6a9@rasmusvillemoes.dk> Date: Tue, 3 Nov 2020 10:13:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <890f98cc-8c4d-8286-890c-d8071669f4a1@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 09:13:49 -0000 On 30/10/2020 17.35, Nick Clifton wrote: > Hi Rasmus, > >>> My feeling is that we ought to extract the basename of any output file >>> and use that, and always honour the directory name specified in the -Map >>> option. > >> However, the problem with using (only) the basename of the -o argument >> is that the build (not the single ld invocation, but the surrounding >> build system) could produce several binaries of the same name in >> different directories, so we (a) would clobber the .map files and (b) >> cannot tell which binary the single surviving .map belongs to. > > That does not sound likely to me. In order for a clobber to occur > the user would have to build multiple binaries with the same output > name and using the same map directory. But in order for the output > binaries not to clobber each other they would have to be built into > different output directories. ie: > > -o foo/bar -Map=/mapdir > -o baz/bar -Map=/mapdir > > It seems to me that this is only likely to occur when creating multiple > versions of the same binary (eg with different ABI options) and the map > dir is being automatically added to the build. (If the user added the > -Map option then they would almost certainly include the discriminating > directory name as well). Yes, exactly, please see my original use case: I'd like some way to get the build to produce map files for all the binaries/solibs etc. generated, without patching each individual project's build system and figuring out where to hook in. This is in the context of building an embedded system using Yocto. So apart from the job of looking at each piece of software (systemd, util-linux, busybox, glibc, ....) and understand how that gets built, I also have to create .patch files, and temporarily add them to the individual recipes. Most build systems do honour LDFLAGS set from outside, so I'd like to do that LDFLAGS += "-Map=something" globally. But also why an environment variable understood by ld itself would be even more convenient, as that wouldn't even rely on the build system passing on inherited LDFLAGS. > >> -Map=AUTO > > Hmm. maybe. > > Another possibility is to have the linker not overwrite an existing > map file, but instead append a timestamp/random number instead. So > > -o foo -Map=. > > would create ./foo.map if it does not exist, or .foo.202010301630.map > if foo.map exists. As distinguishing between these map files, I would > assume that looking at their contents, and seeing the input files mentioned > should be enough. I suppose you're right about the chance of different binaries in different directories having the same name is quite low, and that, in case of a clash, one could distinguish based on contents. But then the problem is that when one rebuilds without cleaning the destination directory, we're actually guaranteed to hit that clash, even if no binaries clash with each other. I think it would add too much complexity and potential for confusion. And actually, sometimes passing "-Map=." wouldn't work; the build system could have a read-only source directory be CWD and have all output go to some other directory. [*] So I still think that having _some way_ to ask ld to create a map file named "<-o argument>.map" is the most convenient; no issues with the target directory possibly not existing or not being writable; no issues with name clashes; the .map gets automatically truncated/overwritten when the binary gets rebuilt. > >> -Map argument is given, but the env variable LDAUTOMAP is set, > > I am strongly against environment variables, if they can be avoided. > I know that they linker does use some, but I consider this to be a > mistake. The bug problem with environment variables is that they make > generating bug reports really hard. Most users never include > environment variables in their reports, and often they do not even > know that they are there. So I agree with you in general. But I'd also argue that for the case of Map files, which are mostly/only for diagnostics, a developer setting LDAUTOMAP would know what he's doing. But if I can have some way of doing [*] via the command line, that would also work for the majority of cases. And instead of a magic -Map= value, it could also simply be a new --automap option (with an explicit -Map= taking precedence). Rasmus