From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89523 invoked by alias); 18 Apr 2018 00:40:35 -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 89408 invoked by uid 89); 18 Apr 2018 00:40:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=685, 2560 X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Apr 2018 00:40:32 +0000 Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 0926F10AFD3; Tue, 17 Apr 2018 20:40:31 -0400 (EDT) From: John Baldwin To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 31/40] target_ops/C++: Base FreeBSD target Date: Wed, 18 Apr 2018 00:40:00 -0000 Message-ID: <2336080.G2aX46TNlR@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <4c3b320e-ecbe-4e97-9ee4-91cacca60b8d@redhat.com> References: <20180414190953.24481-1-palves@redhat.com> <2651054.rGX2nUqyEc@ralph.baldwin.cx> <4c3b320e-ecbe-4e97-9ee4-91cacca60b8d@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00360.txt.bz2 On Tuesday, April 17, 2018 06:07:37 PM Pedro Alves wrote: > On 04/17/2018 05:05 PM, John Baldwin wrote: > > On Saturday, April 14, 2018 08:09:44 PM Pedro Alves wrote: > >> The > >> > >> $architecture x NetBSD/OpenBSD/FreeBSD > >> > >> support matrix complicates things a bit. There's common BSD target > >> code, and there's common architecture-specific code shared between the > >> different BSDs. Current, all that is stiched together to form a final > >> target, via the i386bsd_target, x86bsd_target, fbsd_nat_add_target > >> functions etc. > >> > >> Introduces a fbsd_nat_target base/prototype target. To be used in > >> following patches. > > > > I will do some tests of FreeBSD/amd64 first and let you know what I find. > > Thank you! I've pushed a target_ops-cxx branch to github.com/bsdjhb/gdb.git that has some small fixups (compile fixes). I've built the amd64, i386, arm, and aarch64 FreeBSD native targets so far. Simple testing of the the amd64 and i386 binaries seems to work, but I encountered a new test failure in the testsuite for FreeBSD/amd64 that is a bit odd. In particular, I get a core dump running 'info set' when it tries to display the current setting of whether ASLR is disabled. Looking at the core of gdb: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000000d3a7d4 in target_ops::supports_disable_randomization ( this=0x28d4c68 ) at ../../gdb/target-delegates.c:2732 2732 return this->beneath->supports_disable_randomization (); (top-gdb) where #0 0x0000000000d3a7d4 in target_ops::supports_disable_randomization ( this=0x28d4c68 ) at ../../gdb/target-delegates.c:2732 #1 0x0000000000d3a857 in find_default_supports_disable_randomization ( #2 0x0000000000d3a805 in dummy_target::supports_disable_randomization ( this=0x8040d6060) at ../../gdb/target-delegates.c:2738 #3 0x0000000000d2edd8 in target_supports_disable_randomization () at ../../gdb/target.c:2560 #4 0x0000000000b9adbc in show_disable_randomization (file=0x8047b1200, from_tty=1, c=0x80476db80, value=0x7fffffffd859 "on") at ../../gdb/infrun.c:181 #5 0x00000000007b1178 in do_show_command (arg=0x0, from_tty=1, c=0x80476db80) at ../../gdb/cli/cli-setshow.c:646 #6 0x00000000007b1434 in cmd_show_list (list=0x80476db80, from_tty=1, prefix=0x22a7ead "") at ../../gdb/cli/cli-setshow.c:685 ... The native target isn't currently in the target_stack so its 'beneath' is NULL: (top-gdb) p beneath During symbol reading, missing name for subprogram DIE at 14709647. $1 = (target_ops *) 0x0 (top-gdb) p target_stack $2 = (target_ops *) 0x8040d6060 (top-gdb) p *target_stack $3 = {_vptr$target_ops = 0x183aaf0 , beneath = 0x0, to_stratum = dummy_stratum} >From the stack trace we can see that it already bounced down to the dummy target which calls find_default_supports_disable_randomization. That finds the native "run" target and invokes its method without pushing it onto the stack. I think before if a native target didn't support ASLR at all it just didn't set the function pointer and no harm was done. Now the function pointer is effectively always set but to something that assumes 'beneath' is valid. I'm not quite sure how you want to fix this. The simple solution is to change the default method to return false if beneath is NULL, but I'm not quite sure that fits in with the design this branch is aiming for. -- John Baldwin