Hi again Klemens, On Tue, May 26, 2020 at 5:42 PM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > With regards to your crash, though, that's a bit more puzzling, and > > I'd be interested to learn more details. Because these structs are > > already naturally aligned, the __packed attribute, even with the odd > > nesting Matt had prior, should have produced all entirely aligned > > accesses. That makes me think your kaboom was coming from someplace > > else. One possibility is that you were running the git tree on the two > > days that I was playing with uint128_t, only to find out that some of > > openbsd's patches to clang miscalculate stack sizes when they're in > > use, so that work was shelved for another day and the commits removed; > > perhaps you were just unlucky? Or you hit some other bug that's > > lurking. Either way, output from ddb's `bt` would at least be useful. > > Do you know off hand if we're able to assume any type of alignment > with mbuf->m_data? mtod just casts without any address fixup, which > means if mbuf->m_data isn't aligned by some other mechanism, we're in > trouble. But I would assume there _is_ some alignment imposed, since > the rest of the stack appears to parse tcp headers and such directly > without byte-by-byte copies being made.
After a day of TCG-run compilation, I've got a working sparc64 setup and can confirm the issue. Working on a fix. Jason
