On Thu, Aug 23, 2018 at 4:01 PM Christopher Friedt <chrisfri...@gmail.com> wrote: > On Thu., Aug. 23, 2018, 3:50 p.m. Christopher Friedt, <chrisfri...@gmail.com> > wrote: >> On Thu., Aug. 23, 2018, 2:20 p.m. Peter Maydell, <peter.mayd...@linaro.org> >> wrote: >>> On 23 August 2018 at 17:36, Christopher Friedt <chrisfri...@gmail.com> >>> wrote: >>> >>> happen to have a copy on your lake, but the short answer >>> is that bit 1 must be set, exactly because this is what >>> defines whether EPSR.T is set on exception entry. >> >> Doh! You're right, although I checked for that in my rom vector table. As it >> turns out, I relocated my vtable to ram and *then* zeroed bss, which would >> obviously clear the T bit. > > Ok, not right. The vtable entries all do have the T bit set and I was zeroing > the bss first after all. All isr entries are either 0x2e9 (no-op isr), 0x2ff > (no-op fault handler), or 0 (for reserved), so the T bit is set everywhere it > needs to be. > > It would seem there is an underlying issue with the T bit not getting set > upon exception invocation, and my previous patch was more of a bandaid > solution. It would be fairly straightforward to come up with a short assembly > fragment that verifiably demonstrates the problem in this case.
OK - assembly fragment worked fine. So yeah, it has to be something wrong with the way that the C library I'm linking to (musl) is doing syscalls.
foo.S
Description: Binary data
