From: Sergio Durigan Junior <sergiodj@redhat.com>
To: Andrew Burgess <andrew.burgess@embecosm.com>
Cc: GDB Patches <gdb-patches@sourceware.org>,
Philippe Waroquiers <philippe.waroquiers@skynet.be>,
Pedro Alves <palves@redhat.com>,
Joel Brobecker <brobecker@adacore.com>
Subject: Re: [PATCH] Fix printf of a convenience variable holding an inferior address
Date: Tue, 03 Mar 2020 16:49:00 -0000 [thread overview]
Message-ID: <87wo81criy.fsf@redhat.com> (raw)
In-Reply-To: <877e01h06g.fsf@redhat.com> (Sergio Durigan Junior's message of "Tue, 03 Mar 2020 11:29:11 -0500")
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/
next prev parent reply other threads:[~2020-03-03 16:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-10 21:16 [RFA] Ensure GDB printf command can print convenience var strings without a target Philippe Waroquiers
2019-06-11 2:29 ` Eli Zaretskii
2019-07-05 20:01 ` PING " Philippe Waroquiers
2019-07-08 18:13 ` Pedro Alves
2019-07-08 22:41 ` Philippe Waroquiers
2019-07-09 4:36 ` New FAIL on gdb.base/printcmds.exp (was: Re: [RFA] Ensure GDB printf command can print convenience var strings without a target.) Sergio Durigan Junior
2020-03-02 2:46 ` [PATCH] Fix printf of a convenience variable holding an inferior address Sergio Durigan Junior
2020-03-03 13:39 ` Andrew Burgess
2020-03-03 16:29 ` Sergio Durigan Junior
2020-03-03 16:49 ` Sergio Durigan Junior [this message]
2020-03-04 10:53 ` Joel Brobecker
[not found] ` <8736al5d8s.fsf@redhat.com>
2020-03-07 11:58 ` Joel Brobecker
2020-03-09 22:56 ` Sergio Durigan Junior
2020-03-10 22:37 ` Joel Brobecker
2020-03-10 22:57 ` Sergio Durigan Junior
2020-03-10 23:13 ` Andreas Schwab
2020-03-10 23:38 ` Sergio Durigan Junior
2020-03-11 16:34 ` Sergio Durigan Junior
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=87wo81criy.fsf@redhat.com \
--to=sergiodj@redhat.com \
--cc=andrew.burgess@embecosm.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=philippe.waroquiers@skynet.be \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox