@magicus thank you for looking at this, in hindsight I should have pinged you
to review this as well.
Technically Erik's approval is enough, but I do appreciate if I can get
at least 24h to have a look at build changes that touches delicate build
logic. It usually takes more than one of us to spot all potential issues
with such changes.
So a few thoughts, first one thing that crossed my mind which is the ifeq logic here
should instead test ALLOW_ABSOLUTE_PATHS_IN_OUTPUT, exactly like the setting of
-fdebug-prefix-map and -ffile-macro-prefix already do. In fact just changing to using
that maybe sufficient? ie.only use relative paths here when
ALLOW_ABSOLUTE_PATHS_IN_OUTPUT is false, ie. it is a "release" type build and
not a developer/debug build, where CWD cmdlines are preferable. What's your thought on
that?
That sounds like even more of a step backwards, making even more command
lines relative that could have been absolute.
We want to avoid relative paths as far as at all possible. In fact, we
did not have relative paths at all in the build for quite a long time,
but was forced to introduce it to handle some specific shortcomings in
certain combinations of build tools and circumstances. I'm still hoping
these issues will someday be resolved upstream, and that we can remove
those exceptions.
I did search google & bugzilla for any gcc bug, but didn't find anything.
However, i've just found this issue:
https://github.com/gcc-mirror/gcc/commit/d12153046816f955e74943af7089d30de6a00e19
which maybe related, although looks to do the opposite of what we want, although that
maybe just because I don't understand it! However, it is the .file <path> dwarf
value for the assembly stripped debuginfo that has the full object path that isn't
getting stripped, and I think we do use -flto. This fix is in gcc 11.2, i'm testing
using gcc 10.3.
I'm going to do two things, recreate the problem again, double check the
assembly file compile options, with gcc 10.3, then try again with gcc 11.2..
@magicus just saw your above post, interesting, i'll add I think gcc -v to my
above testing, to see what gcc is passing through to the actual compile,
apparently using verbose removes anything that gets removed for assembly,
ie.anything that is not relavent
I think we're calling the GNU assembler using the gcc frontend. It might
behave badly about passing arguments properly. I found one bug related
to this (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93371) but it
seems to claim -fdebug-prefix-map should work (and only
-ffile-prefix-map, which we do not use, should be broken).
We might need to reconsider that to call as directly, if it works when
we pass --debug-prefix-map directly. I have no complete overview of what
such a change might bring along, though.
/Magnus
