From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753145AbcAXALu (ORCPT ); Sat, 23 Jan 2016 19:11:50 -0500 Received: from mail-wm0-f48.google.com ([74.125.82.48]:33593 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751456AbcAXALs (ORCPT ); Sat, 23 Jan 2016 19:11:48 -0500 Subject: Re: [PATCH 1/5] scripts/gdb: Provide linux constants To: Jan Kiszka References: <1453288550-4706-1-git-send-email-kieran.bingham@linaro.org> <1453288550-4706-2-git-send-email-kieran.bingham@linaro.org> <56A396C8.3040202@siemens.com> Cc: linux-kernel@vger.kernel.org, maxime.coquelin@st.com, peter.griffin@linaro.org, lee.jones@linaro.org From: Kieran Bingham Message-ID: <56A416C2.2070100@linaro.org> Date: Sun, 24 Jan 2016 00:11:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A396C8.3040202@siemens.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> --- >> >> 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