Date: Sat, 26 Oct 2019 10:42:20 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-arm@freebsd.org Subject: Re: ucontext Message-ID: <CANCZdfozeVLUf%2B6kQJHLMKRdXQQNhAz6OsYHiPL1icZZLCq6ng@mail.gmail.com> In-Reply-To: <7fddb657a8a1724c5ae75442e21d4a7f448a0c99.camel@freebsd.org> 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> <d1bbda1f2a796d0a11b0feadbb9caf6004a2b40c.camel@freebsd.org> <20191025145918.GF73312@kib.kiev.ua> <7fddb657a8a1724c5ae75442e21d4a7f448a0c99.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 25, 2019, 9:08 AM Ian Lepore <ian@freebsd.org> 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 <kostikbel@gmail.com> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfozeVLUf%2B6kQJHLMKRdXQQNhAz6OsYHiPL1icZZLCq6ng>