[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f643cc54-e7c6-bff5-1a54-b84024235f84@csgroup.eu>
Date: Sat, 24 Jun 2023 08:32:50 +0000
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Josh Poimboeuf <jpoimboe@...nel.org>
CC: Peter Zijlstra <peterz@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH] objtool: Make 'sec-address' always on
Le 22/06/2023 à 08:31, Josh Poimboeuf a écrit :
> On Wed, Jun 21, 2023 at 05:20:31PM +0200, Christophe Leroy wrote:
>> Most of the time objtool warnings are useless without the
>> absolute address within the section.
>>
>> Today there is --sec-address option to get it printed, but
>> that option is nowhere used and requires a change in Makefile
>> to use it.
>>
>> Having the address inside the section at all time in addition
>> to the address within the object doesn't hurt and will help.
>>
>> Remove the --sec-address option and print it at all time.
>
> This option actually feels like clutter to me. The func+offset format
> works fine, combined with scripts like objdump-func and faddr2line. And
> we also have a new OBJTOOL_VERBOSE=1 option which auto-disassembles the
> affected function.
>
> On x86 we've been using func+offset for console stack traces for many
> years, due to KASLR. So maybe we're just more used to it. But the
> scripts make it fine.
Ah right, I didn't know that script, I was struggling with objtool -dr
Therefore the patch is not needed, and neither is the --sec-address
option, maybe we can remove it completely.
>
> Also it helps with identifying the same warning across different
> configs/compilers.
>
Good point.
Christophe
Powered by blists - more mailing lists