Re: [PATCH 0/2] Fix objtool error reporting and handling of very long symbol names

[Josh Poimboeuf]

On Wed, Oct 04, 2023 at 05:08:17PM -0700, Aaron Plattner wrote:
> Two patches in this series:
> 
> First, when objtool encounters an error, it carefully propagates the return
> code all the way up to main(), which proceeds to ignore it and return 0 no
> matter what. This can cause problems with objtool to be missed because the
> overall build succeeds. This appears to be a regression in commit
> b51277eb9775c, which dropped a call to exit(ret) when a subcommand fails.
> 
> Fix that by returning the status code from main().

Note most objtool errors are currently ignored anyway, due to check()
unconditionally returning 0.  But as the patch mentions, it will indeed
fix early errors.

> Second, very long symbol names with .cold variants cause objtool to fail.
> This is due to using a small max length, which in turn is due to allocating
> on the stack. However, there is not actually a requirement to allocate on
> the stack in this (user space) code path, and in fact, the code is cleaner
> with this fix: MAX_NAME_LEN is gone and the ugly manual NULL termination
> is also removed.

One benefit of the stack array is that reusing it is more performant
than doing a bunch of allocations.  But this is only for cold symbols,
so the slowdown should (hopefully) be negligible.

I'll run it through some testing.  Thanks!

-- 
Josh