From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Anthony PERARD" <anthony.perard@vates.tech>,
"Frédéric Pierret (fepitre)" <frederic.pierret@qubes-os.org>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Michal Orzel" <michal.orzel@amd.com>,
"Julien Grall" <julien@xen.org>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 2/2] Strip build path directories in tools, xen and xen/arch/x86
Date: Thu, 20 Mar 2025 16:58:51 +0100 [thread overview]
Message-ID: <Z9w7PPEbF1STQNBt@mail-itl> (raw)
In-Reply-To: <fb116d7e-e678-4ac9-920a-de7e5b227417@suse.com>
[-- Attachment #1: Type: text/plain, Size: 5100 bytes --]
On Thu, Mar 20, 2025 at 04:48:02PM +0100, Jan Beulich wrote:
> On 20.03.2025 16:32, Marek Marczykowski-Górecki wrote:
> > On Thu, Mar 20, 2025 at 04:21:18PM +0100, Jan Beulich wrote:
> >> On 20.03.2025 16:17, Marek Marczykowski-Górecki wrote:
> >>> On Thu, Mar 20, 2025 at 02:35:59PM +0000, Anthony PERARD wrote:
> >>>> On Thu, Mar 20, 2025 at 02:59:04PM +0100, Marek Marczykowski-Górecki wrote:
> >>>>> On Thu, Mar 20, 2025 at 02:49:27PM +0100, Jan Beulich wrote:
> >>>>>> On 20.03.2025 13:51, Marek Marczykowski-Górecki wrote:
> >>>>>>> On Thu, Mar 20, 2025 at 10:18:28AM +0000, Anthony PERARD wrote:
> >>>>>>>> On Wed, Mar 19, 2025 at 02:40:33PM +0100, Marek Marczykowski-Górecki wrote:
> >>>>>>>>> There are clearly some build path embedding left. And
> >>>>>>>>> -ffile-prefix-map=/-fdebug-prefix-map= doesn't work correctly with
> >>>>>>>>> XEN_ROOT having xen/.. at the end.
> >>>>>>>>> BTW, would it be acceptable to have this?
> >>>>>>>>>
> >>>>>>>>> $(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(realpath $(XEN_ROOT))=.)
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Could you avoid using $(XEN_ROOT) in hypervisor build system? (It's fine
> >>>>>>>> in "tools/"). In "xen/", there's a few variables you can use if they are
> >>>>>>>> needed: $(abs_objtree) $(abs_srctree) for absolutes path, and $(srctree)
> >>>>>>>> $(objtree) for relative path. That also should avoid the need to use
> >>>>>>>> $(realpath ).
> >>>>>>>
> >>>>>>> XEN_ROOT is literally "$(abs_srctree)/..". And I need to resolve it to
> >>>>>>> not have /.. for prefix-map to work correctly. Would it be better to use
> >>>>>>> literal $(realpath $(abs_srctree)/..)? Or use just $(abs_srctree) and
> >>>>>>> have paths in debug symbols relative to hypervisor source dir, instead
> >>>>>>> of xen repo root? I'm not sure if that wouldn't confuse some tools...
> >>>>>>
> >>>>>> abs_srctree being computed using realpath, can't we replace
> >>>>>>
> >>>>>> export XEN_ROOT := $(abs_srctree)/..
> >>>>>>
> >>>>>> by something as simpl{e,istic} as
> >>>>>>
> >>>>>> export XEN_ROOT := $(patsubst %/xen,%,$(abs_srctree))
> >>>>>>
> >>>>>> ?
> >>>>>
> >>>>> That works too. It's slightly less robust, but I don't expect "xen"
> >>>>> directory to be renamed, so shouldn't be an issue. I'll leave also a
> >>>>> comment there why not /.. .
> >>>>
> >>>> I don't think $(XEN_ROOT) is present in the binaries produce by the
> >>>> hypervisor's build system. There's only a few use if that variable: to
> >>>> load some makefile, to execute makefile that build xsm policy and to
> >>>> generate cpuid-autogen.h. Otherwise I don't think the compile have this
> >>>> path in the command line. What is going to be in the binary is
> >>>> $(abs_srctree), which you can replace by "./xen" if you want; which mean
> >>>> it doesn't matter if the directory is renamed or not. You might want to
> >>>> also take care of $(abs_objtree) which seems to also be in `xen-syms`
> >>>> when doing out-of-tree build.
> >>>
> >>> So, you suggest to do -fdebug-prefix-map=$(abs_srctree)=./xen ? That
> >>> appears to work for in-tree builds too.
> >>
> >> And why ./xen (question to Anthony)? Just . is quite fine, isn't it?
> >
> > It makes paths in debug symbols relative to xen/ subdir, not the
> > repository root. I'm not sure if that is a problem, but it may be for
> > some tools.
>
> Yet especially in the symbol table (and hence in strack traces) that's
> unnecessary extra space it takes up.
>
> >>> But now I actually tested how it looks with out-of-tree builds, and
> >>> indeed $(abs_objtree) is embedded there too. Adding
> >>> -fdebug-prefix-map=$(abs_objtree)=./xen appears to help for this. But,
> >>> -fdebug-prefix-map doesn't help with abs_srctree in out-of-tree builds
> >>> for some reason. -ffile-prefix-map does. And so does -fdebug-prefix-map
> >>> + -fmacro-prefix-map. Is there any preference which one to use? It
> >>> appears as -fmacro-prefix-map and -ffile-prefix-map have the same
> >>> availability in both GCC (8) and Clang (10).
> >>
> >> Then the simpler -ffile-prefix-map is better, imo. Question then is
> >> whether any of the options is actually needed at all for in-tree builds.
> >
> > Yes, without any of those options, both xen-syms and xen.efi contain
> > full source path.
>
> Even in builds without debug info?
For in-tree build without debug info, it appears no. But with debug
info, something is needed even for in-tree build.
And BTW, IIUC out-of-tree builds will become relevant even for in-tree
build at some point, due to pvshim.
> Imo a goal ought to be to specify the
> weakest possible of these options for any particular build mode. I.e.
> possibly -ffile-prefix-map= for out of tree builds, else
> -fdebug-prefix-map= when DEBUG_INFO=y, else nothing (if possible).
Is it? I don't really see why making the selection overly complex if the
option is supported (and cc-option-add covers that case).
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2025-03-20 15:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 17:01 [PATCH v1 0/2] Improve reproducibility of build artifacts Marek Marczykowski-Górecki
2025-03-18 17:01 ` [PATCH v1 1/2] docs/xen-headers: use alphabetical sorting for @incontents Marek Marczykowski-Górecki
2025-03-19 11:19 ` Anthony PERARD
2025-03-19 11:36 ` Marek Marczykowski-Górecki
2025-03-18 17:01 ` [PATCH v1 2/2] Strip build path directories in tools, xen and xen/arch/x86 Marek Marczykowski-Górecki
2025-03-19 8:45 ` Jan Beulich
2025-03-19 9:15 ` Jan Beulich
2025-03-19 9:43 ` Jan Beulich
2025-03-19 11:58 ` Marek Marczykowski-Górecki
2025-03-19 12:43 ` Jan Beulich
2025-03-19 13:40 ` Marek Marczykowski-Górecki
2025-03-19 14:26 ` Jan Beulich
2025-03-20 10:18 ` Anthony PERARD
2025-03-20 12:51 ` Marek Marczykowski-Górecki
2025-03-20 13:49 ` Jan Beulich
2025-03-20 13:59 ` Marek Marczykowski-Górecki
2025-03-20 14:36 ` Anthony PERARD
2025-03-20 15:11 ` Jan Beulich
2025-03-20 15:17 ` Marek Marczykowski-Górecki
2025-03-20 15:21 ` Jan Beulich
2025-03-20 15:32 ` Marek Marczykowski-Górecki
2025-03-20 15:48 ` Jan Beulich
2025-03-20 15:58 ` Marek Marczykowski-Górecki [this message]
2025-03-20 16:09 ` Jan Beulich
2025-03-20 17:29 ` Marek Marczykowski-Górecki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z9w7PPEbF1STQNBt@mail-itl \
--to=marmarek@invisiblethingslab.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=frederic.pierret@qubes-os.org \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.