mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Florian Fainelli" <florian.fainelli@broadcom.com>,
	linux-arm-kernel@lists.infradead.org
Cc: "Russell King" <linux@armlinux.org.uk>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Andrew Davis" <afd@ti.com>, "Jason Gunthorpe" <jgg@ziepe.ca>,
	"Mark Brown" <broonie@kernel.org>,
	"Etienne Carriere" <etienne.carriere@foss.st.com>,
	"Trevor Woerner" <twoerner@gmail.com>,
	"Javier Carrasco" <javier.carrasco@wolfvision.net>,
	"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ARM: multi_v7_defconfig: Enable debugging symbols by default
Date: Sat, 07 Sep 2024 12:03:48 +0000	[thread overview]
Message-ID: <40412179-9bc2-409b-ab12-11149a3e4f5f@app.fastmail.com> (raw)
In-Reply-To: <20240906213907.611684-1-florian.fainelli@broadcom.com>

On Fri, Sep 6, 2024, at 21:39, Florian Fainelli wrote:
> Similarly to the ARM64 defconfig, enable debugging symbols and rely upon
> the toolchain's default DWARF implementation.
>
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>

I usually build with debug info disabled when I'm build testing,
but turn it on explicitly when I try to actually debug a problem.

Depending on the configuration, adding debug info can significantly
increase the build time and file size. I've tried to record exact
data here, building the arm defconfig on gcc-14 with and without
debug info, which doesn't seem too bad, especially with the
reduced debug info:

config         vmlinux time    total time   vmlinux size
disabled-gcc9  49s             81s          35MB
reduced-gcc9   55s             98s          148MB
full-gcc9      66s             105s         443MB
disabled-gcc14 55s             90s          34MB
reduced-gcc14  60s             99s          124MB
full-gcc14     68s             115s         349MB

There is still added disk usage for build testing, but
the time overhead seems fine. I'd like to hear what others
think about the tradeoff.

      Arnd

      reply	other threads:[~2024-09-07 10:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-06 21:39 Florian Fainelli
2024-09-07 12:03 ` Arnd Bergmann [this message]

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=40412179-9bc2-409b-ab12-11149a3e4f5f@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=afd@ti.com \
    --cc=broonie@kernel.org \
    --cc=etienne.carriere@foss.st.com \
    --cc=florian.fainelli@broadcom.com \
    --cc=geert+renesas@glider.be \
    --cc=javier.carrasco@wolfvision.net \
    --cc=jgg@ziepe.ca \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=twoerner@gmail.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

all inboxes | Powered by JetHome®