From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79500 invoked by alias); 19 Jun 2017 15:46:01 -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 51666 invoked by uid 89); 19 Jun 2017 15:45:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KHOP_DYNAMIC,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=suddenly X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Jun 2017 15:45:19 +0000 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v5JFca8i002126 for ; Mon, 19 Jun 2017 11:45:12 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0a-001b2d01.pphosted.com with ESMTP id 2b64uq3eb8-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Jun 2017 11:45:12 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 19 Jun 2017 16:45:10 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 19 Jun 2017 16:45:09 +0100 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v5JFj8W016449968; Mon, 19 Jun 2017 15:45:08 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D08AB52045; Mon, 19 Jun 2017 15:41:48 +0100 (BST) Received: from ThinkPad (unknown [9.152.212.148]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 9AB1552043; Mon, 19 Jun 2017 15:41:48 +0100 (BST) Date: Mon, 19 Jun 2017 15:46:00 -0000 From: Philipp Rudo To: Yao Qi Cc: gdb-patches@sourceware.org, omair.javaid@linaro.org, yao.qi@linaro.org, peter.griffin@linaro.org, arnez@linux.vnet.ibm.com Subject: Re: [RFC v4 8/9] Link frame_info to thread_info In-Reply-To: <86tw3cnn28.fsf@gmail.com> References: <20170612170836.25174-1-prudo@linux.vnet.ibm.com> <20170612170836.25174-9-prudo@linux.vnet.ibm.com> <86tw3cnn28.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17061915-0020-0000-0000-0000038BD092 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17061915-0021-0000-0000-0000420C4AFD Message-Id: <20170619174507.0daa763a@ThinkPad> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-19_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706190262 X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00521.txt.bz2 Hi Yao On Mon, 19 Jun 2017 14:07:11 +0100 Yao Qi wrote: > Philipp Rudo writes: > > > Linux kernel stacks on S390 are spread over several memory locations. > > These locations differ for every kernel task/thread. Thus we need to know > > to which task/thread a frame belongs to check whether a stack pointer is > > valid and when to stop unwinding. To do so add a pointer to corresponding > > thread_info to frame_info. > > > > This connection already exists implicitly by the fact that switch_to_thread > > reinitializes the frame cache. > > The whole frame cache is created for current thread, from sentinel > frame. When the current thread is changed, the frame cache will be > re-created. If we see different frame_info objects are about different > threads, it must be a bug somewhere. I think frame_info.thread always > points to the current thread, no? That's also the way I understand it how it should work. My problem with it is that such implicit connections via global variables are extremely error prone and hard to debug. For example look at linux-tdep.c:linux_corefile_thread, here the code looks like this static void linux_corefile_thread (struct thread_info *info, struct linux_corefile_thread_data *args) { [...] old_chain = save_inferior_ptid (); inferior_ptid = info->ptid; target_fetch_registers (regcache, -1); [...] } At this point the inferior_ptid is changed without re-creating the frame cache. Thus the assumption that a existing frame_info always belongs to current_thread is wrong at this point. What makes it worse is that right after a target hook is called. So suddenly you have a connection between a target_obs and a gdbarch you'd never expect which can lead to a bug... For me the easiest way to prevent such long range bugs is not to use global variables but explicit connections between the different subsystems. That's why I made this patch. Philipp P.S. I know that the example is bad and you shouldn't use the frame cache to fetch registers but I hope you get the point I was trying to make.