From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: ross.burton@arm.com
Cc: ",openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH] distro/include: Add yocto-space-optimize, disabling debugging for large components
Date: Thu, 11 Jul 2024 14:35:39 +0100 [thread overview]
Message-ID: <f10ae72f4cd1e0f1b69e362773ec6c92fa4ffa27.camel@linuxfoundation.org> (raw)
In-Reply-To: <60E368D9-15B3-430C-800B-14BEF1E4614B@arm.com>
On Thu, 2024-07-11 at 12:10 +0000, Ross Burton via lists.openembedded.org wrote:
> On 11 Jul 2024, at 10:30, Richard Purdie via lists.openembedded.org <richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:
> >
> > +DEBUG_FLAGS:remove:pn-llvm = "-g"
> > +DEBUG_FLAGS:remove:pn-qemu = "-g"
> > +DEBUG_FLAGS:remove:pn-openssl = "-g”
>
> This would be difficult to undo if the user did actually want debug symbols, right?
>
> This :removes -g (so you can’t :append it back) from the target flags:
>
> DEBUG_FLAGS ?= "-g -feliminate-unused-debug-types ${DEBUG_PREFIX_MAP}"
> FULL_OPTIMIZATION = "-O2 -pipe ${DEBUG_FLAGS}"
> DEBUG_OPTIMIZATION = "-Og ${DEBUG_FLAGS} -pipe"
> SELECTED_OPTIMIZATION = "${@d.getVar(oe.utils.vartrue('DEBUG_BUILD', 'DEBUG_OPTIMIZATION', 'FULL_OPTIMIZATION', d))}”
> TARGET_CFLAGS = "${TARGET_CPPFLAGS} ${SELECTED_OPTIMIZATION}”
>
> So with this there’s no obvious way to get symbols for target llvm/qemu/openssl, setting DEBUG_BUILD=1 still won’t actually pass -g. The user would have to know to do eg CFLAGS += “-g”.
>
> I’ll note that webkitgtk3 has approached this problem already and settled on this:
>
> DEBUG_FLAGS:append = "${@oe.utils.vartrue('DEBUG_BUILD', '', ' -g1', d)}"
>
> So -g1 (minimal but functional debugging info) unless DEBUG_BUILD enabled.
>
> I’m fairly against removing _all_ debug symbols for these recipes in default builds, although I’d certainly be happy with -g1 as a compromise between space saving and utility.
I agree that the remove is too hard to undo so we can't use this
approach. We probably need to parameterise it in DEBUG_FLAGS since
we're likely to need to do this more frequently.
I do still think we should drop -g entirely for llvm though as the
debug info is just too large even at -g1. I'm particularly keen to keep
the package sizes down which keeps the sstate object size down too,
making builds from sstate better over the network.
Cheers,
Richard
next prev parent reply other threads:[~2024-07-11 13:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-11 9:30 [PATCH] distro/include: Add yocto-space-optimize, disabling debugging for large components Richard Purdie
2024-07-11 12:10 ` [OE-core] " Ross Burton
2024-07-11 13:35 ` Richard Purdie [this message]
2024-07-11 21:40 ` Khem Raj
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=f10ae72f4cd1e0f1b69e362773ec6c92fa4ffa27.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=ross.burton@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox