From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109603 invoked by alias); 12 Jan 2017 11:32:35 -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 109520 invoked by uid 89); 12 Jan 2017 11:32:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=everybody, contrast, peters, philipp X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Jan 2017 11:32:24 +0000 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0CBT9oJ146989 for ; Thu, 12 Jan 2017 06:32:23 -0500 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0a-001b2d01.pphosted.com with ESMTP id 27x8a59nke-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Jan 2017 06:32:22 -0500 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 12 Jan 2017 11:32:20 -0000 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 12 Jan 2017 11:32:18 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id D1CBF17D8042; Thu, 12 Jan 2017 11:35:09 +0000 (GMT) Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v0CBWI3554067340; Thu, 12 Jan 2017 11:32:18 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9C0E252043; Thu, 12 Jan 2017 10:30:47 +0000 (GMT) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTPS id 6832E5203F; Thu, 12 Jan 2017 10:30:47 +0000 (GMT) From: Philipp Rudo To: gdb-patches@sourceware.org Cc: peter.griffin@linaro.org, yao.qi@arm.com, arnez@linux.vnet.ibm.com Subject: [RFC 0/7] Support for Linux kernel debugging Date: Thu, 12 Jan 2017 11:32:00 -0000 X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17011211-0016-0000-0000-00000426768A X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17011211-0017-0000-0000-0000260F7C5B Message-Id: <20170112113217.48852-1-prudo@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-12_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=14 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701120162 X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00214.txt.bz2 Hi Peter Hi everybody else This series implements a new Linux kernel target very similar to Peters patch sent shortly before Christmas [1]. In contrast to Peter, i concentrated on core dumps on S390. Thus there are some differences and we can benefit from each other. The series's structure is the following. Patch 1 and 2 contain small, general changes independent of the actual target which are a pre-req for the rest. Patch 3 contains the basic target with the same functionality of Peters patch. Patch 4 contains the implementation for module handling and kernel virtual addresses. Patch 5 contains some commands as a byproduct of development. Its main purpose is to start a discussion how (C++/Python) and where (GDB/kernel) commands for the target schould be implemented. Finally patch 6 and 7 contain the S390 specific code with patch 7 containing the logic needed for the target. The patches apply to and compile with the current master. You need --enable-targets=all to compile. While the basic structure is very similar i made some different design decisions compared to Peter. Most notably i store the needed private data in a libiberty/htab (shouldn't be much of a problem to move to std::unordered_map) with the variables name as key and its address/struct type/struct field as value. Thus it is closer to the approach using std::array Yao suggested [2]. In addition i also have a implementation to handle kernel modules. Together with this goes the handling of kernel virtual addresses which i quite like. Unfortunately generalizing this handling to any kind of virtual address would need a mechanism to pass the address space to target_xfer_partial. The biggest drawback of my design currently is the mapping between the CPUs and the task_strucs of the running tasks. Currently the mapping is static, i.e. it is generated once at initialization and cannot be updated. Knowing this weakness i discussed quite long with Andreas how to improve it. In this context we also discussed the reavenscar-approach Peter is using. In the end we decided against this approach. In particular we discussed a scenario when you also stack a userspace target on top of the kernel target. In this case you would have three different views on threads (hardware, kernel, userspace). With the ravenscar-approach this scenario is impossible to implement as the private_thread_info is already occupied by the kernel target and the userspace would have no chance to use it. Furthermore you would like to have the possibility to switch between different views, i.e. see what the kernel and userspace view on a given process is. The idea to solve this is to move the global thread_list to the target and allow mapping between the threads of the different list. Thus every target can manage its own threads. Furthermore there needs to be a way to allow several targets at the same time and a way for the user to switch between them. Of course this idea would need some work to implement ... Unfortunately there is no way to test the code unless you have access to an S390 machine. But if you like and give me some time i can try to make an dump available to you. Cross debugging shouldn't be a problem. Any kind of feedback is welcome. Kind regards Philipp [1] https://sourceware.org/ml/gdb-patches/2016-12/msg00382.html [2] https://sourceware.org/ml/gdb-patches/2017-01/msg00183.html Philipp Rudo (7): Convert substitute_path_component to C++ Add libiberty/concat styled concat_path function Add basic Linux kernel support Add kernel module support for linux-kernel target Add commands for linux-kernel target Add privileged registers for s390x Add S390 support for linux-kernel target gdb/Makefile.in | 16 + gdb/auto-load.c | 18 +- gdb/common/common-utils.h | 16 +- gdb/features/Makefile | 11 +- gdb/features/s390-cr.xml | 26 + gdb/features/s390x-cr-linux64.c | 99 ++++ gdb/features/s390x-cr-linux64.xml | 24 + gdb/features/s390x-vxcr-linux64.c | 169 ++++++ gdb/features/s390x-vxcr-linux64.xml | 25 + gdb/gdbarch.c | 31 ++ gdb/gdbarch.h | 8 + gdb/gdbarch.sh | 4 + gdb/lk-cmds.c | 248 +++++++++ gdb/lk-cmds.h | 25 + gdb/lk-lists.c | 47 ++ gdb/lk-lists.h | 56 ++ gdb/lk-low.c | 964 ++++++++++++++++++++++++++++++++++ gdb/lk-low.h | 330 ++++++++++++ gdb/lk-modules.c | 412 +++++++++++++++ gdb/lk-modules.h | 29 + gdb/regformats/s390x-cr-linux64.dat | 76 +++ gdb/regformats/s390x-vxcr-linux64.dat | 108 ++++ gdb/s390-linux-tdep.c | 390 +++++++++++++- gdb/s390-linux-tdep.h | 86 ++- gdb/solib.c | 8 + gdb/solib.h | 5 + gdb/typeprint.c | 8 +- gdb/typeprint.h | 2 + gdb/utils.c | 88 ++-- gdb/utils.h | 26 +- 30 files changed, 3294 insertions(+), 61 deletions(-) create mode 100644 gdb/features/s390-cr.xml create mode 100644 gdb/features/s390x-cr-linux64.c create mode 100644 gdb/features/s390x-cr-linux64.xml create mode 100644 gdb/features/s390x-vxcr-linux64.c create mode 100644 gdb/features/s390x-vxcr-linux64.xml create mode 100644 gdb/lk-cmds.c create mode 100644 gdb/lk-cmds.h create mode 100644 gdb/lk-lists.c create mode 100644 gdb/lk-lists.h create mode 100644 gdb/lk-low.c create mode 100644 gdb/lk-low.h create mode 100644 gdb/lk-modules.c create mode 100644 gdb/lk-modules.h create mode 100644 gdb/regformats/s390x-cr-linux64.dat create mode 100644 gdb/regformats/s390x-vxcr-linux64.dat -- 2.8.4