From: Kieran Bingham <kieran.bingham@linaro.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: linux-kernel@vger.kernel.org, maxime.coquelin@st.com,
peter.griffin@linaro.org, lee.jones@linaro.org
Subject: Re: [PATCH 1/5] scripts/gdb: Provide linux constants
Date: Sun, 24 Jan 2016 00:11:46 +0000 [thread overview]
Message-ID: <56A416C2.2070100@linaro.org> (raw)
In-Reply-To: <56A396C8.3040202@siemens.com>
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@linaro.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
next prev parent reply other threads:[~2016-01-24 0:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-20 11:15 [RFC PATCH 0/5] scripts/gdb: Linux awareness debug commands Kieran Bingham
2016-01-20 11:15 ` [PATCH 1/5] scripts/gdb: Provide linux constants Kieran Bingham
2016-01-23 15:05 ` Jan Kiszka
2016-01-24 0:11 ` Kieran Bingham [this message]
2016-01-20 11:15 ` [PATCH 2/5] scripts/gdb: Provide a kernel list item generator Kieran Bingham
2016-01-23 15:08 ` Jan Kiszka
2016-01-24 0:15 ` Kieran Bingham
2016-01-20 11:15 ` [PATCH 3/5] scripts/gdb: Add io resource readers Kieran Bingham
2016-01-23 15:12 ` Jan Kiszka
2016-01-24 0:17 ` Kieran Bingham
2016-01-20 11:15 ` [PATCH 4/5] scripts/gdb: Add mount point list command Kieran Bingham
2016-01-20 11:42 ` Jan Kiszka
2016-01-20 11:51 ` Kieran Bingham
2016-01-20 12:08 ` Jan Kiszka
2016-01-23 12:34 ` Jan Kiszka
2016-01-23 15:27 ` Jan Kiszka
2016-01-24 0:24 ` Kieran Bingham
2016-01-20 11:15 ` [PATCH 5/5] scripts/gdb: Add meminfo command Kieran Bingham
2016-01-23 15:21 ` Jan Kiszka
2016-01-24 0:30 ` Kieran Bingham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56A416C2.2070100@linaro.org \
--to=kieran.bingham@linaro.org \
--cc=jan.kiszka@siemens.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.coquelin@st.com \
--cc=peter.griffin@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.