Comment 7 for bug 1951470

------- Comment From <email address hidden> 2021-11-22 02:30 EDT-------
(In reply to comment #10)
> This does not look like an Ubuntu system. Linux kernel has wrong version:
> "Linux 193438490afd 5.8.15-301.fc33.s390x". Are you sure you are testing it
> on Ubuntu image?

I just mechanically copied the uname -a output there forgetting that I was working in a container. Hence the output is bogus, please ignore. But as mentioned already the issue is not kernel related anyway.

------- Comment From <email address hidden> 2021-11-22 02:37 EDT-------
(In reply to comment #13)
...
> @Andreas Is your proposed fix known to be save for other platform (LE), too?

Yes, the fix should be safe for LE platforms as well. Before that change it just accidentally worked on LE. But this would need to be tested of course.

> And can you point me to the upstream issue where this got fixed?

It looks like it got fixed as part of a commit which fixes numerous other CLoop issues:

commit 3fdde71c7d95d758a61fcbc4c58168616794c102
Author: Mark Lam <email address hidden>
Date: Mon Jan 14 21:34:47 2019 +0000

Fix all CLoop JSC test failures (including some LLInt bugs due to recent bytecode format change).
https://bugs.webkit.org/show_bug.cgi?id=193402
<rdar://problem/46012309>
Reviewed by Keith Miller.

There you can find a similar change as in my proposed patch. However, it is based on a commit which changed how these data are stored. So it might not be obvious to backport it. On the other hand it looks like it contains more fixes which we might want to have as well.

llintOpWithMetadata(op_get_from_scope, OpGetFromScope, macro (size, get, dispatch, metadata, return)
macro getProperty()
- loadis OpGetFromScope::Metadata::operand[t5], t3
+ loadp OpGetFromScope::Metadata::operand[t5], t3
loadPropertyAtVariableOffset(t3, t0, t1, t2)
valueProfile(OpGetFromScope, t5, t1, t2)
return(t1, t2)