From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65281 invoked by alias); 7 Feb 2017 17:39:56 -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 65224 invoked by uid 89); 7 Feb 2017 17:39:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.3 required=5.0 tests=BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=FALSE, qiyaoltc@gmail.com, qiyaoltcgmailcom, U*qiyaoltc X-HELO: mail-wm0-f67.google.com Received: from mail-wm0-f67.google.com (HELO mail-wm0-f67.google.com) (74.125.82.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Feb 2017 17:39:53 +0000 Received: by mail-wm0-f67.google.com with SMTP id r18so29717731wmd.3 for ; Tue, 07 Feb 2017 09:39:53 -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=4A7C/AovQ2uScCc1ILsDgJNaLmqpjFFyTNXC5Xyx2Bo=; b=jjRbKPBcFsgO0DHpNxgWwqKv/DuSbtsL4eytMol4nAV5yoVifQvOgU2V7YIf0buaVm zEYCwiBOLQahzHjfqUt/MvtntEpv+J1gzlQb/X5JD3p55SUM4tDAgiZ7/l2LNOyXDied IbQlnVhLo+8mkVe0eRJtNo9Pr9NmYKLqAsZcj0wwevc7t3YkVD9bPfw+mpdLF24LfT2n bM2xhzg7xMHVW2r8hdJD/OPhSFVntezUm8cCYhcVn/InoNxYhHXmr+9zsBVARwWTNhA3 j1YMHuqqKPDR3XiI3EFiUSvOufPCO7GLwZUI1kPMJWmhrczt38ptpmQHklh58ZLqvSYU jhcA== X-Gm-Message-State: AMke39l3aDm5+h+VbjVPttnIw/Cjun5D2nipVlel5bKsi675j6dhzbhhea0373eEaiHnvQ== X-Received: by 10.28.66.221 with SMTP id k90mr15387183wmi.90.1486489191180; Tue, 07 Feb 2017 09:39:51 -0800 (PST) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id g71sm19941972wmc.9.2017.02.07.09.39.50 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 07 Feb 2017 09:39:50 -0800 (PST) Date: Tue, 07 Feb 2017 17:39:00 -0000 From: Yao Qi To: Philipp Rudo Cc: gdb-patches@sourceware.org Subject: Re: [RFC 3/7] Add basic Linux kernel support Message-ID: <20170207173944.GA32023@E107787-LIN> References: <20170112113217.48852-1-prudo@linux.vnet.ibm.com> <20170112113217.48852-4-prudo@linux.vnet.ibm.com> <20170207105403.GA1630@E107787-LIN> <20170207160444.34c46791@ThinkPad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170207160444.34c46791@ThinkPad> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00166.txt.bz2 On 17-02-07 16:04:44, Philipp Rudo wrote: > 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? Yes, lk-low.o needs to be added to ALL_TARGET_OBS, but that is not enough. I get the following compile error on x86_64-linux, lk-lists.o: In function `lk_find': /home/yao/SourceCode/gnu/gdb/git/gdb/lk-low.h:125: undefined reference to `linux_kernel_ops' /home/yao/SourceCode/gnu/gdb/git/gdb/lk-low.h:125: undefined reference to `linux_kernel_ops' lk-lists.o: In function `lk_list_head_next(unsigned long, char const*, char const*)': /home/yao/SourceCode/gnu/gdb/git/gdb/lk-lists.c:35: undefined reference to `lk_read_addr(unsigned long)' /home/yao/SourceCode/gnu/gdb/git/gdb/lk-lists.c:36: undefined reference to `lk_read_addr(unsigned long)' because lk-low.o isn't linked into the executable. I think both lk-low.o and lk-lists.o should be added for each $ARCH-linux target in configure.tgt. > > > > (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. Do you have an example that lookup_symbol doesn't work but parse_exp works? > > > > (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. > How is it related to kernel modules? I don't want to test kernel module handling in this test case. -- Yao (齐尧)