[PATCH] arm64: defconfig: Disable DEBUG_INFO
Mark Brown
broonie at kernel.org
Thu Mar 4 14:36:47 GMT 2021
On Thu, Mar 04, 2021 at 12:56:24PM +0000, Will Deacon wrote:
> Hmm. Doing this means ./scripts/faddr2line no longer works with the vmlinux,
> which means if somebody forgets to enable DEBUG_INFO they're in for a
> really hard time debugging when something goes wrong.
Assuming they're aware of that script in the first place and try to
translate addreses with it rather just using the function name in the
stack trace, and aren't able to easily rebuild if they decide that it's
something that's useful. What people do is going to depend a lot on
their use cases.
> Why can't the CI systems just disable DEBUG_INFO themselves instead of
> changing defconfig for everybody?
What's more likely is that they can just increase the amount of space
they allocate to jobs (that's certainly what KernelCI does). Testing
modified versions of configurations isn't great as half the point of
using the standard configurations is that everyone's working to the same
thing and should in theory be seeing the same stuff, it's easier to name
a standard config than name a standard config and a list of tweaks
applied to it.
This is about picking a sensible default, there's always going to be
cases where someone wants the other value (otherwise it wouldn't be a
config option). The contention is that there's a lot more builds being
slowed down by the extra I/O and disk space being burned than benefit to
people who end up with the debug info turned on and actively use it but
these aren't direct tradeoffs so you can't categorically say something
one way or the other. At the minute defconfig actually results in a
bigger build tree than an allmodconfig for me (6.8G vs 5.2G) which
doesn't seem like what I'd expect.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210304/b1886160/attachment.sig>
More information about the linux-arm-kernel
mailing list