Use -fdebug-prefix-map in preference to -ffile-prefix-map, as it's
available in earlier toolchain versions. But use it together with
-fmacro-prefix-map (if available) for hypervisor build, otherwise it
still contains some paths in out-of-tree builds.

The out of tree build requires -fdebug-prefix-map mapping for both source
dir and object dir - otherwise the latter is included (2 occurrences) in
xen-syms. Note the ./xen path for out of tree builds may not be strictly
correct choice, but it's consistent across the tree, and just require
starting debugger from the source, not object, directory.

Ensure to have a realpath for XEN_ROOT else it fails to substitute
properly paths in strings sections.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
v2:
- re-add chunk wrapping XEN_ROOT with realpath; simplify it with patsubst
  in hypervisor makefile
- fix cc-option-add usage
- extend commit message
- claim authorship of the patch, as no single line remained from the
  original version
- drop change in xen/arch/x86/Makefile
---
 tools/Makefile | 2 +-
 tools/Rules.mk | 2 ++
 xen/Makefile   | 6 +++++-
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index 6ecf7c0da821..80ec82a15979 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -1,4 +1,4 @@
-XEN_ROOT = $(CURDIR)/..
+XEN_ROOT = $(realpath $(CURDIR)/..)
 
 export PKG_CONFIG_DIR = $(CURDIR)/pkg-config
 
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 725c3c32e9a2..428fce094819 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -166,6 +166,8 @@ endif
 CFLAGS-$(CONFIG_X86_32) += $(call cc-option,$(CC),-mno-tls-direct-seg-refs)
 CFLAGS += $(CFLAGS-y)
 
+$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(realpath $(XEN_ROOT))=.)
+
 CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
 
 INSTALL_PYTHON_PROG = \
diff --git a/xen/Makefile b/xen/Makefile
index 49da79e10fb4..015255971804 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -208,7 +208,7 @@ VPATH := $(srctree)
 
 export srctree objtree VPATH
 
-export XEN_ROOT := $(abs_srctree)/..
+export XEN_ROOT := $(patsubst %/xen,%,$(abs_srctree))
 
 # To make sure we do not include .config for any of the *config targets
 # catch them early, and hand them over to tools/kconfig/Makefile
@@ -412,6 +412,10 @@ ifneq ($(CONFIG_CC_IS_CLANG),y)
 CFLAGS += -Wa,--strip-local-absolute
 endif
 
+$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(abs_objtree)=./xen)
+$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(abs_srctree)=./xen)
+$(call cc-option-add,CFLAGS,CC,-fmacro-prefix-map=$(abs_srctree)=./xen)
+
 AFLAGS += -D__ASSEMBLY__
 
 $(call cc-option-add,AFLAGS,CC,-Wa$$(comma)--noexecstack)
-- 
2.49.0

On 04.09.2025 13:41, Marek Marczykowski-Górecki wrote:
> Use -fdebug-prefix-map in preference to -ffile-prefix-map, as it's
> available in earlier toolchain versions. But use it together with
> -fmacro-prefix-map (if available) for hypervisor build, otherwise it
> still contains some paths in out-of-tree builds.

I consider it wrong not to use -ffile-prefix-map when available. That
already covers more than "debug" and "macro", and it may gain further
functionality.

> The out of tree build requires -fdebug-prefix-map mapping for both source
> dir and object dir - otherwise the latter is included (2 occurrences) in
> xen-syms.

As indicated in a reply to Andrew on the thread hanging off of my
patch - I think whether to remove those wants to be left to the user.

> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -1,4 +1,4 @@
> -XEN_ROOT = $(CURDIR)/..
> +XEN_ROOT = $(realpath $(CURDIR)/..)
>  
>  export PKG_CONFIG_DIR = $(CURDIR)/pkg-config
>  
> diff --git a/tools/Rules.mk b/tools/Rules.mk
> index 725c3c32e9a2..428fce094819 100644
> --- a/tools/Rules.mk
> +++ b/tools/Rules.mk
> @@ -166,6 +166,8 @@ endif
>  CFLAGS-$(CONFIG_X86_32) += $(call cc-option,$(CC),-mno-tls-direct-seg-refs)
>  CFLAGS += $(CFLAGS-y)
>  
> +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(realpath $(XEN_ROOT))=.)

Here and below - no need to use cc-option-add for -fdebug-prefix-map,
which all permissible compilers support.

Further, again as per reply to Andrew on the thread hanging off of my
patch - I don't view it as desirable to leave the tools/ prefix in
place, or e.g. for libraries, the entire tools/libs/<subdir>/ part.
Imo every binary should have only the path (if any) from its own source
root left. (And yes, how to deal with e.g. shared include files isn't
quite clear to me, yet. Maybe we actually need to pass two options.)

> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -208,7 +208,7 @@ VPATH := $(srctree)
>  
>  export srctree objtree VPATH
>  
> -export XEN_ROOT := $(abs_srctree)/..
> +export XEN_ROOT := $(patsubst %/xen,%,$(abs_srctree))

Unlike for tools/, is this still needed here? You don't use XEN_ROOT below.

> @@ -412,6 +412,10 @@ ifneq ($(CONFIG_CC_IS_CLANG),y)
>  CFLAGS += -Wa,--strip-local-absolute
>  endif
>  
> +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(abs_objtree)=./xen)
> +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(abs_srctree)=./xen)
> +$(call cc-option-add,CFLAGS,CC,-fmacro-prefix-map=$(abs_srctree)=./xen)

I disagree with leaving any xen/ prefix there. That's not how in-tree builds
name files; everything there is relative to xen/.

I also don't really see a point in using . in the substitution (similarly
for the toolstack, but there I have less to say).

Finally, why pass two identical, possibly long options for in-tree builds
(where $(abs_objtree) == $(abs_srctree))?

Below I'll reproduce my own further re-worked patch. It's not quite ready
for v2 submission yet, I expect though. For example, the actual Kconfig
portion is still missing. Whether the @SRC@ and @BLD@ parts actually make
sense (or what to replace them by) I'm also unsure about. If nothing else
they may need replacing by plain .

Jan

build: avoid absolute paths in executables

For in-tree builds relative paths are used in most cases, whereas for out-
of-tree builds in various situations absolute ones come into play. The
extra paths can be long, wasting space and e.g. serial line bandwidth.
They would also get in the way of location-independent reproducible
builds. Leverage newer gcc's (and Clang's) ability to "remap" file names.
For older gcc fall back to using the option affecting debug info only.

For the few absolute paths appearing in in-tree builds' debug info, use
the generally available option, conditional upon a new Kconfig control

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Of course we may want to consider putting this in the top-level Config.mk,
to also affect other sub-trees (presently mainly/only affecting debug
info, for which even gcc5 already supports -fdebug-prefix-remap=).

As to a Fixes: tag, I wasn't quite sure whether to "blame" the
introduction of out-of-tree builds.

Note that at least in the gcc5 I'm testing with the (limited) effect is
further undermined by the compiler emitting the specified command line
options into debug info, thus still leaving references to the absolute
directories in place.

For the mentioned gcc15 issue see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121788.
---
v2: Use $(abs_srctree). Introduce DEBUG_INFO_REL_PATHS.

--- a/xen/Makefile
+++ b/xen/Makefile
@@ -461,7 +461,21 @@ CFLAGS += -flto
 LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
 endif
 
+CFLAGS-$(CONFIG_DEBUG_INFO_REL_PATHS) += -fdebug-prefix-map=$(abs_srctree)=@SRC@
+
 ifdef building_out_of_srctree
+    # Need to add to CFLAGS-y here, as gcc checks later options before earlier
+    # ones, and we want in particular the latter one(s) here to be checked
+    # first.
+    CFLAGS-$(CONFIG_DEBUG_INFO_REL_PATHS) += -fdebug-prefix-map=$(abs_objtree)=@BLD@
+    CFLAGS-y += $(call cc-option,$(CC),-ffile-prefix-map=$(abs_srctree)/=)
+    # While -ffile-prefix-map= implies -fdebug-prefix-map=, we need to use the
+    # latter explicitly: Up to at least gcc15 the compiler specs translate all
+    # -ffile-prefix-map= ahead of all -fdebug-prefix-map= when invoking the
+    # the assembler for *.S files, thus breaking our intended ordering.
+    # (Otherwise the option below could be passed as 3rd [fallback] argument to
+    # cc-option above.)
+    CFLAGS-y += -fdebug-prefix-map=$(abs_srctree)/=
     CFLAGS += -I$(objtree)/include
     CFLAGS += -I$(objtree)/arch/$(SRCARCH)/include
 endif

On Thu, Sep 04, 2025 at 02:58:20PM +0200, Jan Beulich wrote:
> On 04.09.2025 13:41, Marek Marczykowski-Górecki wrote:
> > Use -fdebug-prefix-map in preference to -ffile-prefix-map, as it's
> > available in earlier toolchain versions. But use it together with
> > -fmacro-prefix-map (if available) for hypervisor build, otherwise it
> > still contains some paths in out-of-tree builds.
> 
> I consider it wrong not to use -ffile-prefix-map when available. That
> already covers more than "debug" and "macro", and it may gain further
> functionality.

I asked about that on v1 and got ambiguous answer suggesting the opposite:
https://lore.kernel.org/xen-devel/0370c0eb1fd9ac00acab016792132fa0b943d384.1742317309.git-series.marmarek@invisiblethingslab.com/T/#m74a8883835e30fb74a85b07a7b14507ee52e7c65


> > The out of tree build requires -fdebug-prefix-map mapping for both source
> > dir and object dir - otherwise the latter is included (2 occurrences) in
> > xen-syms.
> 
> As indicated in a reply to Andrew on the thread hanging off of my
> patch - I think whether to remove those wants to be left to the user.
> 
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -1,4 +1,4 @@
> > -XEN_ROOT = $(CURDIR)/..
> > +XEN_ROOT = $(realpath $(CURDIR)/..)
> >  
> >  export PKG_CONFIG_DIR = $(CURDIR)/pkg-config
> >  
> > diff --git a/tools/Rules.mk b/tools/Rules.mk
> > index 725c3c32e9a2..428fce094819 100644
> > --- a/tools/Rules.mk
> > +++ b/tools/Rules.mk
> > @@ -166,6 +166,8 @@ endif
> >  CFLAGS-$(CONFIG_X86_32) += $(call cc-option,$(CC),-mno-tls-direct-seg-refs)
> >  CFLAGS += $(CFLAGS-y)
> >  
> > +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(realpath $(XEN_ROOT))=.)
> 
> Here and below - no need to use cc-option-add for -fdebug-prefix-map,
> which all permissible compilers support.

Ok.

> Further, again as per reply to Andrew on the thread hanging off of my
> patch - I don't view it as desirable to leave the tools/ prefix in
> place, or e.g. for libraries, the entire tools/libs/<subdir>/ part.
> Imo every binary should have only the path (if any) from its own source
> root left. (And yes, how to deal with e.g. shared include files isn't
> quite clear to me, yet. Maybe we actually need to pass two options.)

I don't think it's valid to strip arbitrary prefixes from debug symbols,
especially in tools. This will break some automated tools that try to match
coredumps (and similar) to source code and sometimes even debug symbols
too. But even for manual usage, having to jump between directories (I'm
not sure if gdb supports multiple source dirs at once?) just because you
happen to debug a binary that use more of libraries isn't exactly
desirable.
I think the paths in debug symbols and similar should match the layout
in the source repository, not a subset of it.

Theoretically this doesn't apply to the hypervisor yet, as I'm not aware
of any tool processing xen memory dumps automatically (and those for
manual usage are quite unstable, to say the least...). But I don't think
it's an excuse to have incomplete paths in there, just to save few
bytes?
The only case where I can see it would make some sense is out of tree
build, where indeed it's about just the hypervisor, not the toolstack
(IMO due to the build system limitation, but well...). But at the same
time, having different path variant depending on it-tree/out-of-tree
build feels weird.

> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -208,7 +208,7 @@ VPATH := $(srctree)
> >  
> >  export srctree objtree VPATH
> >  
> > -export XEN_ROOT := $(abs_srctree)/..
> > +export XEN_ROOT := $(patsubst %/xen,%,$(abs_srctree))
> 
> Unlike for tools/, is this still needed here? You don't use XEN_ROOT below.

Indeed in this revision not anymore.

> > @@ -412,6 +412,10 @@ ifneq ($(CONFIG_CC_IS_CLANG),y)
> >  CFLAGS += -Wa,--strip-local-absolute
> >  endif
> >  
> > +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(abs_objtree)=./xen)
> > +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(abs_srctree)=./xen)
> > +$(call cc-option-add,CFLAGS,CC,-fmacro-prefix-map=$(abs_srctree)=./xen)
> 
> I disagree with leaving any xen/ prefix there. That's not how in-tree builds
> name files; everything there is relative to xen/.
> 
> I also don't really see a point in using . in the substitution (similarly
> for the toolstack, but there I have less to say).
> 
> Finally, why pass two identical, possibly long options for in-tree builds
> (where $(abs_objtree) == $(abs_srctree))?

That can be avoided, yes.

> Below I'll reproduce my own further re-worked patch. It's not quite ready
> for v2 submission yet, I expect though. For example, the actual Kconfig
> portion is still missing. Whether the @SRC@ and @BLD@ parts actually make
> sense (or what to replace them by) I'm also unsure about. If nothing else
> they may need replacing by plain .
> 
> Jan
> 
> build: avoid absolute paths in executables
> 
> For in-tree builds relative paths are used in most cases, whereas for out-
> of-tree builds in various situations absolute ones come into play. The
> extra paths can be long, wasting space and e.g. serial line bandwidth.
> They would also get in the way of location-independent reproducible
> builds. Leverage newer gcc's (and Clang's) ability to "remap" file names.
> For older gcc fall back to using the option affecting debug info only.
> 
> For the few absolute paths appearing in in-tree builds' debug info, use
> the generally available option, conditional upon a new Kconfig control
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Of course we may want to consider putting this in the top-level Config.mk,
> to also affect other sub-trees (presently mainly/only affecting debug
> info, for which even gcc5 already supports -fdebug-prefix-remap=).
> 
> As to a Fixes: tag, I wasn't quite sure whether to "blame" the
> introduction of out-of-tree builds.
> 
> Note that at least in the gcc5 I'm testing with the (limited) effect is
> further undermined by the compiler emitting the specified command line
> options into debug info, thus still leaving references to the absolute
> directories in place.
> 
> For the mentioned gcc15 issue see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121788.
> ---
> v2: Use $(abs_srctree). Introduce DEBUG_INFO_REL_PATHS.
> 
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -461,7 +461,21 @@ CFLAGS += -flto
>  LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
>  endif
>  
> +CFLAGS-$(CONFIG_DEBUG_INFO_REL_PATHS) += -fdebug-prefix-map=$(abs_srctree)=@SRC@
> +
>  ifdef building_out_of_srctree
> +    # Need to add to CFLAGS-y here, as gcc checks later options before earlier
> +    # ones, and we want in particular the latter one(s) here to be checked
> +    # first.
> +    CFLAGS-$(CONFIG_DEBUG_INFO_REL_PATHS) += -fdebug-prefix-map=$(abs_objtree)=@BLD@
> +    CFLAGS-y += $(call cc-option,$(CC),-ffile-prefix-map=$(abs_srctree)/=)
> +    # While -ffile-prefix-map= implies -fdebug-prefix-map=, we need to use the
> +    # latter explicitly: Up to at least gcc15 the compiler specs translate all
> +    # -ffile-prefix-map= ahead of all -fdebug-prefix-map= when invoking the
> +    # the assembler for *.S files, thus breaking our intended ordering.
> +    # (Otherwise the option below could be passed as 3rd [fallback] argument to
> +    # cc-option above.)
> +    CFLAGS-y += -fdebug-prefix-map=$(abs_srctree)/=
>      CFLAGS += -I$(objtree)/include
>      CFLAGS += -I$(objtree)/arch/$(SRCARCH)/include
>  endif
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

On 04.09.2025 16:27, Marek Marczykowski-Górecki wrote:
> On Thu, Sep 04, 2025 at 02:58:20PM +0200, Jan Beulich wrote:
>> On 04.09.2025 13:41, Marek Marczykowski-Górecki wrote:
>>> Use -fdebug-prefix-map in preference to -ffile-prefix-map, as it's
>>> available in earlier toolchain versions. But use it together with
>>> -fmacro-prefix-map (if available) for hypervisor build, otherwise it
>>> still contains some paths in out-of-tree builds.
>>
>> I consider it wrong not to use -ffile-prefix-map when available. That
>> already covers more than "debug" and "macro", and it may gain further
>> functionality.
> 
> I asked about that on v1 and got ambiguous answer suggesting the opposite:
> https://lore.kernel.org/xen-devel/0370c0eb1fd9ac00acab016792132fa0b943d384.1742317309.git-series.marmarek@invisiblethingslab.com/T/#m74a8883835e30fb74a85b07a7b14507ee52e7c65

Ambiguous answer(s)? There's no reply to that mail of yours, and I don't
see how the conclusion drawn fits my earlier comment. That was more
towards what I did in v1 of my patch - fall back to the more widely
supported option when the less widely available one can't be used.

>>> --- a/tools/Makefile
>>> +++ b/tools/Makefile
>>> @@ -1,4 +1,4 @@
>>> -XEN_ROOT = $(CURDIR)/..
>>> +XEN_ROOT = $(realpath $(CURDIR)/..)
>>>  
>>>  export PKG_CONFIG_DIR = $(CURDIR)/pkg-config
>>>  
>>> diff --git a/tools/Rules.mk b/tools/Rules.mk
>>> index 725c3c32e9a2..428fce094819 100644
>>> --- a/tools/Rules.mk
>>> +++ b/tools/Rules.mk
>>> @@ -166,6 +166,8 @@ endif
>>>  CFLAGS-$(CONFIG_X86_32) += $(call cc-option,$(CC),-mno-tls-direct-seg-refs)
>>>  CFLAGS += $(CFLAGS-y)
>>>  
>>> +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(realpath $(XEN_ROOT))=.)
>>
>> Here and below - no need to use cc-option-add for -fdebug-prefix-map,
>> which all permissible compilers support.
> 
> Ok.
> 
>> Further, again as per reply to Andrew on the thread hanging off of my
>> patch - I don't view it as desirable to leave the tools/ prefix in
>> place, or e.g. for libraries, the entire tools/libs/<subdir>/ part.
>> Imo every binary should have only the path (if any) from its own source
>> root left. (And yes, how to deal with e.g. shared include files isn't
>> quite clear to me, yet. Maybe we actually need to pass two options.)
> 
> I don't think it's valid to strip arbitrary prefixes from debug symbols,
> especially in tools. This will break some automated tools that try to match
> coredumps (and similar) to source code and sometimes even debug symbols
> too. But even for manual usage, having to jump between directories (I'm
> not sure if gdb supports multiple source dirs at once?)

Pretty necessarily: When debugging you might easily cross project boundaries.

> just because you
> happen to debug a binary that use more of libraries isn't exactly
> desirable.
> I think the paths in debug symbols and similar should match the layout
> in the source repository, not a subset of it.

Well, okay, we disagree here. To me, xen.git really is an agglomeration of
too many things in a single repo. If things were properly split, you'd end
up with what I'm asking for anyway.

> Theoretically this doesn't apply to the hypervisor yet, as I'm not aware
> of any tool processing xen memory dumps automatically (and those for
> manual usage are quite unstable, to say the least...). But I don't think
> it's an excuse to have incomplete paths in there, just to save few
> bytes?
> The only case where I can see it would make some sense is out of tree
> build, where indeed it's about just the hypervisor, not the toolstack
> (IMO due to the build system limitation, but well...). But at the same
> time, having different path variant depending on it-tree/out-of-tree
> build feels weird.

Which is why I'm arguing for the dropping of the xen/ prefixes, as that's
how things come out in in-tree builds.

Jan

On Fri, Sep 05, 2025 at 10:15:12AM +0200, Jan Beulich wrote:
> On 04.09.2025 16:27, Marek Marczykowski-Górecki wrote:
> > On Thu, Sep 04, 2025 at 02:58:20PM +0200, Jan Beulich wrote:
> >> On 04.09.2025 13:41, Marek Marczykowski-Górecki wrote:
> >>> Use -fdebug-prefix-map in preference to -ffile-prefix-map, as it's
> >>> available in earlier toolchain versions. But use it together with
> >>> -fmacro-prefix-map (if available) for hypervisor build, otherwise it
> >>> still contains some paths in out-of-tree builds.
> >>
> >> I consider it wrong not to use -ffile-prefix-map when available. That
> >> already covers more than "debug" and "macro", and it may gain further
> >> functionality.
> > 
> > I asked about that on v1 and got ambiguous answer suggesting the opposite:
> > https://lore.kernel.org/xen-devel/0370c0eb1fd9ac00acab016792132fa0b943d384.1742317309.git-series.marmarek@invisiblethingslab.com/T/#m74a8883835e30fb74a85b07a7b14507ee52e7c65
> 
> Ambiguous answer(s)? There's no reply to that mail of yours,

I mean your email to which I responded.

> and I don't
> see how the conclusion drawn fits my earlier comment. That was more
> towards what I did in v1 of my patch - fall back to the more widely
> supported option when the less widely available one can't be used.
> 
> >>> --- a/tools/Makefile
> >>> +++ b/tools/Makefile
> >>> @@ -1,4 +1,4 @@
> >>> -XEN_ROOT = $(CURDIR)/..
> >>> +XEN_ROOT = $(realpath $(CURDIR)/..)
> >>>  
> >>>  export PKG_CONFIG_DIR = $(CURDIR)/pkg-config
> >>>  
> >>> diff --git a/tools/Rules.mk b/tools/Rules.mk
> >>> index 725c3c32e9a2..428fce094819 100644
> >>> --- a/tools/Rules.mk
> >>> +++ b/tools/Rules.mk
> >>> @@ -166,6 +166,8 @@ endif
> >>>  CFLAGS-$(CONFIG_X86_32) += $(call cc-option,$(CC),-mno-tls-direct-seg-refs)
> >>>  CFLAGS += $(CFLAGS-y)
> >>>  
> >>> +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(realpath $(XEN_ROOT))=.)
> >>
> >> Here and below - no need to use cc-option-add for -fdebug-prefix-map,
> >> which all permissible compilers support.
> > 
> > Ok.
> > 
> >> Further, again as per reply to Andrew on the thread hanging off of my
> >> patch - I don't view it as desirable to leave the tools/ prefix in
> >> place, or e.g. for libraries, the entire tools/libs/<subdir>/ part.
> >> Imo every binary should have only the path (if any) from its own source
> >> root left. (And yes, how to deal with e.g. shared include files isn't
> >> quite clear to me, yet. Maybe we actually need to pass two options.)
> > 
> > I don't think it's valid to strip arbitrary prefixes from debug symbols,
> > especially in tools. This will break some automated tools that try to match
> > coredumps (and similar) to source code and sometimes even debug symbols
> > too. But even for manual usage, having to jump between directories (I'm
> > not sure if gdb supports multiple source dirs at once?)
> 
> Pretty necessarily: When debugging you might easily cross project boundaries.
> 
> > just because you
> > happen to debug a binary that use more of libraries isn't exactly
> > desirable.
> > I think the paths in debug symbols and similar should match the layout
> > in the source repository, not a subset of it.
> 
> Well, okay, we disagree here. To me, xen.git really is an agglomeration of
> too many things in a single repo. If things were properly split, you'd end
> up with what I'm asking for anyway.

To give specific example: Fedora installs source files in
/usr/src/debug/(package name) and then does debuginfo postprocessing to
point at that path. Debian does pretty much the same, and I'm sure many
other distributions too. Now, if you strip part of the path from debug
symbols, they will not point at the correct source location.
Of course Fedora/Debian/etc package can apply a patch to adjust it (as
it's currently supplying -fdebug-prefix-map via CFLAGS), but IMO forcing
every distribution to basically undo upstream change is a wrong move.

> > Theoretically this doesn't apply to the hypervisor yet, as I'm not aware
> > of any tool processing xen memory dumps automatically (and those for
> > manual usage are quite unstable, to say the least...). But I don't think
> > it's an excuse to have incomplete paths in there, just to save few
> > bytes?
> > The only case where I can see it would make some sense is out of tree
> > build, where indeed it's about just the hypervisor, not the toolstack
> > (IMO due to the build system limitation, but well...). But at the same
> > time, having different path variant depending on it-tree/out-of-tree
> > build feels weird.
> 
> Which is why I'm arguing for the dropping of the xen/ prefixes, as that's
> how things come out in in-tree builds.
> 
> Jan

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab