This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix printf of a convenience variable holding an inferior address
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Andrew Burgess <andrew dot burgess at embecosm dot com>
- Cc: GDB Patches <gdb-patches at sourceware dot org>, Philippe Waroquiers <philippe dot waroquiers at skynet dot be>, Pedro Alves <palves at redhat dot com>, Joel Brobecker <brobecker at adacore dot com>
- Date: Tue, 03 Mar 2020 11:49:41 -0500
- Subject: Re: [PATCH] Fix printf of a convenience variable holding an inferior address
- References: <20190610211622.15237-1-philippe.waroquiers@skynet.be> <20200302024616.1049417-1-sergiodj@redhat.com> <20200303133918.GV3317@embecosm.com> <877e01h06g.fsf@redhat.com>
On Tuesday, March 03 2020, I wrote:
> On Tuesday, March 03 2020, Andrew Burgess wrote:
>
>> * Sergio Durigan Junior <sergiodj@redhat.com> [2020-03-01 21:46:16 -0500]:
>>
>>> Back at:
>>>
>>> commit 1f6f6e21fa86dc3411a6498608f32e9eb24b7851
>>> Author: Philippe Waroquiers <philippe.waroquiers@skynet.be>
>>> Date: Mon Jun 10 21:41:51 2019 +0200
>>>
>>> Ensure GDB printf command can print convenience var strings without a target.
>>>
>>> GDB was extended in order to allow the printing of convenience
>>> variables that are strings without a target. However, this introduced
>>> a regression that hasn't been caught by our testsuite (because there
>>> were no tests for it).
>>>
>>> The problem happens when we try to print a convenience variable that
>>> holds the address of a string in the inferior. The following
>>> two-liners can reproduce the issue:
>>>
>>> $ echo -e 'int main(){const char a[]="test";return 0;}' | gcc -x c - -O0-g3
>>> $ ./gdb/gdb --data-directory ./gdb/data-directory -q ./a.out -ex 'start' -ex 'set $x = (const char *) (&a[0] + 2)' -ex 'printf "%s\n", $x'
>>>
>>> After some investigation, I found that the problem happens on
>>> printcmd.c:printf_c_string. In the case above, we're taking the first
>>> branch of the 'if' condition, which assumes that there will be a value
>>> to be printed at "value_contents (value)". There isn't. We actually
>>> need to obtain the address that the variable points to, and read the
>>> contents from memory.
>>>
>>> It seems to me that we should avoid this branch if the TYPE_CODE of
>>> "value_type (value)" is TYPE_CODE_PTR (i.e., a pointer to the
>>> inferior's memory). This is what this patch does.
>>>
>>> I took the liberty to extend the current testcase under
>>> gdb.base/printcmds.exp and create a test that exercises this scenario.
>>>
>>> No regressions have been found on Buildbot.
>>>
>>> gdb/ChangeLog:
>>> 2020-03-02 Sergio Durigan Junior <sergiodj@redhat.com>
>>>
>>> * printcmd.c (print_c_string): Check also for TYPE_CODE_PTR
>>> when verifying if dealing with a convenience variable.
>>>
>>> gdb/testsuite/ChangeLog:
>>> 2020-03-02 Sergio Durigan Junior <sergiodj@redhat.com>
>>>
>>> * gdb.base/printcmds.exp: Add test to verify printf of a
>>> variable holding an address.
>>
>> LGTM.
>
> Thanks, pushed:
>
> 7b973adce2b486518d3150db257b179e1b9a5d33
BTW, this also affects 9.1 (in fact, that's where I found the bug). I
can create a tracking bug and backport it to the branch if the issue and
fix are deemed important enough.
Thanks,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/