From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124948 invoked by alias); 9 Jan 2018 18:27:01 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 124863 invoked by uid 89); 9 Jan 2018 18:27:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:sk:cm13.we, Hx-spam-relays-external:100.42.49.6, H*RU:sk:cm13.we, H*RU:100.42.49.6 X-HELO: gateway32.websitewelcome.com Received: from gateway32.websitewelcome.com (HELO gateway32.websitewelcome.com) (192.185.145.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Jan 2018 18:26:58 +0000 Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 14954F0A21C for ; Tue, 9 Jan 2018 12:26:56 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id Yybwez423BUMKYybwe7BkM; Tue, 09 Jan 2018 12:26:56 -0600 Received: from 71-218-90-63.hlrn.qwest.net ([71.218.90.63]:34438 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eYybv-002ReV-S5; Tue, 09 Jan 2018 12:26:55 -0600 From: Tom Tromey To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFA] Fix scm-ports.exp regression References: <20180103182048.8495-1-tom@tromey.com> <37ddb96c-2b32-2fcd-9c36-17f32d8701e3@redhat.com> Date: Tue, 09 Jan 2018 18:27:00 -0000 In-Reply-To: <37ddb96c-2b32-2fcd-9c36-17f32d8701e3@redhat.com> (Pedro Alves's message of "Fri, 5 Jan 2018 17:01:54 +0000") Message-ID: <87efmykhw1.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Source-L: No X-Exim-ID: 1eYybv-002ReV-S5 X-Source-Sender: 71-218-90-63.hlrn.qwest.net (pokyo) [71.218.90.63]:34438 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2018-01/txt/msg00189.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: >> I think the simplest fix is to use "print/u" rather than "print/d" to >> get the value of sp_reg in the test case. Pedro> Can you expand a bit on this rationale, please? Pedro> There's: Pedro> (parse-and-eval \"*(char*) \$sp\") Pedro> in the context of the diff. Is that related? I ask because Pedro> that "char" in there would look like something that could print Pedro> as signed or unsigned depending on target. I don't think that is related. That expression has a dereference. What happens is that on x86, this: set sp_reg [get_integer_valueof "\$sp" 0] ... ends up setting sp_reg to a negative value, because get_integer_valueof uses "print/d": print /d $sp $1 = -11496 Then later the test suite does: gdb_test "guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))" \ "= $sp_reg" \ "seek to \$sp" ... expecting this value to be identical to the saved $sp_reg value. However it gets: guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET)) = 4294955800 "print" is just a wrapper for guile's format: gdb_test_no_output "guile (define (print x) (format #t \"= ~A\" x) (newline))" The seek function returns a scm_t_off, so I would think that this sort of printing is handled by guile, not by gdb. IIRC what happened is that "print/d" slightly changed in some cases during the scalar printing work, and what we're seeing is the result. Tom