From owner-freebsd-arm@freebsd.org Sat Oct 26 16:42:34 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 EB87C1792CF for ; Sat, 26 Oct 2019 16:42:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 470mx55nGhz4N3C for ; Sat, 26 Oct 2019 16:42:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x841.google.com with SMTP id m15so8212786qtq.2 for ; Sat, 26 Oct 2019 09:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V4hxd/sZQhExkTCdUxHM95UjWtC7mV0fufQXx6K8JTQ=; b=eNx23NcCsNW+14o+fDb5NPYKUCD3J1Yd+aSG4WhOtonRjL0OMN0V5ByHE29uoo3AL3 4q5jngQOgXc3K3NB5cMjDh3x308ZKqnmiBF1wNx4140xvbKPW3XiaK8IWKn5QEyzrmkh LpXoN9xBeF1UBf4+CmuDQBYEKXnEfcdpkaH0GQDjqJllBRIhDRf6q/Oyk/GaSDS1/08l ae0pJDYXRBlQ7pvvCuz7M2gWbMPS3CwnYNGEUXcu4i+dSyYXT5EdLcrMuBY/nGp1Jsyf L/kWxOHzvtT3+9YINlOmzOz4jyjTGjZFDVjr14hzBmtUa1oNHrD0mYFFVyXwprVq7l/E I03w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V4hxd/sZQhExkTCdUxHM95UjWtC7mV0fufQXx6K8JTQ=; b=cHgE1BH6esQLfSdeebVNLwkGt4m/oaeF5PI+/9d20r0ZEwPzTln+InTAjHwTGv69NT r+8APWeVmtmOIgzlPlJEpP8Bq/TB9GczDPHw+FnSeHa7914iXd4zM+mXcSrFVB8pV8I7 gttTESTBa3AOh5TzGSZZB9kobObM3VRvWQ4DehcXztdfpR2Xow4BOUO4onqibwneEbjR H9aa3wYRQNvHUGnPSEc9fag5ZLYD7ScFbHsAg17EaLFLNNGwwwocKbGmfV19FhN5i10T 8+g7QSPmTn0f1ZOzK04vsVUnIGJerK5N4J0Qs0A0eo0veNwtBxhsV5lUSuSxDTDXe8Hf 4/Hg== X-Gm-Message-State: APjAAAVzxLaQl2HhR+W0XEIcCm08icraf5h+UlQzcGn8/cH2pXI84iIS fuMnHpe0nhconoHG+KMl6EQfcBdIn/rKvYs65i9o6Q== X-Google-Smtp-Source: APXvYqymwczMXaJeKyjhkFntjWDb0/KIU0LzKJi6t3Vm+L1JvvYBFiG4P/9lOPUd8or0sZdO26Pz3DcS/lcuttzcb2k= X-Received: by 2002:ad4:442d:: with SMTP id e13mr1290016qvt.202.1572108152332; Sat, 26 Oct 2019 09:42:32 -0700 (PDT) MIME-Version: 1.0 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> <7fddb657a8a1724c5ae75442e21d4a7f448a0c99.camel@freebsd.org> In-Reply-To: <7fddb657a8a1724c5ae75442e21d4a7f448a0c99.camel@freebsd.org> From: Warner Losh Date: Sat, 26 Oct 2019 10:42:20 -0600 Message-ID: Subject: Re: ucontext To: Ian Lepore Cc: Konstantin Belousov , freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 470mx55nGhz4N3C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=eNx23NcC; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::841) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.41 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[1.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.41)[ip: (2.48), ipnet: 2607:f8b0::/32(-2.40), asn: 15169(-2.05), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Sat, 26 Oct 2019 16:42:35 -0000 On Fri, Oct 25, 2019, 9:08 AM Ian Lepore wrote: > 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. > For mips, there are places we decode instructions. If we need to do that on arm, then I'm surprised with 0 bug reports from that angle as well... Warner -- Ian > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >