James Cook writes:
> On Mon, Apr 22, 2024 at 11:21:36AM GMT, Greg Steuck wrote:
>> James, if you'd like to play with this on -current, please remove both
>> patch-libraries_text_simdutf_simdutf_h and
>> patch-libraries_text_cbits_measure_off_c
>>
>> This should make the offending check
On Mon, Apr 22, 2024 at 11:21:36AM GMT, Greg Steuck wrote:
> Stuart Henderson writes:
>
> > On 2024/04/22 10:30, Greg Steuck wrote:
> >> > If it would help, I could update my old AMD machine to -current
> >> > and check ghc works with the two patches removed, once I've finished
> >> > trying out
Stuart Henderson writes:
> On 2024/04/22 10:30, Greg Steuck wrote:
>> > If it would help, I could update my old AMD machine to -current
>> > and check ghc works with the two patches removed, once I've finished
>> > trying out the patch I just sent for 7.5.
>>
>> Thanks James for working through
On 2024/04/22 10:30, Greg Steuck wrote:
> > If it would help, I could update my old AMD machine to -current
> > and check ghc works with the two patches removed, once I've finished
> > trying out the patch I just sent for 7.5.
>
> Thanks James for working through this. Yes, we need the new
James Cook writes:
> The line you linked to comes after a check for cpuid_bit::osxsave,
> so I don't think it would get reached on machines that don't have
> xgetbv, i.e. it should be fine.
Cool, so maybe we need a patch which does this? I also just noticed
that you patched
On Sun, Apr 21, 2024 at 09:03:30PM +, James Cook wrote:
> On Sun, Apr 21, 2024 at 11:49:46AM -0700, Greg Steuck wrote:
> > Stuart Henderson writes:
> >
> > > This is in the avx512 checks in the text library again, I think it must
> > > be patch-libraries_text_cbits_measure_off_c (the simdutf
On Sun, Apr 21, 2024 at 11:49:46AM -0700, Greg Steuck wrote:
> Stuart Henderson writes:
>
> > This is in the avx512 checks in the text library again, I think it must
> > be patch-libraries_text_cbits_measure_off_c (the simdutf one doesn't
> > explicitly check for xgetbv but it does check for
On Sun, Apr 21, 2024 at 11:49:46AM -0700, Greg Steuck wrote:
> Stuart Henderson writes:
>
> > This is in the avx512 checks in the text library again, I think it must
> > be patch-libraries_text_cbits_measure_off_c (the simdutf one doesn't
> > explicitly check for xgetbv but it does check for
Stuart Henderson writes:
> This is in the avx512 checks in the text library again, I think it must
> be patch-libraries_text_cbits_measure_off_c (the simdutf one doesn't
> explicitly check for xgetbv but it does check for osxsave so I think
> wouldn't have executed the xgetbv opcode on this
On 2024/04/19 17:58, Greg Steuck wrote:
> James Cook writes:
>
> > Here are some results of debugging with lldb.
> >
> >
> > With cabal-bundler and pandoc, it seems to be the xgetbv instruction
> > itself:
> >
> >
> > $ lldb /usr/local/bin/cabal-bundler
> > (lldb) target create
James Cook writes:
> Here are some results of debugging with lldb.
>
>
> With cabal-bundler and pandoc, it seems to be the xgetbv instruction
> itself:
>
>
> $ lldb /usr/local/bin/cabal-bundler
> (lldb) target create "/usr/local/bin/cabal-bundler"
> Current executable set to
On Fri, Apr 19, 2024 at 12:04:54AM +, James Cook wrote:
> On Sun, Feb 18, 2024 at 08:35:26AM -0800, Evan Silberman wrote:
> > Stuart Henderson wrote:
> > > On 2024/02/18 09:02, Stuart Henderson wrote:
> > > > On 2024/02/17 22:08, Greg Steuck wrote:
> > > > > Oh wow, this is becoming eerily
On Sun, Feb 18, 2024 at 08:35:26AM -0800, Evan Silberman wrote:
> Stuart Henderson wrote:
> > On 2024/02/18 09:02, Stuart Henderson wrote:
> > > On 2024/02/17 22:08, Greg Steuck wrote:
> > > > Oh wow, this is becoming eerily similar to the failures aja@ is
> > > > getting. Do
> > > > dig more
oops, thanks - fix committed.
On 2024/02/23 11:35, Evan Silberman wrote:
> Stuart Henderson wrote:
> > Index: patches/patch-libraries_text_cbits_measure_off_c
> > ===
> > RCS file: patches/patch-libraries_text_cbits_measure_off_c
>
Stuart Henderson wrote:
> Index: patches/patch-libraries_text_cbits_measure_off_c
> ===
> RCS file: patches/patch-libraries_text_cbits_measure_off_c
> diff -N patches/patch-libraries_text_cbits_measure_off_c
> --- /dev/null 1 Jan
> Evan, if you have abundant time, could you try to run `make test` with
> and without the patches? `make clean` in the middle is probably the
> easiest way to ensure the patches get applied as expected.
Did `make test` in lang/ghc with and without the patches and got the
same three failed tests
Stuart Henderson writes:
> On 2024/02/18 16:56, Evan Silberman wrote:
>> Something like this? I'm out of my depth and heavily pattern-matching
>> against the fix to simdutf and other references. Genuinely no idea if
>> I'm using inline asm correctly, etc. Works on my machine, however.
>
> That
Stuart Henderson wrote:
> On 2024/02/18 16:56, Evan Silberman wrote:
> > Something like this? I'm out of my depth and heavily pattern-matching
> > against the fix to simdutf and other references. Genuinely no idea if
> > I'm using inline asm correctly, etc. Works on my machine, however.
>
> That
On 2024/02/18 16:56, Evan Silberman wrote:
> Something like this? I'm out of my depth and heavily pattern-matching
> against the fix to simdutf and other references. Genuinely no idea if
> I'm using inline asm correctly, etc. Works on my machine, however.
That seems right to me. I don't have an
Stuart Henderson wrote:
> On 2024/02/18 13:58, Evan Silberman wrote:
> > Stuart Henderson wrote:
> > > This is probably worth a try. I've asked if upstream can update it
> >
> > Hi Stuart,
> >
> > Unclear if necessary, but not sufficient. Turns out there's one more
> > unconditional AVX512
On 2024/02/18 13:58, Evan Silberman wrote:
> Stuart Henderson wrote:
> > This is probably worth a try. I've asked if upstream can update it
>
> Hi Stuart,
>
> Unclear if necessary, but not sufficient. Turns out there's one more
> unconditional AVX512 check in text's own C code,
Stuart Henderson wrote:
> This is probably worth a try. I've asked if upstream can update it
Hi Stuart,
Unclear if necessary, but not sufficient. Turns out there's one more
unconditional AVX512 check in text's own C code, cbits/measure_off.c:
#if !((defined(__apple_build_version__) &&
This is probably worth a try. I've asked if upstream can update it:
https://github.com/haskell/text/issues/563
Index: Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.220
diff -u -p -r1.220 Makefile
---
Stuart Henderson wrote:
> On 2024/02/18 09:02, Stuart Henderson wrote:
> > On 2024/02/17 22:08, Greg Steuck wrote:
> > > Oh wow, this is becoming eerily similar to the failures aja@ is getting.
> > > Do
> > > dig more into this!
> >
> > Antoine, can you send a dmesg from one of the exopi VMs,
On Sun, Feb 18, 2024 at 09:02:16AM +, Stuart Henderson wrote:
> On 2024/02/17 22:08, Greg Steuck wrote:
> > Oh wow, this is becoming eerily similar to the failures aja@ is getting. Do
> > dig more into this!
>
> Antoine, can you send a dmesg from one of the exopi VMs, please?
Sure.
OpenBSD
On 2024/02/18 09:02, Stuart Henderson wrote:
> On 2024/02/17 22:08, Greg Steuck wrote:
> > Oh wow, this is becoming eerily similar to the failures aja@ is getting. Do
> > dig more into this!
>
> Antoine, can you send a dmesg from one of the exopi VMs, please?
- specifically I am wondering if it
On 2024/02/17 22:08, Greg Steuck wrote:
> Oh wow, this is becoming eerily similar to the failures aja@ is getting. Do
> dig more into this!
Antoine, can you send a dmesg from one of the exopi VMs, please?
> On Sat, Feb 17, 2024, 21:34 Evan Silberman wrote:
>
> > Evan Silberman wrote:
> > >
Greg Steuck wrote:
> Oh wow, this is becoming eerily similar to the failures aja@ is getting. Do
> dig more into this!
I did, and now it's bedtime. Attached tarball contains a reasonably
minimized reproduction of the crash on my machine with a short readme.
It builds with GHC 9.2.7 and fails
Oh wow, this is becoming eerily similar to the failures aja@ is getting. Do
dig more into this!
On Sat, Feb 17, 2024, 21:34 Evan Silberman wrote:
> Evan Silberman wrote:
> > Thanks to the amd64 snapshot package archives I was able to bisect to a
> > working pandoc package on my machine. OK on
Evan Silberman wrote:
> Thanks to the amd64 snapshot package archives I was able to bisect to a
> working pandoc package on my machine. OK on 2024-01-16, NG on
> 2024-01-17.
I guess what this means is my problem is traceable to the ghc 9.6.4
bump. I have determined I can elicit a SIGILL
Stuart Henderson wrote:
> On 2024/02/16 13:41, Evan Silberman wrote:
> > Greg back to your question about when this worked, I wish I could tell
> > you something meaningful. I think I had a pre-7.4 snap on this laptop
> > vintage September, whenever I last updated the Pandoc port, and then I
> >
On 2024/02/16 20:45, Stuart Henderson wrote:
> It runs ok on ryzen. 11th gen intel + SIGILL - looks like an IBT issue.
I've tried cargo-bundler and pandoc on my IBT machine now, they seem to
run OK there too.
On 2024/02/16 13:41, Evan Silberman wrote:
> Greg back to your question about when this
Greg Steuck wrote:
> Same here. That's intentional as the underlying problem got fixed
> upstream a while ago. We removed WXNEEDED then:
>
> Date: Fri Jun 3 02:48:07 2022 +
>
> Remove USE_WXNEEDED from lang/ghc as it's no longer needed
>
> Thanks
> Greg
OK. I'm out of my depth a bit
Evan Silberman writes:
> Can you repeat for OPENBSD_WXNEED? On my syspatched 7.4-release VPS, pandoc
> from packages has wxneeded:
>
> ~$ uname -rsv
> OpenBSD 7.4 GENERIC#1336
> ~$ readelf -Wl $(which pandoc) | grep OPENBSD_WXNEED
> OPENBSD_WXNEED 0x00 0x 0x
Greg Steuck wrote:
> Evan Silberman writes:
>
> > I should've figured out how to use readelf before I bothered with this,
> > the NOBTCFI elf segment is already present in the ports in question.
> > Above diff is irrelevant. It does seem significant that the ports that
> > work fine (ghc and
Evan Silberman writes:
> I should've figured out how to use readelf before I bothered with this,
> the NOBTCFI elf segment is already present in the ports in question.
> Above diff is irrelevant. It does seem significant that the ports that
> work fine (ghc and cabal-install) are, naturally, the
Evan Silberman wrote:
> I'm trying with this:
>
> diff /usr/ports
> commit - 5fdc9dbcebbd57477b047430dfc2cc4e987537ef
> path + /usr/ports
> blob - a51e834910b7ee582f3be8d92a4e137a0cb46ad1
> file + devel/cabal/cabal.port.mk
> --- devel/cabal/cabal.port.mk
> +++ devel/cabal/cabal.port.mk
> @@
Greg Steuck wrote:
> Stuart Henderson writes:
>
> > It runs ok on ryzen. 11th gen intel + SIGILL - looks like an IBT
> > issue.
>
> Isn't -Wl,-z,nobtcfi supposed to have disabled this?
>
> https://codeberg.org/OpenBSD/ports/src/branch/master/lang/ghc/Makefile#L123
>
> Thanks
> Greg
I'm
Stuart Henderson writes:
> It runs ok on ryzen. 11th gen intel + SIGILL - looks like an IBT
> issue.
Isn't -Wl,-z,nobtcfi supposed to have disabled this?
https://codeberg.org/OpenBSD/ports/src/branch/master/lang/ghc/Makefile#L123
Thanks
Greg
Evan Silberman writes:
> Hi ports@ and Greg,
>
> On -current (yesterday's amd64 snap, this morning's amd64 packages),
> ports built with ghc are all getting SIGILL early in execution on my
> laptop.
Interesting, when was the last time it worked for you?
> I'm not totally positive what is
It runs ok on ryzen. 11th gen intel + SIGILL - looks like an IBT issue.
On 2024/02/16 11:48, Evan Silberman wrote:
> Hi ports@ and Greg,
>
> On -current (yesterday's amd64 snap, this morning's amd64 packages),
> ports built with ghc are all getting SIGILL early in execution on my
> laptop. I'm
Hi ports@ and Greg,
On -current (yesterday's amd64 snap, this morning's amd64 packages),
ports built with ghc are all getting SIGILL early in execution on my
laptop. I'm not totally positive what is helpful to provide here but I
can provide it on request. I thought I was maybe caught in some base
42 matches
Mail list logo
