Hi there!
as some of you may know, I've been working on an aarch64 native code
generator. Now I've hit a situation where my stage2 compiler somehow
corrupts my heap. Initially I thought this would likely be missing memory
barriers, however they are emitted. This doesn't mean it can't be, but at
> On 31 Aug 2020, at 5:54 pm, Moritz Angermann
> wrote:
>
> If anyone has some create ideas, I'd love to hear them. I've been wondering
> if just logging allocations (offset, range, type) would help figuring out
> what we
> expected to be there; and then maybe try to break on the allocation,
Dump the whole heap into file during GC traversal or taking the whole
allocated area. hmm, maybe this is the same as core dump.
On Mon, Aug 31, 2020 at 11:00 AM Ben Lippmeier wrote:
>
>
> > On 31 Aug 2020, at 5:54 pm, Moritz Angermann
> wrote:
> >
> > If anyone has some create ideas, I'd love t
I assume you're familiar with the following from
https://www.aosabook.org/en/ghc.html and that this facility is still there.
Just in case you are not:
So, the debug RTS has an optional mode that we call *sanity checking*.
Sanity checking enables all kinds of expensive assertions, and can make the
+Moritz
On Mon, Aug 31, 2020 at 11:17 AM George Colpitts
wrote:
> I assume you're familiar with the following from
> https://www.aosabook.org/en/ghc.html and that this facility is still
> there. Just in case you are not:
>
> So, the debug RTS has an optional mode that we call *sanity checking*.
Fuzzing:
1. generate simple random stg programs
2. compile and run with RTS sanity checking enabled
3. compare the program result between different backends
The fuzzer should cover all codegen cases and all code in RTS. Maybe this
could be checked by the existing tools.
On Mon, Aug 31,
Thanks everyone. I have indeed been trying to get somewhere with sanity
checking. That used to help quite a bit for the deadstripping stuff that
happened on iOS a long time ago, but that was also much more deterministic.
Maybe I'll try to see if running it through qemu will give me some more
determ
Ben Lippmeier writes:
>> On 31 Aug 2020, at 5:54 pm, Moritz Angermann
>> wrote:
>>
>> If anyone has some create ideas, I'd love to hear them. I've been wondering
>> if just logging allocations (offset, range, type) would help figuring out
>> what we
>> expected to be there; and then maybe tr
