From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78209 invoked by alias); 1 Mar 2017 21:59:32 -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 78175 invoked by uid 89); 1 Mar 2017 21:59:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.9 required=5.0 tests=BAYES_00,KAM_ASCII_DIVIDERS,RP_MATCHES_RCVD,SPF_HELO_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=rescue, gratified, excerpts, reasoning X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Mar 2017 21:59:30 +0000 Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8679A61B8D; Wed, 1 Mar 2017 21:59:30 +0000 (UTC) Received: from fche.csb (vpn-63-4.rdu2.redhat.com [10.10.63.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3F9242D654; Wed, 1 Mar 2017 21:59:30 +0000 (UTC) Received: by fche.csb (Postfix, from userid 2569) id 54B7A58AE2; Wed, 1 Mar 2017 16:59:28 -0500 (EST) Date: Wed, 01 Mar 2017 21:59:00 -0000 From: "Frank Ch. Eigler" To: Yao Qi Cc: Alan Hayward , "gdb-patches@sourceware.org" Subject: Re: [PATCH] Remove MAX_REGISTER_SIZE from sol-thread.c Message-ID: <20170301215928.GP7871@redhat.com> References: <9C2B8A71-1050-4B8B-A27A-C620E46AB9A2@arm.com> <86d1e0rkam.fsf@gmail.com> <20170301172400.GM7871@redhat.com> <20170301211039.aagkvmdlkqn7jf5u@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170301211039.aagkvmdlkqn7jf5u@localhost> User-Agent: Mutt/1.4.2.2i X-SW-Source: 2017-03/txt/msg00016.txt.bz2 Hi - > > [...] There was one on sourceware.org, but its web interface is no > > longer operating, and scraps of the database files that are still > > archived seem not to go up to 14571. Likewise, no google hits. > > > > So I'm at a loss, can't find orginal supporting data either, and > > that's a bummer. > > Thank you all the same. Hold on! Personal email archives to the rescue. gdb/14571 was an internal Cygnus PRMS bug number. This was solaris 2.5.1 era. Here are some excerpts from emails on the topic. Please excuse the goofy "autoethnography", I'm just so weirdly gratified to have found some traces of this old work! ------------------------------------------------------------------------ The problem was caused by sol-thread.c's inability to write to individual registers in the target. The updated value got lost in sol_thread_store_registers before being written out. The following patch corrects the problem. ------------------------------------------------------------------------ >Can you send me a pointer to your toy test case? Argh - I think I zapped it accidentally. Basically it looked like this: void* thread_me(void* arg) { sleep(1); return arg; } main() { thread_t id; register int i; thr_create(NULL, NULL, thread_me, NULL, , &id); /* breakpoint here */ i = 0; i = 1; i = 2; } I fidgeted with the to get various THR_* combinations. My desired test was to be unable to change the register variable i by commands like "p (i=4)" from the debugger, after the breakpoint is hit. (Before my patch, I would expect the new value to be clobbered.) I wanted gdb to go through the sol-thread.c's register-setting function, but the bugger would not go near it. ------------------------------------------------------------------------ >[...] >Can you tell me a bit how you figured gdb/14571 out. I am >seeing more multithread releted bugs and I was hoping you >could share some hints and methods. Sure, though I must admin it was just plain ordinary perseverance rather than any special technique. As I recall, I went along steps like these: - traced backward from the "target halted while in function" call to the expression parser - figured out the mechanism used to make inferior calls (that ugly stack frame stuff, and the pre-assembled block of instructions) - convinced myself that the code should work, mostly by very slow single-stepping in the region - found the bunch of routines that get/set inferior registers - figured out weird register caching mechanism - traced it work through the thread_db & procfs calls; it worked for threads fine - found, by breakpoints, that the PC set in the cache at an earlier point was reset to an old value, before control was handed to the target - an anomaly - let a very slow watchpoint run go overnight to find who was overwriting the PC slot in the cache - eureka one morning: watchpoint triggered at around 8 AM. :) - a bug in the threads/procfs code caused the register cache to be invalidated (re-read), if not all registers were desired to be updated It was cool, but as you see, nothing very special in reasoning. I just eliminated a bunch of possible problems, and learned how registers, threads, and inferior calls were supposed to work, and then ultimately found one anomaly. The watchpoint mechanism could then (very slowly) find the anomaly's trigger. ------------------------------------------------------------------------ - FChE