[PATCH] allow empty string as argument to -Map

[Rasmus Villemoes]

On 29/10/2020 16.52, Nick Clifton wrote:
> Hi Rasmus,
> 
>> Sorry for resurrecting this, and not thinking of this sooner, but it
>> just occurred to me that passing -Map=. only works automatically if the
>> -o argument is a relative path. If the -o argument is absolute, that
>> will lead to trying to create a map file at, say,
>> ".//home/ravi/some/project/foo.so.out", which won't work given that the
>> working directory is very likely already "/home/ravi/some/project". One
>> could pass -Map=/, but that would then break in the other direction when
>> the -o argument is relative.
> 
>> Since the main point of this is to be able to just do "LDFLAGS +=
>> <something>" to always get a linker map for each output artifact,
>> without hooking into each individual project's build system and figuring
>> out how to add that flag to each build target, can we special-case . to
>> always mean "generate a map file next to the output file", i.e. in that
>> case check whether output_filename starts with '/' and if so do not
>> prepend "./" (but still append ".map", of course)? Or is there some
>> better way?
> 
> Hmm, I think that that would be confusing.  Suppose for example that
> the link involved "-Map=.. -o /foo/bar".  Where would the user expect
> the map file to appear ?  In ../foo/bar.map or ../bar.map or /foo/bar.map ?
> 
> 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.  ie:
> 
>   -Map=. -o foo       => creates ./foo.map
>   -Map=. -o /foo      => creates ./foo.map 
>   -Map=. -o /foo/bar  => creates ./bar.map
>   -Map=/ -o foo       => creates /foo.map
>   -Map=/ -o /foo/bar  => creates /bar.map
>   -Map=/foo -o bar    => creates /foo/bar.map
>   -Map=../ -o foo/bar => creates ../bar.map.  (NB/ does not create ../foo/bar.map)

Yes, that's another problem with the current logic, even for relative -o
arguments: If one specifies -Map=maps/, it may be that maps/ exists, but
for -o foo/bar, we'd try to create maps/foo/bar.map - the Makefile (or
whatnot) obviously ensures foo/ exists, but maps/foo/ would not
automatically be created.

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.

So I don't think there's any way around having _some_ magic value mean
'take the -o argument, append ".map"'. That magic value can be almost
anything

-Map=%
-Map=/ # nobody would put stuff in the root directory
-Map=AUTO

(and if anybody really wants a map file called AUTO, they could say
-Map=./AUTO).

> Thoughts ?

A whole other option, which may be even easier to hook into arbitrary
build systems (not everybody honours/forwards LDFLAGS), is to say "If no
-Map argument is given, but the env variable LDAUTOMAP is set, use the
-o argument with .map appended". ld does already look at a few
environment variables that can be overridden with options, so it's not
completely unprecedented.

Rasmus