From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id UIGkJSoWVWKtTAAAWB0awg (envelope-from ) for ; Tue, 12 Apr 2022 02:03:22 -0400 Received: by simark.ca (Postfix, from userid 112) id 599BC1F327; Tue, 12 Apr 2022 02:03:22 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 02E811E150 for ; Tue, 12 Apr 2022 02:03:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 716553857371 for ; Tue, 12 Apr 2022 06:03:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 716553857371 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1649743401; bh=9soqw21/ts4hWNbuMAwgNDnNKELh+LjGFXrUUkE3hEM=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=RlVGBLFsBVAD4/bSYE0X2TfORVNmqCzb+w5/JYTU47nl0qbJF6Vy4TCGKPviC0SE7 2L0IhbAE1R3K9Z3/GtMHClusC8prHcr1G84U9SUxp8VMDK7pk8rH0IJQ3+nmKi2q3G Df+UrhQU+wXiI/uCaIukEVC83XHO187o9iDeA2ls= Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 93FD43858C52 for ; Tue, 12 Apr 2022 06:03:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 93FD43858C52 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id C0E2C21605; Tue, 12 Apr 2022 06:03:00 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id A572F13780; Tue, 12 Apr 2022 06:03:00 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id nfe7JhQWVWIcXgAAMHmgww (envelope-from ); Tue, 12 Apr 2022 06:03:00 +0000 Message-ID: Date: Tue, 12 Apr 2022 08:03:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH][gdb/testsuite] Detect 'No MPX support' Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20220411142553.GA13322@delia.home> <330da9ef-584c-2072-83d0-fd60ee477632@simark.ca> In-Reply-To: <330da9ef-584c-2072-83d0-fd60ee477632@simark.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Tom de Vries via Gdb-patches Reply-To: Tom de Vries Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 4/11/22 17:00, Simon Marchi wrote: > On 2022-04-11 10:25, Tom de Vries via Gdb-patches wrote: >> Hi, >> >> On openSUSE Leap 15.3, mpx support has been disabled for m32, so I run into: >> ... >> (gdb) run ^M >> Starting program: outputs/gdb.arch/i386-mpx/i386-mpx ^M >> [Thread debugging using libthread_db enabled]^M >> Using host libthread_db library "/lib64/libthread_db.so.1".^M >> No MPX support^M >> ... >> and eventually into all sort of fails in this and other mpx test-cases. >> >> Fix this by detecting the "No MPX support" message in have_mpx. >> >> Tested on x86_64-linux with target boards unix and unix/-m32. >> >> Any comments? >> >> Thanks, >> - Tom >> >> [gdb/testsuite] Detect 'No MPX support' >> >> --- >> gdb/testsuite/lib/gdb.exp | 23 +++++++++++++++++++++++ >> 1 file changed, 23 insertions(+) >> >> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp >> index 2eb711748e7..9eb01e0b4b2 100644 >> --- a/gdb/testsuite/lib/gdb.exp >> +++ b/gdb/testsuite/lib/gdb.exp >> @@ -8329,6 +8329,29 @@ gdb_caching_proc have_mpx { >> >> remote_file build delete $obj >> >> + if { $status == 0 } { >> + verbose "$me: returning $status" 2 >> + return $status >> + } >> + >> + # Compile program with -mmpx -fcheck-pointer-bounds, try to trigger >> + # 'No MPX support', in other words, see if kernel supports mpx. >> + set src { int main (void) { return 0; } } >> + set comp_flags {} >> + append comp_flags " additional_flags=-mmpx" >> + append comp_flags " additional_flags=-fcheck-pointer-bounds" >> + if {![gdb_simple_compile $me-2 $src executable $comp_flags]} { >> + return 0 >> + } >> + >> + set result [remote_exec target $obj] >> + set status [lindex $result 0] >> + set output [lindex $result 1] >> + set status [expr ($status == 0) \ >> + && ![string equal $output "No MPX support\r\n"]] >> + >> + remote_file build delete $obj >> + >> verbose "$me: returning $status" 2 >> return $status >> } > > It seems fine to me. I am just wondering: > > - Who prints this "No MPX support" string exactly? Libmpx. On gcc-7-branch: ... ./libmpx/mpxrt/mpxrt.c: __mpxrt_print (VERB_DEBUG, "No MPX support.\n"); ./libmpx/mpxrt/mpxrt.c: __mpxrt_print (VERB_ERROR, "No MPX support\n"); ./libmpx/mpxrt/mpxrt.c: __mpxrt_print (VERB_ERROR, "No MPX support\n"); ... When it is printed, > is the status other than 0? If so, it wouldn't be necessary to check > for the "No MPX support" output, just check if the program runs > successfully. No, the status is the same: ... $ cat ~/min.c int main (void) { return 0; } $ gcc -mmpx -fcheck-pointer-bounds ~/min.c $ ./a.out; echo $? 0 $ gcc -mmpx -fcheck-pointer-bounds ~/min.c -m32 $ ./a.out; echo $? No MPX support 0 ... > - Why do you need to compile a separate program with -mmpx, why not the > existing test program? The existing test program tries to check for cpu support, which requires some very specific code. The added test checks for kernel support, which (because we're relying on libmpx output) AFAICT requires no particular program, so I'm using the minimal source possible. This for clarity, to prevent giving the impression in any way that the source does matter. I suppose it would be possible to use a more specific test-case that is supposed to have a different status with and without kernel support. But I don't think it makes sense to invest in that unless we run into trouble with this approach. Thanks, - Tom