[U-Boot] [RFC] bug.h: Drop filename from BUG/WARNING logs if building for TPL/SPL

[Tom Rini <trini@konsulko.com>]

On Thu, Jul 11, 2019 at 01:12:16PM -0500, Andreas Dannenberg wrote:
> Yamada-san,
> 
> On Fri, Jul 12, 2019 at 02:29:02AM +0900, Masahiro Yamada wrote:
> > On Fri, Jul 12, 2019 at 12:34 AM Andreas Dannenberg <dannenberg@ti.com> wrote:
> > >
> > > On Wed, Jul 10, 2019 at 04:30:44PM -0500, Andreas Dannenberg wrote:
> > > > On several platforms space is very tight when building for SPL or TPL.
> > > > To claw back a few bytes to be used for code remove the __FILE__ name
> > > > from the BUG() and WARN() type macros. Since those macros still print
> > > > the function name plus a line number this should not really affect
> > > > the ability to backtrace an actual BUG/WARN message to a specific
> > > > piece of code.
> > > >
> > > > Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
> > > > ---
> > > >
> > > > I was looking for a way to shave off a few bytes from the SPL code size
> > > > (TI AM335x) and looking at the hexdump of the SPL I found well why not
> > > > further reduce some strings down in size... I was already aware of the
> > > > recent compiler optimizations to drop some of the irrelevant path from
> > > > the __FILE__ macro but I wanted to go one step beyond this. Dropping
> > > > all the path from __FILE__ via preprocessor macro can't be easily done
> > > > as others have already found so I decided to drop __FILE__ altogether
> > > > (code below) and was excited about the improvements I got...
> > >
> > > Just some quick examples about the savings...
> > >
> > > Using buildman "bloat" reporting (-B) I see the SPL .text size for AM335x
> > > to be reduced by 12 bytes. And for AM43xx the size goes down by 52
> > > bytes. The benefit of the proposed change really depends on a) whether a
> > > given platform uses SPL, and b) how many calls to BUG/WARN it has. The
> > > USB drivers in AM335x/AM43xx are really the "heavy hitters" here. I'm
> > > sure I could find additional examples/platforms to highlight savings if
> > > needed.
> > >
> > > Anyways I'm not proud of the proposed change but merely wanted to see
> > > with this RFC if there isn't any way to do further optimizations on the
> > > __FILE__ topic that are not overly intrusive specifically as it comes to
> > > SPL.
> > 
> > 
> > Commit 1eb2e71edd55e16562e3912881c449db69623352
> > was not enough to solve your problem.
> > 
> > Correct?
> 
> Correct. This is a great commit and I saw what all went into it and it
> goes a long way in addressing the general concern and doing much needed
> cleanup but I wanted to go beyond this.
> 
> Consider this example, if I use a WARN_ON() deep in the arch folder of
> one of the SoCs, I would get this on the console...
> 
> 	WARNING at arch/arm/mach-k3/am6_init.c:192/board_init_f()!
> 
> ...and now, with the proposed change, it would boil down to this...
> 
> 	WARNING at 192 at board_init_f()!
> 
> 
> If we could just keep the base filename itself that would still be a
> good size reduction, and keep the output somewhat consistent with the
> original behavior, but I spent quite some time researching but without
> some extreme "magic" there didn't seem to be an universal solution...
> 
> 
> Also some additional background why I am even looking into this. One of
> our platforms (AM335x) has a regression building on Travis CI with some
> of our pending patches applied. Interestingly, this only happens on
> Travis, which still uses GCC 7.3.0 for arm (why?). With newer, more
> efficient compilers there is no such issue.

On this last point, gcc 7.3 is the current GCC release that doesn't have
regressions elsewhere until we reach gcc-9, for which I cannot find good
pre-built toolchains.  We can get gcc-8.3 (or 8.2?  I forget) from Arm
Ltd now, but that has problems on x86.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190711/6098aba2/attachment.sig>