Message ID | 564F998D.5080406@gmail.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 5467 invoked by alias); 20 Nov 2015 22:07:16 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 5441 invoked by uid 89); 20 Nov 2015 22:07:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lf0-f48.google.com Received: from mail-lf0-f48.google.com (HELO mail-lf0-f48.google.com) (209.85.215.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 20 Nov 2015 22:07:14 +0000 Received: by lfs39 with SMTP id 39so77640413lfs.3 for <gdb-patches@sourceware.org>; Fri, 20 Nov 2015 14:07:10 -0800 (PST) X-Received: by 10.25.28.70 with SMTP id c67mr5856319lfc.95.1448057230579; Fri, 20 Nov 2015 14:07:10 -0800 (PST) Received: from [10.0.2.15] ([91.215.122.25]) by smtp.gmail.com with ESMTPSA id 194sm189005lfd.4.2015.11.20.14.07.09 for <gdb-patches@sourceware.org> (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Nov 2015 14:07:09 -0800 (PST) To: gdb-patches@sourceware.org From: Ruslan Kabatsayev <b7.10110111@gmail.com> Subject: [PATCH][PR 18702] Fix wrong output of x87 registers due to truncation to double on amd64 Message-ID: <564F998D.5080406@gmail.com> Date: Sat, 21 Nov 2015 01:07:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit |
Commit Message
Ruslan Kabatsayev
Nov. 20, 2015, 10:07 p.m. UTC
When `info float` is used on an AMD64 system, GDB prints floating-point values of x87 registers with raw contents like 0x361a867a8e0527397ce0 or 0xc4f988454a1ddd3cfdab wrongly. This happens due to truncation to double, after which the former becomes 0.0, and the latter becomes negative infinity. This is caused by failed detection of x86-64 host, which results in setting gdb_host_{float,double,long_double}_format to zeros. This commit fixes this misdetection. gdb/ChangeLog: * configure.host: Fix detection of x86_64 host when setting floatformats --- gdb/configure.host | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Ruslan Kabatsayev <b7.10110111@gmail.com> writes: Hi Ruslan, > When `info float` is used on an AMD64 system, GDB prints floating-point > values of x87 registers with raw contents like 0x361a867a8e0527397ce0 or > 0xc4f988454a1ddd3cfdab wrongly. This happens due to truncation to double, > after which the former becomes 0.0, and the latter becomes negative infinity. > This is caused by failed detection of x86-64 host, which results in setting > gdb_host_{float,double,long_double}_format to zeros. > This commit fixes this misdetection. I think your patch is correct, but I am not confident approving it because I know few about floating point stuff. Do you run GDB regression tests? > > gdb/ChangeLog: > > * configure.host: Fix detection of x86_64 host when setting floatformats This line is too long, the max is 74. Sentence should be ended with ".".
Hi Yao, Thanks for your reply. On Wed, Dec 2, 2015 at 2:32 PM, Yao Qi <qiyaoltc@gmail.com> wrote: > I think your patch is correct, but I am not confident approving it > because I know few about floating point stuff. Do you run GDB > regression tests? I did a `make check` for unpatched gdb-7.10 and patched with my changes. Here's the unpatched result: # of expected passes 32377 # of unexpected failures 85 # of unexpected successes 2 # of expected failures 72 # of unknown successes 2 # of known failures 62 # of untested testcases 36 # of unsupported tests 201 And here's after my patch: # of expected passes 32378 # of unexpected failures 85 # of unexpected successes 2 # of expected failures 71 # of unknown successes 2 # of known failures 62 # of untested testcases 36 # of unsupported tests 201 I.e. one "expected failure" less and one "expected pass" more. I'm not sure how to interpret this result. >> gdb/ChangeLog: >> >> * configure.host: Fix detection of x86_64 host when setting floatformats > > This line is too long, the max is 74. Sentence should be ended with ".". Should I resend the whole original mail with this fixed? Regards, Ruslan
Ruslan Kabatsayev <b7.10110111@gmail.com> writes: > I did a `make check` for unpatched gdb-7.10 and patched with my > changes. Here's the unpatched result: Thanks for running the test. Could you test your patch against GDB git mainline please? The patch will be applied to mainline, so we need to test it against mainline. > > # of expected passes 32377 > # of unexpected failures 85 > # of unexpected successes 2 > # of expected failures 72 > # of unknown successes 2 > # of known failures 62 > # of untested testcases 36 > # of unsupported tests 201 > > And here's after my patch: > > # of expected passes 32378 > # of unexpected failures 85 > # of unexpected successes 2 > # of expected failures 71 > # of unknown successes 2 > # of known failures 62 > # of untested testcases 36 > # of unsupported tests 201 > > I.e. one "expected failure" less and one "expected pass" more. I'm not > sure how to interpret this result. > This may happen from time to time, especially in some gdb.threads tests. >>> gdb/ChangeLog: >>> >>> * configure.host: Fix detection of x86_64 host when setting >>> floatformats >> >> This line is too long, the max is 74. Sentence should be ended with ".". > > Should I resend the whole original mail with this fixed? Please post the changelog entry only for the reference. If there is no regression in the GDB mainline tests, and no objections from other people in 3 days, your patch can go in. Do you have write access to git repository and FSF copyright assignment? If you don't have them, I can commit it for you as a tiny patch. However, if you want to contribute more patches, you need an FSF copyright assignment, and git write access, so that you can push by yourself.
On 11/20/2015 10:07 PM, Ruslan Kabatsayev wrote: > When `info float` is used on an AMD64 system, GDB prints floating-point > values of x87 registers with raw contents like 0x361a867a8e0527397ce0 or > 0xc4f988454a1ddd3cfdab wrongly. This happens due to truncation to double, > after which the former becomes 0.0, and the latter becomes negative infinity. > This is caused by failed detection of x86-64 host, which results in setting > gdb_host_{float,double,long_double}_format to zeros. > This commit fixes this misdetection. A test to make sure we don't regress this would be nice. Maybe add something to gdb.arch/i386-float.exp ? Thanks, Pedro Alves
On 12/03/2015 02:27 PM, Yao Qi wrote: > Thanks for running the test. Could you test your patch against GDB git > mainline please? The patch will be applied to mainline, so we need to > test it against mainline. With current git master the result is the same: no noticeable changes between patched and unpatched version. >> # of expected passes 32377 >> # of unexpected failures 85 >> # of unexpected successes 2 >> # of expected failures 72 >> # of unknown successes 2 >> # of known failures 62 >> # of untested testcases 36 >> # of unsupported tests 201 >> >> And here's after my patch: >> >> # of expected passes 32378 >> # of unexpected failures 85 >> # of unexpected successes 2 >> # of expected failures 71 >> # of unknown successes 2 >> # of known failures 62 >> # of untested testcases 36 >> # of unsupported tests 201 >> >> I.e. one "expected failure" less and one "expected pass" more. I'm not >> sure how to interpret this result. >> > This may happen from time to time, especially in some gdb.threads tests. For some reason such things happen with different individual tests almost on every `make check` here, be it patched or unpatched version. >>>> gdb/ChangeLog: >>>> >>>> * configure.host: Fix detection of x86_64 host when setting >>>> floatformats >>> This line is too long, the max is 74. Sentence should be ended with ".". >> Should I resend the whole original mail with this fixed? > Please post the changelog entry only for the reference. gdb/ChangeLog: * configure.host: Fix detection of x86_64 host when setting floatformats. > If there is no regression in the GDB mainline tests, and no objections > from other people in 3 days, your patch can go in. > > Do you have write access to git repository and FSF copyright assignment? > If you don't have them, I can commit it for you as a tiny patch. > However, if you want to contribute more patches, you need an FSF > copyright assignment, and git write access, so that you can push by yourself. I think I don't. How do I get them? As for more patches, I'm going to make a regression test for this fix, as suggested by Pedro Alves in another email.
On Thu, Dec 3, 2015 at 3:28 PM, Pedro Alves <palves@redhat.com> wrote: > A test to make sure we don't regress this would be nice. > Maybe add something to gdb.arch/i386-float.exp ? I think I'll do this. Should this go as a separate patch? > > Thanks, > Pedro Alves >
On 12/04/2015 03:06 PM, Ruslan Kabatsayev wrote: > On Thu, Dec 3, 2015 at 3:28 PM, Pedro Alves <palves@redhat.com> wrote: >> A test to make sure we don't regress this would be nice. >> Maybe add something to gdb.arch/i386-float.exp ? > > I think I'll do this. Should this go as a separate patch? Ideally it'd go in the same patch. Thanks, Pedro Alves
On Fri, Dec 4, 2015 at 6:11 PM, Pedro Alves <palves@redhat.com> wrote: > On 12/04/2015 03:06 PM, Ruslan Kabatsayev wrote: >> On Thu, Dec 3, 2015 at 3:28 PM, Pedro Alves <palves@redhat.com> wrote: >>> A test to make sure we don't regress this would be nice. >>> Maybe add something to gdb.arch/i386-float.exp ? >> >> I think I'll do this. Should this go as a separate patch? > > Ideally it'd go in the same patch. Oh, OK. What about email subject? Can I just send it as a follow-up to this conversation, or does it have to be an independent email with subject="[PATCH]..."? Or is there no difference? (Sorry for silly questions, I'm just trying to fulfill all the requirements at the first try :) ) > > Thanks, > Pedro Alves >
On 12/04/2015 03:16 PM, Ruslan Kabatsayev wrote: > On Fri, Dec 4, 2015 at 6:11 PM, Pedro Alves <palves@redhat.com> wrote: >> On 12/04/2015 03:06 PM, Ruslan Kabatsayev wrote: >>> On Thu, Dec 3, 2015 at 3:28 PM, Pedro Alves <palves@redhat.com> wrote: >>>> A test to make sure we don't regress this would be nice. >>>> Maybe add something to gdb.arch/i386-float.exp ? >>> >>> I think I'll do this. Should this go as a separate patch? >> >> Ideally it'd go in the same patch. > Oh, OK. What about email subject? Can I just send it as a follow-up to > this conversation, or does it have to be an independent email with > subject="[PATCH]..."? Or is there no difference? > (Sorry for silly questions, I'm just trying to fulfill all the > requirements at the first try :) ) As it's a single patch, reply is fine. Repost as new thread would be fine too. Ideally tagged with "[PATCH v2]" in that case. I suggest using "git send-email" to send patches. Thanks, Pedro Alves
diff --git a/gdb/configure.host b/gdb/configure.host index 48714f4..ef265eb 100644 --- a/gdb/configure.host +++ b/gdb/configure.host @@ -195,7 +195,7 @@ esac # "double" and "long double" types. case "${host}" in -i[34567]86-*-*) +i[34567]86-*-*|x86_64-*-*) gdb_host_float_format="&floatformat_ieee_single_little" gdb_host_double_format="&floatformat_ieee_double_little" gdb_host_long_double_format="&floatformat_i387_ext"