Message ID | 1435069850-11830-1-git-send-email-patrick@parcs.ath.cx |
---|---|
State | New, archived |
Headers |
Received: (qmail 126590 invoked by alias); 23 Jun 2015 14:31:07 -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 119542 invoked by uid 89); 23 Jun 2015 14:31:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-qg0-f54.google.com Received: from mail-qg0-f54.google.com (HELO mail-qg0-f54.google.com) (209.85.192.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 23 Jun 2015 14:31:03 +0000 Received: by qged89 with SMTP id d89so3689258qge.0 for <gdb-patches@sourceware.org>; Tue, 23 Jun 2015 07:31:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=W4SLvsvZPVqygseCPN/kDsfQV1lowvU33hAoAwI6HpU=; b=aFtffxpNdpl26ByT0+T+eNOj0XwcSmaa9Y/MGeIXf0bLvRt53J7QWK5tiLWZfdTMj0 nAeoRRKJM78sy7V20B0BeTDTUM1++9F7OKt03mP3yih8CWhJflORV/XuE3+boHXbGO37 rbiuibPViwUqTg9Reoq4kEWiWNFjCPZyRi9sKwMbQ34DPe7h3HVwknCeK1zburkL2FOX WJQ4n906ngc8xGxV2VsQXUp6zlmcZYLK3h8OCfHyt9G4L1YugL35EuAlZtm6KNnpchRA BCohoJdebcw3v4mGHZ8dxnS/lmck15qRjR65u4Dolv9xCywiEnH7m3nNTwJ2zC3kkLuu nS0g== X-Gm-Message-State: ALoCoQmyZWDsD4g4S7vqaaIMx9lBaOYXI5eGPYf+fGPjRNF0aep/txDUF6MxPPKAqWx8hYBQ+9d1 X-Received: by 10.55.19.225 with SMTP id 94mr73424930qkt.37.1435069861650; Tue, 23 Jun 2015 07:31:01 -0700 (PDT) Received: from localhost.localdomain (ool-4353acd8.dyn.optonline.net. [67.83.172.216]) by mx.google.com with ESMTPSA id b31sm1543160qge.5.2015.06.23.07.31.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Jun 2015 07:31:00 -0700 (PDT) From: Patrick Palka <patrick@parcs.ath.cx> To: gdb-patches@sourceware.org Cc: Patrick Palka <patrick@parcs.ath.cx> Subject: [PATCH] Fix GDBHISTSIZE test failure on i686 Date: Tue, 23 Jun 2015 10:30:50 -0400 Message-Id: <1435069850-11830-1-git-send-email-patrick@parcs.ath.cx> |
Commit Message
Patrick Palka
June 23, 2015, 2:30 p.m. UTC
The test test_histsize_history_setting "99999999999999999999999999999999999" "unlimited" was failing on i686 because the condition in init_history() for determining whether to map a large GDBHISTSIZE value to infinity was long var = strtol (tmpenv); if (var > INT_MAX) history_size = unlimited; but this condition is never true on i686 because INT_MAX == LONG_MAX. So in order to properly map large out-of-range values of GDBHISTSIZE to infinity on targets where LONG_MAX > INT_MAX as well as on i686, we have to instead change the above condition to if (var > INT_MAX || (var == INT_MAX && errno == ERANGE)) history_size = unlimited; [ I did not test this patch on i686 because I don't have access to such a machine. But the patch seems straightforward enough... ] gdb/ChangeLog: * top.c (init_history): Look at the errno set by strtol to properly map large GDBHISTSIZE values to infinity. --- gdb/top.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
Comments
On Tue, Jun 23, 2015 at 10:30 AM, Patrick Palka <patrick@parcs.ath.cx> wrote: > The test > > test_histsize_history_setting "99999999999999999999999999999999999" "unlimited" > > was failing on i686 because the condition in init_history() for > determining whether to map a large GDBHISTSIZE value to infinity was > > long var = strtol (tmpenv); > if (var > INT_MAX) > history_size = unlimited; > > but this condition is never true on i686 because INT_MAX == LONG_MAX. > So in order to properly map large out-of-range values of GDBHISTSIZE to > infinity on targets where LONG_MAX > INT_MAX as well as on i686, we have > to instead change the above condition to > > if (var > INT_MAX > || (var == INT_MAX && errno == ERANGE)) > history_size = unlimited; > > [ I did not test this patch on i686 because I don't have access to > such a machine. But the patch seems straightforward enough... ] > > gdb/ChangeLog: > > * top.c (init_history): Look at the errno set by strtol to > properly map large GDBHISTSIZE values to infinity. > --- > gdb/top.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/gdb/top.c b/gdb/top.c > index 5114c2e..afb14be 100644 > --- a/gdb/top.c > +++ b/gdb/top.c > @@ -1734,10 +1734,12 @@ init_history (void) > if (tmpenv) > { > long var; > + int saved_errno; > char *endptr; > > tmpenv = skip_spaces (tmpenv); > var = strtol (tmpenv, &endptr, 10); > + saved_errno = errno; errno should be set to 0 before the call to strtol. > endptr = skip_spaces (endptr); > > /* If GDBHISTSIZE is non-numeric then ignore it. If GDBHISTSIZE is the > @@ -1749,7 +1751,12 @@ init_history (void) > ; > else if (*tmpenv == '\0' > || var < 0 > - || var > INT_MAX) > + || var > INT_MAX > + /* On targets where INT_MAX == LONG_MAX, we have to look at > + the errno set by strtol to distinguish between a value that > + is exactly INT_MAX and an overflowing value that was clamped > + to INT_MAX. */ > + || (var == INT_MAX && saved_errno == ERANGE)) > history_size_setshow_var = -1; > else > history_size_setshow_var = var; > -- > 2.4.4.410.g43ed522.dirty >
On 06/23/2015 03:30 PM, Patrick Palka wrote: > The test > > test_histsize_history_setting "99999999999999999999999999999999999" "unlimited" > > was failing on i686 because the condition in init_history() for > determining whether to map a large GDBHISTSIZE value to infinity was > > long var = strtol (tmpenv); > if (var > INT_MAX) > history_size = unlimited; > > but this condition is never true on i686 because INT_MAX == LONG_MAX. > So in order to properly map large out-of-range values of GDBHISTSIZE to > infinity on targets where LONG_MAX > INT_MAX as well as on i686, we have > to instead change the above condition to > > if (var > INT_MAX > || (var == INT_MAX && errno == ERANGE)) > history_size = unlimited; > > [ I did not test this patch on i686 because I don't have access to > such a machine. But the patch seems straightforward enough... ] Looks fine to me, with the missing errno=0, but note that assuming you install the 32-bit dependencies in your distro, you can easily build a 32-bit gdb on a 64-bit host. E.g., on x86-64 GNU/Linux, configure with: CC="gcc -m32" /path/to/configure \ --host=i686-pc-linux-gnu \ --build=i686-pc-linux-gnu \ --target=i686-pc-linux-gnu Thanks, Pedro Alves
On Tue, Jun 23, 2015 at 12:19 PM, Pedro Alves <palves@redhat.com> wrote: >... note that assuming you > install the 32-bit dependencies in your distro, you can easily build > a 32-bit gdb on a 64-bit host. E.g., on x86-64 GNU/Linux, configure with: > > CC="gcc -m32" /path/to/configure \ > --host=i686-pc-linux-gnu \ > --build=i686-pc-linux-gnu \ > --target=i686-pc-linux-gnu --host and --target can be elided here.
On Tue, Jun 23, 2015 at 1:19 PM, Pedro Alves <palves@redhat.com> wrote: > On 06/23/2015 03:30 PM, Patrick Palka wrote: >> The test >> >> test_histsize_history_setting "99999999999999999999999999999999999" "unlimited" >> >> was failing on i686 because the condition in init_history() for >> determining whether to map a large GDBHISTSIZE value to infinity was >> >> long var = strtol (tmpenv); >> if (var > INT_MAX) >> history_size = unlimited; >> >> but this condition is never true on i686 because INT_MAX == LONG_MAX. >> So in order to properly map large out-of-range values of GDBHISTSIZE to >> infinity on targets where LONG_MAX > INT_MAX as well as on i686, we have >> to instead change the above condition to >> >> if (var > INT_MAX >> || (var == INT_MAX && errno == ERANGE)) >> history_size = unlimited; >> >> [ I did not test this patch on i686 because I don't have access to >> such a machine. But the patch seems straightforward enough... ] > > Looks fine to me, with the missing errno=0, but note that assuming you > install the 32-bit dependencies in your distro, you can easily build > a 32-bit gdb on a 64-bit host. E.g., on x86-64 GNU/Linux, configure with: > > CC="gcc -m32" /path/to/configure \ > --host=i686-pc-linux-gnu \ > --build=i686-pc-linux-gnu \ > --target=i686-pc-linux-gnu Cool. I will commit the patch after confirming that it's fixed on i686 this way. > > Thanks, > Pedro Alves >
diff --git a/gdb/top.c b/gdb/top.c index 5114c2e..afb14be 100644 --- a/gdb/top.c +++ b/gdb/top.c @@ -1734,10 +1734,12 @@ init_history (void) if (tmpenv) { long var; + int saved_errno; char *endptr; tmpenv = skip_spaces (tmpenv); var = strtol (tmpenv, &endptr, 10); + saved_errno = errno; endptr = skip_spaces (endptr); /* If GDBHISTSIZE is non-numeric then ignore it. If GDBHISTSIZE is the @@ -1749,7 +1751,12 @@ init_history (void) ; else if (*tmpenv == '\0' || var < 0 - || var > INT_MAX) + || var > INT_MAX + /* On targets where INT_MAX == LONG_MAX, we have to look at + the errno set by strtol to distinguish between a value that + is exactly INT_MAX and an overflowing value that was clamped + to INT_MAX. */ + || (var == INT_MAX && saved_errno == ERANGE)) history_size_setshow_var = -1; else history_size_setshow_var = var;