From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cEuMA8uQVmImfwAAWB0awg (envelope-from ) for ; Wed, 13 Apr 2022 04:58:51 -0400 Received: by simark.ca (Postfix, from userid 112) id 0C4261F327; Wed, 13 Apr 2022 04:58:51 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.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 998591E787 for ; Wed, 13 Apr 2022 04:58:50 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 371BF3857C71 for ; Wed, 13 Apr 2022 08:58:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 371BF3857C71 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1649840330; bh=wRrXum2A3nXVrDIdgSYs2xYGziL+OJOmqdvHicM/znI=; 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=SzCKx09AfYSuyrvcicTEt3BOz05zJRF5Jaih4VBup085YghrE0FziGlMiXbduSQN6 yUa/bDpVLHObxl1WmozPo0jkcU2WzI8Tw0cd+vJSUKarPrICSAh+7gNi92ic9Ut+gA 6iqdYRLaPBHZHnS0pHIaFCDsR+myeazPkSxpf9wA= Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id E1D2D3858C50 for ; Wed, 13 Apr 2022 08:58:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E1D2D3858C50 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 1F739210DF; Wed, 13 Apr 2022 08:58:30 +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 0B0C013AB8; Wed, 13 Apr 2022 08:58:30 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id M6tkAbaQVmL8CwAAMHmgww (envelope-from ); Wed, 13 Apr 2022 08:58:30 +0000 Message-ID: <6f5f73b0-3739-8dda-035f-01181e093860@suse.de> Date: Wed, 13 Apr 2022 10:58:29 +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: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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/12/22 08:03, Tom de Vries wrote: > 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. > Hi, any further comments? I realize you already mentioned that it seems fine to you, but given that: - you still had questions, and - I'm also planning to apply to gdb-12-branch I thought I ask. Thanks, - Tom