From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49267 invoked by alias); 24 Jun 2016 00:24:18 -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 49256 invoked by uid 89); 24 Jun 2016 00:24:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=Hx-languages-length:2121, monday, Monday X-HELO: bigwig.baldwin.cx Received: from bigwig.baldwin.cx (HELO bigwig.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 24 Jun 2016 00:24:12 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B3840B917; Thu, 23 Jun 2016 20:24:10 -0400 (EDT) From: John Baldwin To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Add support for catching system calls to native FreeBSD targets. Date: Fri, 24 Jun 2016 00:24:00 -0000 Message-ID: <7374404.qtI4NAOGSQ@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <53d24aec-5588-ea4f-7d6d-085aca553457@redhat.com> References: <20160614205751.11566-1-jhb@FreeBSD.org> <53d24aec-5588-ea4f-7d6d-085aca553457@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00392.txt.bz2 On Monday, June 20, 2016 11:56:40 PM Pedro Alves wrote: > Hi John, > > This looks good to me. Just some minor nits below. > > On 06/14/2016 09:57 PM, John Baldwin wrote: > > versions of FreeBSD include the identifier of the current > > system call when reporting a system call entry or exit event in the > > ptrace_lwpinfo structure obtained via PT_LWPINFO in fbsd_wait. As > > such, FreeBSD native targets do not use the gdbarch method to fetch > > the system call code. In addition, FreeBSD register sets fetched via > > ptrace do not include an equivalent of 'orig_rax' (on amd64 for > > example), so the system call code cannot be extracted from the > > available registers during a system call exit. However, GDB assumes > > that system call catch points are not supported if the gdbarch method > > is not present. As a workaround, FreeBSD ABIs install a dummy gdbarch > > method that throws an internal_error if it is ever invoked. > > > > We should probably get rid of this gdbarch method, by making linux-nat.c > (the only caller) call an arch-specific target_ops override instead of > a gdbarch method, like gdbserver's equivalent code does. > > To replace the break-catch-syscall.c error, I think that it'd be reasonable > to remove it altogether, and for Linux targets that don't implement > the gdbarch hook yet, instead just always intercept all syscalls, reporting > an syscall number. > > But what you did seems like a reasonable thing to do as long as do > have the gdbarch hook. So I'm not quite sure how to implement an arch-specific target_op. There are various linux_nat_set_* functions that accept a function pointer but then just set a global variable. The amd64 version might have to copy with different ABIs rather than depending on teh i386 gdbarch method, etc. One option that is a bit smaller in scale would be to move the error in break-catch-syscall.c into linux_child_set_syscall_catchpoint in linux-nat.c. It could return 1 to fail the request if the gdbarch method wasn't present. -- John Baldwin