From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101769 invoked by alias); 3 Feb 2017 17:45:40 -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 101722 invoked by uid 89); 3 Feb 2017 17:45:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=compete, Knowing, on-going, Hx-languages-length:4215 X-HELO: mail-wj0-f195.google.com Received: from mail-wj0-f195.google.com (HELO mail-wj0-f195.google.com) (209.85.210.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 03 Feb 2017 17:45:26 +0000 Received: by mail-wj0-f195.google.com with SMTP id kq3so1496109wjc.3 for ; Fri, 03 Feb 2017 09:45:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=G1CpjaZNngPGQecABiDXUjK3QvVGqL2U9AyGEpZPMkE=; b=VRqNvdXGLoqtJ8e5PCRPHmEfj+2g5J1YI6B50oPv8zI72iXe51FriHoMaf1fDkCUut 3zvPDUcnb96cdR1h3YbJVkHM9jq/A0f734GJlmFDCMNWH/K+K16NPt69+7ujI28uPB6L AsNGi4dTF3U4cXLCYf2lEix5n7BLJhTqbtcv9Y1j9jvUKrIpYF0AxMESvAlYEMQ6ofXq 8fR50+huODe6Po+1xHFxt4uamyn0qK5T3WupKLif4FmXnmU5gIL/shv4XY7IjIPx36lp +9Pn9LN5DFrl1z4Otf+O52iTUxpIMxX7eHWoxoO6jKPDNZUiqWp/To1IbdvEkmZD2Vn2 bhgQ== X-Gm-Message-State: AIkVDXJoBp1bTTNGtkI/9zapdpzkceEiMfBQR2LGpoLIp/+rbUMoVcgSu304VLF4W56j4Q== X-Received: by 10.223.160.114 with SMTP id l47mr13241370wrl.73.1486143924111; Fri, 03 Feb 2017 09:45:24 -0800 (PST) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id j18sm46282390wrb.33.2017.02.03.09.45.23 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 03 Feb 2017 09:45:23 -0800 (PST) Date: Fri, 03 Feb 2017 17:45:00 -0000 From: Yao Qi To: Philipp Rudo Cc: Peter Griffin , gdb-patches@sourceware.org, yao.qi@arm.com, arnez@linux.vnet.ibm.com Subject: Re: [RFC 0/7] Support for Linux kernel debugging Message-ID: <20170203174521.GC11916@E107787-LIN> References: <20170112113217.48852-1-prudo@linux.vnet.ibm.com> <20170125180950.GA10609@griffinp-ThinkPad-X1-Carbon-2nd> <20170126141225.321a5bf6@ThinkPad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170126141225.321a5bf6@ThinkPad> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00105.txt.bz2 On 17-01-26 14:12:25, Philipp Rudo wrote: > > > > Live debug of a target is the main use case we are trying to support > > with the linux-kthread patches. So for us on-going thread > > synchronisation between GDB and the Linux target is a key feature we > > need. > > For us live debugging is more a nice-to-have. That's why we > wanted to delay implementation of on-going synchronisation after the > basic structure of our code was discussed on the mailing list. So we > could avoid some work if we needed to rework it. Apparently we need to > change this plan now ;) > Nowadays, when GDB debugs normal application, it has four target layers, The current target stack is: - multi-thread (multi-threaded child process.) - native (Native process) - exec (Local exec file) - None (None) when it debugs corefile, it becomes The current target stack is: - core (Local core dump file) - exec (Local exec file) - None (None) This same can apply to kernel debugging. GDB can have the right target layer (Peter's patch) and when GDB debugs kernel dump, GDB has the target layer from your patch. We can share something between these two target layers. I think all code about parsing kernel data structures can be shared. Even more, we can add a shared target layer for linux kernel debugging, and live debugging target layer and dump debugging target layer can sit on top it. They can use the beneath linux kernel target layer to fetch registers, get thread names, etc. > > > 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. > > > > How do you stack a userspace target on top with a coredump? > > You don't. At least with the current code base it is impossible. > > Andreas and I see the ravenscar-approach as a workaround for > limitations in GDB. Thus while discussing it we thought about possible > scenarios for the future which would be impossible to implement using > this approach. The userspace-on-kernel was just meant to be an example. > Other examples would be a Go target where the libthreaddb > (POSIX-threads) and Go (goroutines) targets would compete on > thread stratum. Or (for switching targets) a program that runs > simultaneous on CPU and GPU and needs different targets for both code > parts. > IMO, https://sourceware.org/gdb/wiki/MultiTarget is the right way to solve such problem. We can have one JTAG remote target debugging kernel, and one GDBserver debugging user-space app on that machine. > > > 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. > > > > Is this a feature you are actively using today with the coredump > > (stacking userspace)? > > We are not using it, as discussed above. In particular with our dumps > it is even impossible as we strip it of all userspace memory (a crash > of our build server created a ~9 GB dump (kdump, kernelspace only) > imagine adding all of userspace to that ...). But for live debugging or > smaller systems it could be an interesting scenario to find bugs > triggered by "buggy" userspace behavior. > With MultiTarget in place, we need to somehow associate a function call in one target to another function in another different target. A user-space program call a syscall and trap into kernel, GDB just associate the user-space call stack on one target with the right kernel space call stack in another target. I remember some one presented something on GDB show stack traces across over RPC calls in the GNU Cauldron several years. This is about live debugging. -- Yao (齐尧)