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

[Masahiro Yamada]

On Fri, Jul 12, 2019 at 12:34 AM Andreas Dannenberg <dannenberg at 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 at 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?



-- 
Best Regards
Masahiro Yamada