[PATCH] allow empty string as argument to -Map

[Rasmus Villemoes]

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