Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Leonard Crestez <leonard.crestez@nxp.com>
To:     Jan Kiszka <jan.kiszka@siemens.com>,
        Joel Colledge <joel.colledge@linbit.com>
CC:     Kieran Bingham <kbingham@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] scripts/gdb: fix lx-dmesg when CONFIG_PRINTK_CALLER is
 set
Thread-Topic: [PATCH] scripts/gdb: fix lx-dmesg when CONFIG_PRINTK_CALLER is
 set
Thread-Index: AQHVc7J2WTi3Jq2z7EqErfeE4WWeNw==
Date:   Thu, 10 Oct 2019 19:36:55 +0000
Message-ID: <VI1PR04MB70236211F170522DD456553AEE940@VI1PR04MB7023.eurprd04.prod.outlook.com>
References: <20190925150308.6609-1-joel.colledge@linbit.com>
 <a87e01b0-73f1-8a86-d7c0-2700e1032b92@siemens.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7ac3a1b9-5e7c-4a83-205f-08d74db93582
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2019 19:36:55.7412
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5rdjWkGttmYwf5JS+XYLinFJtpegisN0dPNv0VmhHdfe8Uwq8LiR4d7qdex4CyIDAV2TGQhkLDH6BKW4zwWp9A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5309
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10.10.2019 18:14, Jan Kiszka wrote:=0A=
> On 25.09.19 17:03, Joel Colledge wrote:=0A=
>> When CONFIG_PRINTK_CALLER is set, struct printk_log contains an=0A=
>> additional member caller_id. As a result, the offset of the log text is=
=0A=
>> different.=0A=
>>=0A=
>> This fixes the following error:=0A=
>>=0A=
>>    (gdb) lx-dmesg=0A=
>>    Python Exception <class 'ValueError'> embedded null character:=0A=
>>    Error occurred in Python command: embedded null character=0A=
>>=0A=
>> Signed-off-by: Joel Colledge <joel.colledge@linbit.com>=0A=
>> ---=0A=
>>   scripts/gdb/linux/constants.py.in | 1 +=0A=
>>   scripts/gdb/linux/dmesg.py        | 4 +++-=0A=
>>   2 files changed, 4 insertions(+), 1 deletion(-)=0A=
>>=0A=
>> diff --git a/scripts/gdb/linux/constants.py.in b/scripts/gdb/linux/const=
ants.py.in=0A=
>> index 2efbec6b6b8d..3c9794a0bf55 100644=0A=
>> --- a/scripts/gdb/linux/constants.py.in=0A=
>> +++ b/scripts/gdb/linux/constants.py.in=0A=
>> @@ -74,4 +74,5 @@ LX_CONFIG(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST)=0A=
>>   LX_CONFIG(CONFIG_HIGH_RES_TIMERS)=0A=
>>   LX_CONFIG(CONFIG_NR_CPUS)=0A=
>>   LX_CONFIG(CONFIG_OF)=0A=
>> +LX_CONFIG(CONFIG_PRINTK_CALLER)=0A=
>>   LX_CONFIG(CONFIG_TICK_ONESHOT)=0A=
>> diff --git a/scripts/gdb/linux/dmesg.py b/scripts/gdb/linux/dmesg.py=0A=
>> index 6d2e09a2ad2f..1352680ef731 100644=0A=
>> --- a/scripts/gdb/linux/dmesg.py=0A=
>> +++ b/scripts/gdb/linux/dmesg.py=0A=
>> @@ -14,6 +14,7 @@=0A=
>>   import gdb=0A=
>>   import sys=0A=
>>   =0A=
>> +from linux import constants=0A=
>>   from linux import utils=0A=
>>   =0A=
>>   =0A=
>> @@ -53,7 +54,8 @@ class LxDmesg(gdb.Command):=0A=
>>                   continue=0A=
>>   =0A=
>>               text_len =3D utils.read_u16(log_buf[pos + 10:pos + 12])=0A=
>> -            text =3D log_buf[pos + 16:pos + 16 + text_len].decode(=0A=
>> +            text_start =3D pos + (20 if constants.LX_CONFIG_PRINTK_CALL=
ER else 16)=0A=
>> +            text =3D log_buf[text_start:text_start + text_len].decode(=
=0A=
>>                   encoding=3D'utf8', errors=3D'replace')=0A=
>>               time_stamp =3D utils.read_u64(log_buf[pos:pos + 8])=0A=
> =0A=
> Sorry for the delay:=0A=
> =0A=
> Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>=0A=
> =0A=
> I suspect we will see more in nearer future with upcoming printk rework..=
.=0A=
=0A=
The patch looks correct but I'm curious: is there a reason this code =0A=
doesn't use struct printk_log?=0A=
=0A=
GDB already knows about struct offsets so there should be no need to =0A=
handle ifdefs with arithmetic.=0A=
=0A=
Is it realistic to use gdb without struct layout info?=0A=
=0A=
--=0A=
Regards,=0A=
Leonard=0A=