lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ