From owner-freebsd-arm@freebsd.org Fri Oct 25 15:08:04 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 DC594173374 for ; Fri, 25 Oct 2019 15:08:04 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (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 4706tX4hPbz4cj1 for ; Fri, 25 Oct 2019 15:08:04 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1572016083; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=NJouv/df42OfTmtThXXq6AMKVY2R6xIqZzft+Oc7wScn6QHO5nByHhoncCbP6AOXnPZnoh6oyypoM gMrOb1Ezb8/4Yprr89Gxmw0NsQtMCfUMYjZTtWralaZifq5EPuilEk25bFvsyiad5KLRL00HC0gYqZ gKbWZiin+v/7JcZej30hgFil7tBQ+NwHAkFCjtsuMrsV4Ovvw6fZGiX0SwAWMXz7ifdDUmZ1HCjtLk dyixdRO8KUPHLcfkjiEZRO77/6z3PthcaR1Ho6WWAwQXU0Yg7HeBxzNgHi2Y67aZRoBi3eZaRDbyCZ BmdBGh3kbkwsJF/fKiWjAdZsQcgQyYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=yvKRhoZ57voapt9kYNo0VbyRYRm0MHYEySyBS0h7z/M=; b=Th6Y9VHYQzQgH/R3IiQsXAgwPI0Tc6Tpk25uiFqihglwRc4Ee4A2jKhUHE18wJmUf1m1v1us8n78B rB3/rYwyOaHy7H8c2cvO003SwC71N9dAnfnCZXskmpgzXpxUTLINzdD793cuMJ2l0exGjDga4l2rRi stQCPFnqmGtY4VNdLmbHijaIWou3CUrF544MHj9fuD7Sy/QMpaGvfSqzEVEwm4oO1N1qJNxgH2YUoe pMJITsOH4ksEVSgxMnvJyV0XxVoxkEiqlxSGPKWseMJTzkj7ATAtUtHh5KH1ewbdc/iRqThavReIhd dmqx9xP/vbVd4VuYrx6MREb1JMzsnVA== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=yvKRhoZ57voapt9kYNo0VbyRYRm0MHYEySyBS0h7z/M=; b=e+8ewmL+Hdm1+Jpv6UEj9o/SBHs8FT88a3dJubiJzqVpR9w+RNNIML6PwoHaSnR46DCmt6vQm7l5+ Nhl1s3nxaXc8Iz6fiXR/ttsPuquNkjKsv8I1j3CA7AF0AqLdFv+LfmUo5UhQdvvTIXm9H5KDH1fGW7 uav2l8yxdXkU7pY0geAQJUXYts6O9e52RvtikgV9N3G0/3aKSvMkc5fKTzgUGJl4E0aNV1Y1dEJCWk 9dd6qYsHkLEOE556W+jMZrU+SmYDSvN0boMyydYAZ043qXXMHUfj3NiLTsyFZHAcUscrwrwXMpbg24 y3Ie+dTBnZJbIPFjOtKr7RoRxL7vGWg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 3c678a32-f739-11e9-829e-79a40d15cccd X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 3c678a32-f739-11e9-829e-79a40d15cccd; Fri, 25 Oct 2019 15:08:01 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x9PF805I049554; Fri, 25 Oct 2019 09:08:00 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <7fddb657a8a1724c5ae75442e21d4a7f448a0c99.camel@freebsd.org> Subject: Re: ucontext From: Ian Lepore To: Konstantin Belousov Cc: freebsd-arm@freebsd.org Date: Fri, 25 Oct 2019 09:08:00 -0600 In-Reply-To: <20191025145918.GF73312@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> <20191025144957.GE73312@kib.kiev.ua> <20191025145918.GF73312@kib.kiev.ua> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4706tX4hPbz4cj1 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.84 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.84)[-0.837,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] 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 15:08:04 -0000 On Fri, 2019-10-25 at 17:59 +0300, Konstantin Belousov wrote: > On Fri, Oct 25, 2019 at 08:51:41AM -0600, Ian Lepore wrote: > > On Fri, 2019-10-25 at 17:49 +0300, Konstantin Belousov wrote: > > > 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. > > > > > > > I think in the kernel it would appear in places like page fault > > handlers needing to mask off the lower bit. > > Normally thumb state is stored in PSTATE.T and not in R15. Also, > even > if it would be R15.0, why would kernel need it masked ? > I assume that a page fault on an instruction fetch would have the low bit set in the FAR in thumb mode, and the fault handler would have to cope with that. Maybe not, it wasn't me that wrote that part of the arm kernel support. But it seems like you yourself just gave an example of why the kernel would be involved in thumb-or-not stuff... to resume execution after a fault you'd have to adjust the PC to the faulting instruction, and how much to adjust it would be based on whether the faulting code was in thumb mode or not, so the fault handler would have to examine the status register for the mode. I imagine there's a handful of places where that sort of thing comes up in the kernel, and if nobody has ever tested it, I imagine there's a bug or two lurking there. -- Ian