From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20460 invoked by alias); 7 Feb 2017 15:04:54 -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 20419 invoked by uid 89); 7 Feb 2017 15:04:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.0 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=structs, FALSE, qiyaoltc@gmail.com, qiyaoltcgmailcom 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; Tue, 07 Feb 2017 15:04:51 +0000 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v17EtNt4108081 for ; Tue, 7 Feb 2017 10:04:50 -0500 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0a-001b2d01.pphosted.com with ESMTP id 28eupjb305-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 07 Feb 2017 10:04:49 -0500 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 7 Feb 2017 15:04:47 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 7 Feb 2017 15:04:46 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 4EA602190066 for ; Tue, 7 Feb 2017 15:03:49 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v17F4iEe8716786 for ; Tue, 7 Feb 2017 15:04:45 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C3332A4059 for ; Tue, 7 Feb 2017 15:04:41 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B28C7A4070 for ; Tue, 7 Feb 2017 15:04:41 +0000 (GMT) Received: from ThinkPad (unknown [9.152.212.148]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP for ; Tue, 7 Feb 2017 15:04:41 +0000 (GMT) Date: Tue, 07 Feb 2017 15:04:00 -0000 From: Philipp Rudo To: gdb-patches@sourceware.org Subject: Re: [RFC 3/7] Add basic Linux kernel support In-Reply-To: <20170207105403.GA1630@E107787-LIN> References: <20170112113217.48852-1-prudo@linux.vnet.ibm.com> <20170112113217.48852-4-prudo@linux.vnet.ibm.com> <20170207105403.GA1630@E107787-LIN> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17020715-0008-0000-0000-000003E3EAFC X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17020715-0009-0000-0000-00001C60D508 Message-Id: <20170207160444.34c46791@ThinkPad> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-07_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702070143 X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00154.txt.bz2 Hi Yao On Tue, 7 Feb 2017 10:54:03 +0000 Yao Qi wrote: > On 17-01-12 12:32:13, Philipp Rudo wrote: > > (ALL_TARGET_OBS): Add lk-low.o > > ALL_TARGET_OBS is used with --enable-targets=all, so if we put > lk-low.o in it, lk-low.o can't be linked into GDB if we don't enable > all targets. you kind of lost me here. As I understand it lk-low.o needs to be added to ALL_TARGET_OPS. The thing I could do is adding entries in configure.tgt. Although I'm not sure if adding lk-low to all arch*-*-linux* (like Peter did) is better than adding a general *-*-lk* target. The benefit of the first is that the target is added automatically to all linux builds. While the second allows more flexibility and turning kernel debugging on/off as needed. I don't have a strong opinion on which way to go. Do you prefer one way? > > (COMMON_OBS): Add lk-lists.o > > --- > > > + > > +/* Initialize a private data entry for an address, where NAME is > > the name > > + of the symbol, i.e. variable name in Linux, ALIAS the name used > > to > > + retrieve the entry from hashtab, and SILENT a flag to determine > > if > > + errors should be ignored. > > + > > + Returns a pointer to the new entry. In case of an error, > > either returns > > + NULL (SILENT = TRUE) or throws an error (SILENT = FALSE). If > > SILENT = TRUE > > + the caller is responsible to check for errors. > > + > > + Do not use directly, use LK_DECLARE_* macros defined in > > lk-low.h instead. */ + > > +struct lk_private_data * > > +lk_init_addr (const char *name, const char *alias, int silent) > > +{ > > + /* Initialize to NULL to silence gcc. */ > > + struct value *val = NULL; > > + struct lk_private_data *data; > > + void **new_slot; > > + void *old_slot; > > + > > + if ((old_slot = lk_find (alias)) != NULL) > > + return (struct lk_private_data *) old_slot; > > + > > + TRY > > + { > > + /* Choose global block for search, in case the variable was > > redefined > > + in the current context. */ > > + const struct block *global = block_global_block > > (get_selected_block (0)); > > + const char *tmp = name; > > + expression_up expr = parse_exp_1 (&tmp, 0, global, 0); > > Why don't you look up symbol or msymbol? like Peter's patch does. I used lookup_symbol in the beginning. But at some point it suddenly made problems and couldn't find a symbol. I actually never found out what went wrong but to parse_exp solved the problem for me. And, as it's an init function only used only once per symbol I thought that adding this extra overhead is excusable. > > + > > + gdb_assert (*tmp == '\0'); > > + val = evaluate_expression (expr.get ()); > > + } > > + CATCH (except, RETURN_MASK_ALL) > > + { > > + if (!silent) > > + error (_("Could not find address %s. Abort."), alias); > > + > > + return NULL; > > + } > > + END_CATCH > > + > > + data = XCNEW (struct lk_private_data); > > + data->alias = alias; > > + data->data.addr = value_address (val); > > + > > + new_slot = lk_find_slot (alias); > > + *new_slot = data; > > + > > + return data; > > +} > > + > > +/* Same as lk_init_addr but for structs. */ > > + > > +struct lk_private_data * > > +lk_init_struct (const char *name, const char *alias, int silent) > > +{ > > + /* Initialize to NULL to silence GCC. */ > > + struct value *val = NULL; > > + struct lk_private_data *data; > > + void **new_slot; > > + void *old_slot; > > + > > + if ((old_slot = lk_find (alias)) != NULL) > > + return (struct lk_private_data *) old_slot; > > + > > + /* There are two ways to define structs > > + o struct name { ... }; > > + o typedef struct { ... } name; > > + Both are used in the linux kernel. Thus we have to check for > > both ways. > > + We do this by first searching for "struct name" (the "struct " > > is added > > + by macro LK_STRUCT_NAME in lk-low.h) and if not found seach > > for "name". + > > + Note: The alias will always keep its "struct "-prefix, even > > when > > + given explicitely. Besides some weird error messages this has > > no effect. > > + */ > > +retry: > > + TRY > > + { > > + /* Choose global block for search, in case the struct was > > redefined > > + in the current context. */ > > + const struct block *global = > > block_global_block(get_selected_block (0)); > > + const char *tmp = name; > > + expression_up expr = parse_exp_1 (&tmp, 0, global, 0); > > Likewise. > > > + > > + gdb_assert (*tmp == '\0'); > > + /* parsing just for 'name' can cause name clashes. Thus > > also check for > > + OP_TYPE. */ > > + if (expr->elts[0].opcode != OP_TYPE) > > + error ("We just need to get to the catch block"); > > + > > + val = evaluate_type (expr.get ()); > > + } > > + CATCH (except, RETURN_MASK_ALL) > > + { > > + /* 7 = strlen ("struct "). */ > > + if (strncmp (name, "struct ", 7) == 0) > > + { > > + name += 7; > > + goto retry; > > + } > > + > > + if (!silent) > > + error (_("Could not find %s. Abort."), alias); > > + > > + return NULL; > > + } > > + END_CATCH > > + > > + data = XCNEW (struct lk_private_data); > > + data->alias = alias; > > + data->data.type = value_type (val); > > + > > + new_slot = lk_find_slot (alias); > > + *new_slot = data; > > + > > + return data; > > +} > > + > > I am playing your first three patches on x86_64 with some hacks. > I write a small program with the same linux kernel "signature", and > want GDB treat it as a linux kernel. > > (gdb) b main > Breakpoint 1 at 0x4004fa: > file /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/linux-kernel.c, > line 59. (gdb) run Starting > program: /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.base/linux-kernel/linux-kernel > Could not map thread with pid 28278, lwp 28278 to a cpu. > > I hope we can have a small test case in gdb testsuite to test linux > kernel debugging. Is it possible? We can generate a normal coredump > to linux-kernel in test, and we can also set up task_struct and expect > GDB sees some "threads". What do you think? Andreas and I had the same idea :-) I don't know If it really works. But we think its the most promising approach for the testsuite. The biggest problem I see is the relocation done for the kernel modules. Here you need to somehow mimic a dynamic linking done in the kernel. Which I suppose not to be that simple, but still doable. Thanks Philipp