From mboxrd@z Thu Jan 1 00:00:00 1970 From: Masahiro Yamada Date: Fri, 12 Jul 2019 02:29:02 +0900 Subject: [U-Boot] [RFC] bug.h: Drop filename from BUG/WARNING logs if building for TPL/SPL In-Reply-To: <20190711153326.wkz3atrfqxlnhbr2@jiji> References: <20190710213044.19985-1-dannenberg@ti.com> <20190711153326.wkz3atrfqxlnhbr2@jiji> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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? -- Best Regards Masahiro Yamada