[PATCH] allow empty string as argument to -Map

[Nick Clifton]

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)

Thoughts ?

Cheers
  Nick