From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86064 invoked by alias); 17 Jul 2019 12:00:27 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 85217 invoked by uid 89); 17 Jul 2019 12:00:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,MIME_QP_LONG_LINE autolearn=ham version=3.3.1 spammy=Proposal, stopped, nicole, HTo:U*gdb X-HELO: mga09.intel.com Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Jul 2019 12:00:24 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2019 05:00:21 -0700 Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga001.jf.intel.com with ESMTP; 17 Jul 2019 05:00:20 -0700 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.234]) by irsmsx105.ger.corp.intel.com ([169.254.7.164]) with mapi id 14.03.0439.000; Wed, 17 Jul 2019 13:00:20 +0100 From: "Saiapova, Natalia" To: "Saiapova, Natalia" , "gdb@sourceware.org" CC: "Metzger, Markus T" Subject: RE: Proposal: scheduler-locking during inferior calls Date: Wed, 17 Jul 2019 12:00:00 -0000 Message-ID: <0684A59A727D094BB8A375CE8D2ED8A963F72692@IRSMSX106.ger.corp.intel.com> References: <0684A59A727D094BB8A375CE8D2ED8A963F66B75@IRSMSX106.ger.corp.intel.com> In-Reply-To: <0684A59A727D094BB8A375CE8D2ED8A963F66B75@IRSMSX106.ger.corp.intel.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00006.txt.bz2 > -----Original Message----- >=20 > Dear All, >=20 > In multithreaded program, when several threads are stopped at a breakpoin= t and > scheduler-locking mode is not 'on', there might be unexpected thread swit= ches > during an inferior call evaluation. If such thread switching occurs, > the evaluation of the inferior call is abandoned: >=20 > ~~~ > (gdb) run > Thread 1 "a.out" hit Breakpoint 2, main._omp_fn.0(void) () at multi-omp.c= pp:18 > 18 std::cout << omp_get_thread_nu= m(); > (gdb) call do_something() > [Switching to Thread 0x7ffff6327700 (LWP 32498)] >=20 > Thread 3 "a.out" hit Breakpoint 2, main._omp_fn.0(void) () at multi-omp.c= pp:18 > 18 std::cout << omp_get_thread_nu= m(); > The program stopped in another thread while making a function call from G= DB. > Evaluation of the expression containing the function > (do_something()) will be abandoned. > When the function is done executing, GDB will silently stop. > ~~~ >=20 > The similar problem happens with stepping commands, however, for these we= have > 'step' scheduler-locking mode. We could add a new scheduler locking mode = that > will handle inferior calls. But it is highly likely, that this mode would > be used together with 'step'. If we blend step locking into the new mode, > one might also want to include the replay, and then the number of possible > combinations explodes. It does not seem to be flexible and scalable solut= ion. > And if the new mode locks only inferior calls, it will not be user-friend= ly, > since then a user will be forced to switch modes during the debugging. >=20 > I would like to propose a change of existing scheduler-locking mechanism,= which > will give a user fine-granular control over the scheduler lock. The user = will > define his or her own mode based on options that he or she could set > independently: >=20 > ~~~ > (gdb) set scheduler-locking step on > (gdb) set scheduler-locking eval on > (gdb) set scheduler-locking replay on > (gdb) set scheduler-locking run off > (gdb) show scheduler-locking > Scheduler-locking mode: > step on > eval on > replay on > run off > ~~~ >=20 > Here 'eval' represents inferior calls, and 'run' represents 'continue' and > 'finish' commands. >=20 > However, these will not be backward compatible with the current 'set/show > scheduler-locking' commands. As I am not sure, that pros of this change w= ill > outweigh the backward incompatibility, I have added a command > 'set scheduler-locking-eval' as a work-around. It toggles scheduler locki= ng > for inferior calls and coexists with current scheduler-locking modes > (so it could be used together with or without step or replay modes). >=20 > I would appreciate other opinions about this problem and its possible sol= utions. Currently, if we want to execute an inferior call in multithreaded program,= =20 we have to switch scheduler-locking to 'on' before the call, and then, swit= ch it back to 'step' or 'replay' after the call. I could think about three options how we could improve scheduler locking fo= r this case: add a new mode, add a new set/show command (example from my first email), or modify the existing locking mechanism (the proposed solution). The easiest solution would be a creation of a new mode (that was actually=20 my first attempt). The mode was called 'step+' and covered all three optio= ns: 'step', 'replay', and 'inferior calls'. But I believe, that was not=20 very user-friendly. This mode did not fit well to the current list: it not= =20 only added a new locking option, but also included already existing ones. The second option is only a temporary workaround for the problem (I attache= d the example to my first email). The third option is not backward compatible, however, I believe, it would m= ake the scheduler locking UI more transparent to a user. As far as I could see= ,=20 current scheduler-locking modes do not contradict with each other, so if th= e=20 interface allowed it, they could be mixed. From the code perspective,=20 the proposed change should not be big and will involve only infrun.c: 1. Instead of storing the current mode in 'scheduler_mode' variable, we wil= l store=20 a structure of all options ~~~ static struct {=20 int replay =3D 1; int step =3D 0; int eval =3D 0; int run =3D 0; } scheduler_locking; ~~~ 2. Modify 'schedlock_applies' function; 3. Modify user_visible_resume_ptid (possibly, also use 'schedlock_applies' = there; 4. Modify 'clear_proceed_status' to use 'scheduler_locking.replay'. If the proposed change sounds sensible I could create a patch. --Natalia Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928