[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56A416C2.2070100@linaro.org>
Date: Sun, 24 Jan 2016 00:11:46 +0000
From: Kieran Bingham <kieran.bingham@...aro.org>
To: Jan Kiszka <jan.kiszka@...mens.com>
Cc: linux-kernel@...r.kernel.org, maxime.coquelin@...com,
peter.griffin@...aro.org, lee.jones@...aro.org
Subject: Re: [PATCH 1/5] scripts/gdb: Provide linux constants
On 23/01/16 15:05, Jan Kiszka wrote:
> On 2016-01-20 12:15, Kieran Bingham wrote:
>> Some macro's and defines are needed when parsing memory, and without
>> compiling the kernel as -g3 they are not available in the debug-symbols.
>>
>> We use the pre-processor here to extract constants to a dedicated module
>> for the linux debugger extensions
>>
>> Signed-off-by: Kieran Bingham <kieran.bingham@...aro.org>
>> ---
>>
>> I've added a 'constants.py' which is automatically generated. This allows
>> values not available to the debugger, through #defines to be provided to
>> our scripts.
>>
>> The alternative method for this is to create a c-object file to obtain values
>> through symbols instead, and compile segments with -g3 to include macro
>> definitions in the debug-info.
>>
>> I'd appreciate your thoughts on these options.
>
> I cannot assess your second proposal. How invasive will it be? Is it
> promising to reduce the maintenance? What will be the impact of -g3?
>
> This approach seems pragmatic and sufficient. Would be fine with me
> unless the other has significant advantages.
At the moment, I believe the current method (generating a constants.py)
is my preferred method. It's less intrusive, and can be generated for a
kernel which is to be debugged, which perhaps didn't have GDB_SCRIPTS
enabled at the time.
A c-object file would be more limiting I believe.
Kieran
Powered by blists - more mailing lists