From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125711 invoked by alias); 7 Feb 2017 10:54:17 -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 125687 invoked by uid 89); 7 Feb 2017 10:54:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=BAYES_40,FREEMAIL_FROM,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=structs, FALSE, TRY, CATCH X-HELO: mail-wr0-f196.google.com Received: from mail-wr0-f196.google.com (HELO mail-wr0-f196.google.com) (209.85.128.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Feb 2017 10:54:14 +0000 Received: by mail-wr0-f196.google.com with SMTP id 89so5297818wrr.1 for ; Tue, 07 Feb 2017 02:54:13 -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=wFIRbTYjvrgOpfafSDilhNKVNMPqUXVbEGcANtBw3HM=; b=RRX4hhNZLgICuy5ywg0GYQrUK/yuSaJs57pX7rApdRBOtE4rfQ9AzaU2jpy48oNN6k 9UafuhU7nHASo2u09ggVUzi7RngsnorNsLc6RYMmea8sB35mF0MQ+QkSgHMrvzoNvJpT eFHi6Wf08z57WnmE1JvIysmJPJeSHB6H0ZfzxVms0txONQiLLmWRUWvDDNHra3dRNFdC 682csadRyQdrZznzktyjciP+1OWrGu8QqUICob1mOubmWhqTyhe0ihtrM8A3xDTsglxC oxeqojXiMg0SeF7+++3ZVYXsx+R3EsMEeTCpyVXqcO+HfFfgvosQOBfN9xPd0LG/XAZ5 H5hg== X-Gm-Message-State: AIkVDXK9P38a8Qna6cYOqF01FOzAJ1/CteM6cwxKvokLSiB/rKMyrsbM60I3hJ4paKD97g== X-Received: by 10.223.151.138 with SMTP id s10mr13174698wrb.65.1486464851895; Tue, 07 Feb 2017 02:54:11 -0800 (PST) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id 18sm6689574wrb.14.2017.02.07.02.54.10 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 07 Feb 2017 02:54:11 -0800 (PST) Date: Tue, 07 Feb 2017 10:54:00 -0000 From: Yao Qi To: Philipp Rudo Cc: gdb-patches@sourceware.org, peter.griffin@linaro.org, yao.qi@arm.com, arnez@linux.vnet.ibm.com Subject: Re: [RFC 3/7] Add basic Linux kernel support Message-ID: <20170207105403.GA1630@E107787-LIN> References: <20170112113217.48852-1-prudo@linux.vnet.ibm.com> <20170112113217.48852-4-prudo@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170112113217.48852-4-prudo@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00147.txt.bz2 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. > (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. > + > + 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? -- Yao (齐尧) static char linux_banner[10]; static int _stext = 0; static int _etext = 0; typedef int pid_t; struct list_head { struct list_head *next, *prev; }; struct thread_struct {}; struct task_struct { struct list_head tasks; pid_t pid; pid_t tgid; struct list_head thread_group; char comm[20]; struct thread_struct thread; }; struct rq { struct task_struct *curr; }; #define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d)) #define BITS_PER_BYTE 8 #define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long)) #define DECLARE_BITMAP(name,bits) \ unsigned long name[BITS_TO_LONGS(bits)] #define NR_CPUS 10 struct cpumask { DECLARE_BITMAP(bits, NR_CPUS); }; struct cpumask __cpu_online_mask; struct task_struct init_task; struct rq runqueues; struct cpumask baz; unsigned long __per_cpu_offset[NR_CPUS]; struct mm_struct {}; struct mm_struct init_mm; int main (void) { return 0; }