From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id D3B273851C20 for ; Fri, 8 May 2020 15:16:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D3B273851C20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.193] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id E47811E5F9; Fri, 8 May 2020 11:16:38 -0400 (EDT) Subject: Re: [PATCH][gdb] Fix stepping over fork with follow-fork-mode child and gcc-8 To: Tom de Vries , gdb-patches@sourceware.org Cc: Pedro Alves References: <20200507050409.GA30601@delia> From: Simon Marchi Message-ID: <35196fcc-a6f4-c2ac-9cd5-70f5d0966cbe@simark.ca> Date: Fri, 8 May 2020 11:16:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200507050409.GA30601@delia> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_NUMSUBJECT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 08 May 2020 15:16:42 -0000 On 2020-05-07 1:04 a.m., Tom de Vries wrote: > Hi, > > When running test-case gdb.threads/fork-child-threads.exp with gcc-8 instead > of gcc-7, we have: > ... > (gdb) next^M > [Attaching after Thread 0x7ffff7fae740 (LWP 27574) fork to child process \ > 27578]^M > [New inferior 2 (process 27578)]^M > [Detaching after fork from parent process 27574]^M > [Inferior 1 (process 27574) detached]^M > [Thread debugging using libthread_db enabled]^M > Using host libthread_db library "/lib64/libthread_db.so.1".^M > [Switching to Thread 0x7ffff7fae740 (LWP 27578)]^M > -main () at src/gdb/testsuite/gdb.threads/fork-child-threads.c:41^M > +main () at src/gdb/testsuite/gdb.threads/fork-child-threads.c:34^M > -41 i = pthread_create (&thread, NULL, start, NULL);^M > +34 switch (fork ())^M > -(gdb) PASS: gdb.threads/fork-child-threads.exp: next over fork > +(gdb) FAIL: gdb.threads/fork-child-threads.exp: next over fork > ... > > This is due to the fact that gcc-8 generates more precise line info, making > the instruction after the call to fork a "recommended breakpoint location". > However, it is a bug because next is supposed to move to the next source > line. > > The problem is that in process_event_stop_test we hit this code: > ... > if ((ecs->event_thread->suspend.stop_pc == stop_pc_sal.pc) > && (ecs->event_thread->current_line != stop_pc_sal.line > || ecs->event_thread->current_symtab != stop_pc_sal.symtab)) > { > if (stop_pc_sal.is_stmt) > { > /* We are at the start of a different line. So stop. Note that > we don't stop if we step into the middle of a different line. > That is said to make things like for (;;) statements work > better. */ > if (debug_infrun) > fprintf_unfiltered (gdb_stdlog, > "infrun: stepped to a different line\n"); > end_stepping_range (ecs); > return; > } > ... > because current_line and current_symtab have initial values: > ... > (gdb) p ecs->event_thread->current_line > $8 = 0 > (gdb) p ecs->event_thread->current_symtab > $9 = (symtab *) 0x0 > ... > > Fix this in follow_fork by copying current_line and current_symtab from > parent thread to child thread. > > Tested on x86_64-linux, with gcc 7.5.0 and gcc 10.0.1. > > OK for trunk? Hi Tom, The change makes sense to me, although I don't know this code in depth (things related to lines and SaL). But I confirm that it fixes on my machine the same FAIL that you see. Simon