From owner-freebsd-arm@freebsd.org Fri Oct 25 14:50:05 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 363CB1729CD for ; Fri, 25 Oct 2019 14:50:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4706Tm6CFJz4bTh; Fri, 25 Oct 2019 14:50:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x9PEnvQa036524 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 25 Oct 2019 17:50:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x9PEnvQa036524 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x9PEnvLr036523; Fri, 25 Oct 2019 17:49:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Oct 2019 17:49:57 +0300 From: Konstantin Belousov To: Ian Lepore Cc: Nick Kostirya , freebsd-arm@freebsd.org Subject: Re: ucontext Message-ID: <20191025144957.GE73312@kib.kiev.ua> References: <20191024141133.04fb0693@i11.co> <20191024145436.GX73312@kib.kiev.ua> <20191025104421.012c1e5e@i11.co> <20191025083803.GD73312@kib.kiev.ua> <78c9868cf23643dfa2f88694542e86251bde13e7.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78c9868cf23643dfa2f88694542e86251bde13e7.camel@freebsd.org> User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 4706Tm6CFJz4bTh X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.991,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 14:50:05 -0000 On Fri, Oct 25, 2019 at 08:26:19AM -0600, Ian Lepore wrote: > On Fri, 2019-10-25 at 11:38 +0300, Konstantin Belousov wrote: > > On Fri, Oct 25, 2019 at 10:44:21AM +0300, Nick Kostirya wrote: > > > On Thu, 24 Oct 2019 17:54:36 +0300 > > > Konstantin Belousov wrote: > > > > > > > > > > > I believe you want > > > > uc_context.__gregs[_REG_PC] > > > > on arm (32bit) and > > > > uc_context.mc_gpregs.gp_elr > > > > on arm64 for aarch64. > > > > > > > > Sometimes the thumb bit (lowest bit in PC) leaks there, then you should > > > > mask it. > > > > > > Thanks! > > > > > > Although I did not understand your last phrase. > > > There is leak of what? > > > > Leak of the thumb bit. ARM ARM specifies that in non-thumb mode, pc must > > be word-aligned, in thumb it is half-word aligned. A way to enter thumb > > mode is to execute BX or BLX instruction with the lowest bit of the target > > PC set to 1. > > > > Sometimes you might get pc with the bit 0 set, which should > > be masked out then. This is a bigger issue for unwinders than for simple > > profilers. > > > > > Where can I read about it? > > > > ARM ARM (ARM architecture reference manual), available from arm.com. > > Or Google for it. > > > > The kernel has some support for running thumb binaries, but I've never > heard of anybody actually doing so on freebsd. Nobody has ever > reported a bug related to running a thumb binary, and it would be > astounding to me if we accidentally got everything in the kernel thumb > support right on the first try without ever testing it. I am curious as well, isn't thumb completely transparent to the kernel ? I.e. my impression was that some code might be compiled into thumb, and then a thunk which does BX to the location, is used to switch to thumb mode. There is no new ELF machine type involved, or different exception entry mode, so it should just work ? And this is why I remember about this bit 0 issue, it caused some problems to libunwind on arm.