Jeremy Fitzhardinge wrote:
quoted text
> 
> Yeah, that seems reasonable if you're optimising for overall size.  Did
> you count the difference of including the function name?  We decided not
> to include it for BUG because its usefulness/size tradeoff didn't seem
> terribly important.

in the WARN_ON case it's not there either, based on Ingo's idea we do a kallsyms lookup
of __builtin_return_address(0) .. same data, less memory.


quoted text
> But my goal was actually to reduce icache pollution, so by my reckoning
> code bytes were much more expensive than data ones, so putting all BUG
> information in a separate section makes those bytes much less
> significant than putting anything inline in code.  Also, the trap for
> WARN_ON would be smaller than BUG, because it wouldn't need the spurious
> infinite loop needed to make gcc understand the control flow of a BUG.
> 
> On the other hand, you could put the call to out of line warning
> function in a separate section to achieve the same effect.

yeah and gcc even has a compiler option for that. Doubt it's really worth it,
we're still talking a few bytes here ;)

quoted text
> 
>     J

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/