From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 11 Jul 2019 14:43:17 -0400 Subject: [U-Boot] [RFC] bug.h: Drop filename from BUG/WARNING logs if building for TPL/SPL In-Reply-To: <20190711181216.vznixfd5xzk2ihfe@jiji> References: <20190710213044.19985-1-dannenberg@ti.com> <20190711153326.wkz3atrfqxlnhbr2@jiji> <20190711181216.vznixfd5xzk2ihfe@jiji> Message-ID: <20190711184317.GG6891@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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 > > > > --- > > > > > > > > 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: