From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21041 invoked by alias); 2 Jul 2015 10:09:58 -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 21032 invoked by uid 89); 2 Jul 2015 10:09:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f171.google.com Received: from mail-pd0-f171.google.com (HELO mail-pd0-f171.google.com) (209.85.192.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 02 Jul 2015 10:09:56 +0000 Received: by pdjd13 with SMTP id d13so42784880pdj.0 for ; Thu, 02 Jul 2015 03:09:54 -0700 (PDT) X-Received: by 10.70.37.43 with SMTP id v11mr23105435pdj.89.1435831794467; Thu, 02 Jul 2015 03:09:54 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id pz9sm5103468pbb.93.2015.07.02.03.09.52 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 02 Jul 2015 03:09:53 -0700 (PDT) From: Yao Qi To: Walfred Tedeschi Cc: "Yao Qi \\; Patrick Palka \\; Doug Evans \\; Keith Seitz \\; gdb-patches" Subject: Re: Several regressions and we branch soon. References: <5589BECB.7090200@redhat.com> <86mvzpqq1z.fsf@gmail.com> <86pp4cp8ii.fsf@gmail.com> <5593B32F.6070503@intel.com> Date: Thu, 02 Jul 2015 10:09:00 -0000 In-Reply-To: <5593B32F.6070503@intel.com> (Walfred Tedeschi's message of "Wed, 01 Jul 2015 11:30:23 +0200") Message-ID: <86wpyioope.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00073.txt.bz2 Walfred Tedeschi writes: >> - if program doesn't set mpx bounds at all, GDB attaches to the progra= m, >> and set mpx bounds, when GDB detaches from this program, does GDB >> need to clear these mpx bounds it sets? > In case program does not set bounds GDB will also not able to set > bounds. Basically idea is to have bounds as variables. > Once user has modified its done. so GDB can only update and show the mpx bounds set in the program, is it co= rrect? >> - if program does set mpx bounds too (through mpx instructions or >> compiler builtins), do we expect GDB to show these mpx bounds too? > No. Same as above. Your answer to Q1 is contradictive to it. >> - If program sets mpx bounds through mxp instructions and GDB sets mpx >> bounds too, does this interfere each other? or program's mxp bounds >> setting is stored in bnd0-bnd3, but GDB's mpx bound setting is bound >> directory and bound table, so this doesn't interfere each other? > > Yes. Like it happens with variables location dependent variables. Sorry, I don't understand what does "Yes" mean to my alternative question. What are "variables location dependent variables"? > To be able to to set bounds also on registers and tables and make them > sync we need debug information. Can you elaborate on this? Why do we need debug information? AFAIK, bounds are stored in either registers and tables, GDB can read them from registers and tables, and show them. > The solution by now is without. In this sense user has to know a bit > of assembler to know where to set the bounds, for the case it being > debugged. --=20 Yao (=E9=BD=90=E5=B0=A7)