add ollama test script

4 files changed, 277 insertions, 17 deletions

diff --git a/ollama/llm.py b/ollama/llm.py
new file mode 100755
index 00000000..acf76421
--- /dev/null
+++ b/ollama/llm.py
@@ -0,0 +1,31 @@
+from ollama import chat, ChatResponse
+from re import sub
+from os import listdir, path
+
+model : str = "deepseek-r1:70b"
+directory : str = "../mailinglist/output_mailinglist"
+
+with open("preambel", "r") as file:
+    preambel = file.read()
+
+for name in listdir(directory):
+    with open(path.join(directory, name)) as file:
+        content = preambel + "\n" + file.read()
+
+    with open("test", "r") as file:
+        content = file.read()
+
+    response : ChatResponse = chat(
+        model=model, messages=[
+            {
+                'role': 'user',
+                'content': content,
+            }
+        ]
+    )
+
+    no_think_response : str = sub(r'<think>(.|\n)*</think>\n\n', '', response.message.content)
+
+    print(no_think_response)
+    print("\n")
+    exit()
diff --git a/ollama/mail b/ollama/mail
new file mode 100644
index 00000000..6a329756
--- /dev/null
+++ b/ollama/mail
@@ -0,0 +1,184 @@
+We have this gitlab issue for the project qemu. This is a semantic mistranslation bug:
+----
+x86 BLSMSK semantic bug
+Host environment
+
+Operating system: Windows 10 20H2
+OS/kernel version: WSL2 Ubuntu 20.04.4 LTS (GNU/Linux 5.10.102.1-microsoft-standard-WSL2 x86_64)
+Architecture: x86
+QEMU flavor: qemu-x86_64
+QEMU version: 7.1.90 (v7.2.0-rc0)
+QEMU command line: qemu-x86_64 -cpu max a.out
+
+Emulated/Virtualized environment
+
+Operating system: None
+OS/kernel version: None
+Architecture: x86
+
+Description of problem
+The result of instruction BLSMSK is different with from the CPU. The value of CF is different.
+
+Steps to reproduce
+
+Compile this code
+
+void main() {
+    asm("mov rax, 0x65b2e276ad27c67");
+    asm("mov rbx, 0x62f34955226b2b5d");
+    asm("blsmsk eax, ebx");
+}
+
+Execute and compare the result with the CPU.
+CPU CF = 0
+QEMU CF = 1
+----
+
+This issue results in the following toml file:
+----
+id = 1371
+title = "x86 BLSMSK semantic bug"
+state = "closed"
+created_at = "2022-12-16T06:43:29.794Z"
+closed_at = "2023-03-01T01:08:38.844Z"
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1371"
+host-os = "Windows 10 20H2"
+host-arch = "x86"
+qemu-version = "7.1.90 (v7.2.0-rc0)"
+guest-os = "None"
+guest-arch = "x86"
+description = """The result of instruction BLSMSK is different with from the CPU. The value of CF is different."""
+reproducer = """
+void main() {
+    asm("mov rax, 0x65b2e276ad27c67");
+    asm("mov rbx, 0x62f34955226b2b5d");
+    asm("blsmsk eax, ebx");
+}
+"""
+additional = "n/a"
+semantic_bug = "yes"
+----
+
+For the following mails you have to give me a toml file with the variables 'title, state, created_at, closed_at, host-os, host-arch, qemu-version, guest-os, guest-arch, description, reproducer, semantic_bug'. 'semantic_bug' can either be "yes" or "no". If the information for one variable is not provided, set it to "n/a". Output only the toml without reasoning:
+----
+[Bug] x86 EFLAGS refresh is not happening correctly
+
+Hello,
+I'm posting this here instead of opening an issue as it is not clear to me if this is a bug or not.
+The issue is located in function "cpu_compute_eflags" in target/i386/cpu.h
+(
+https://gitlab.com/qemu-project/qemu/-/blob/master/target/i386/cpu.h#L2071
+)
+This function is exectued in an out of cpu loop context.
+It is used to synchronize TCG internal eflags registers (CC_OP, CC_SRC,  etc...) with the CPU eflags field upon loop exit.
+It does:
+    eflags
+|=
+cpu_cc_compute_all
+(
+env
+,
+CC_OP
+)
+|
+(
+env
+->
+df
+&
+DF_MASK
+);
+Shouldn't it be:
+    Â
+eflags
+=
+cpu_cc_compute_all
+(
+env
+,
+CC_OP
+)
+|
+(
+env
+->
+df
+&
+DF_MASK
+);
+as eflags is entirely reevaluated by "cpu_cc_compute_all" ?
+Thanks,
+Kind regards,
+Stevie
+
+On 05/08/21 11:51, Stevie Lavern wrote:
+Shouldn't it be:
+eflags = cpu_cc_compute_all(env, CC_OP) | (env->df & DF_MASK);
+as eflags is entirely reevaluated by "cpu_cc_compute_all" ?
+No, both are wrong.  env->eflags contains flags other than the
+arithmetic flags (OF/SF/ZF/AF/PF/CF) and those have to be preserved.
+The right code is in helper_read_eflags.  You can move it into
+cpu_compute_eflags, and make helper_read_eflags use it.
+Paolo
+
+On 05/08/21 13:24, Paolo Bonzini wrote:
+On 05/08/21 11:51, Stevie Lavern wrote:
+Shouldn't it be:
+eflags = cpu_cc_compute_all(env, CC_OP) | (env->df & DF_MASK);
+as eflags is entirely reevaluated by "cpu_cc_compute_all" ?
+No, both are wrong.  env->eflags contains flags other than the
+arithmetic flags (OF/SF/ZF/AF/PF/CF) and those have to be preserved.
+The right code is in helper_read_eflags.  You can move it into
+cpu_compute_eflags, and make helper_read_eflags use it.
+Ah, actually the two are really the same, the TF/VM bits do not apply to
+cpu_compute_eflags so it's correct.
+What seems wrong is migration of the EFLAGS register.  There should be
+code in cpu_pre_save and cpu_post_load to special-case it and setup
+CC_DST/CC_OP as done in cpu_load_eflags.
+Also, cpu_load_eflags should assert that update_mask does not include
+any of the arithmetic flags.
+Paolo
+
+Thank for your reply!
+It's still a bit cryptic for me.
+I think i need to precise that I'm using a x86_64 custom user-mode,base on linux user-mode, that i'm developing (unfortunately i cannot share the code) with modifications in the translation loop (I've added cpu loop exits on specific instructions which are not control flow instructions).
+If my understanding is correct, in the user-mode case 'cpu_compute_eflags' is called directly by 'x86_cpu_exec_exit' with the intention of synchronizing the CPU env->eflags field with its real value (represented by the CC_* fields).
+I'm not sure how 'cpu_pre_save' and 'cpu_post_load' are involved in this case.
+Â
+As you said in your first email, 'helper_read_eflags' seems to be the correct way to go.
+Here is some detail about my current experimentation/understanding of this "issue":
+With the current implementationÂ
+        Â
+eflags |= cpu_cc_compute_all(env, CC_OP) | (env->df & DF_MASK);
+if I exit the loop with a CC_OP different from CC_OP_EFLAGS, I found that the resulting env->eflags may be invalid.
+In my test case, the loop was exiting with eflags = 0x44 and CC_OP = CC_OP_SUBL with CC_DST=1, CC_SRC=258, CC_SRC2=0.
+While 'cpu_cc_compute_all' computes the correct flags (ZF:0, PF:0), the result will still be 0x44 (ZF:1, PF:1) due to the 'or' operation, thus leading to an incorrect eflags value loaded into the CPU env.Â
+In my case, after loop reentry, it led to an invalid branch to be taken.
+Thanks for your time!
+Regards
+Stevie
+Â
+On Thu, Aug 5, 2021 at 1:33 PM Paolo Bonzini <
+pbonzini@redhat.com
+> wrote:
+On 05/08/21 13:24, Paolo Bonzini wrote:
+> On 05/08/21 11:51, Stevie Lavern wrote:
+>>
+>> Shouldn't it be:
+>> eflags = cpu_cc_compute_all(env, CC_OP) | (env->df & DF_MASK);
+>> as eflags is entirely reevaluated by "cpu_cc_compute_all" ?
+>
+> No, both are wrong.  env->eflags contains flags other than the
+> arithmetic flags (OF/SF/ZF/AF/PF/CF) and those have to be preserved.
+>
+> The right code is in helper_read_eflags.  You can move it into
+> cpu_compute_eflags, and make helper_read_eflags use it.
+Ah, actually the two are really the same, the TF/VM bits do not apply to
+cpu_compute_eflags so it's correct.
+What seems wrong is migration of the EFLAGS register.  There should be
+code in cpu_pre_save and cpu_post_load to special-case it and setup
+CC_DST/CC_OP as done in cpu_load_eflags.
+Also, cpu_load_eflags should assert that update_mask does not include
+any of the arithmetic flags.
+Paolo
+----
diff --git a/ollama/ollama.py b/ollama/ollama.py
deleted file mode 100755
index ea183b39..00000000
--- a/ollama/ollama.py
+++ /dev/null
@@ -1,17 +0,0 @@
-from ollama import chat, ChatResponse
-
-model = "deepseek-r1:70b"
-
-response: ChatResponse = chat(
-    model=model, messages=[
-        {
-            'role': 'user',
-            'content': 'Hello, how are you?',
-        }
-    ],
-    stream=True
-)
-
-for chunk in response:
-    print(chunk['message']['content'], end='', flush=True)
-print("\n")
diff --git a/ollama/preambel b/ollama/preambel
new file mode 100644
index 00000000..d2d498f2
--- /dev/null
+++ b/ollama/preambel
@@ -0,0 +1,62 @@
+We have this gitlab issue for the project qemu. This is a semantic mistranslation bug:
+----
+x86 BLSMSK semantic bug
+Host environment
+
+Operating system: Windows 10 20H2
+OS/kernel version: WSL2 Ubuntu 20.04.4 LTS (GNU/Linux 5.10.102.1-microsoft-standard-WSL2 x86_64)
+Architecture: x86
+QEMU flavor: qemu-x86_64
+QEMU version: 7.1.90 (v7.2.0-rc0)
+QEMU command line: qemu-x86_64 -cpu max a.out
+
+Emulated/Virtualized environment
+
+Operating system: None
+OS/kernel version: None
+Architecture: x86
+
+Description of problem
+The result of instruction BLSMSK is different with from the CPU. The value of CF is different.
+
+Steps to reproduce
+
+Compile this code
+
+void main() {
+    asm("mov rax, 0x65b2e276ad27c67");
+    asm("mov rbx, 0x62f34955226b2b5d");
+    asm("blsmsk eax, ebx");
+}
+
+Execute and compare the result with the CPU.
+CPU CF = 0
+QEMU CF = 1
+----
+
+This issue results in the following toml:
+----
+id = 1371
+title = "x86 BLSMSK semantic bug"
+state = "closed"
+created_at = "2022-12-16T06:43:29.794Z"
+closed_at = "2023-03-01T01:08:38.844Z"
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1371"
+host-os = "Windows 10 20H2"
+host-arch = "x86"
+qemu-version = "7.1.90 (v7.2.0-rc0)"
+guest-os = "None"
+guest-arch = "x86"
+description = """The result of instruction BLSMSK is different with from the CPU. The value of CF is different."""
+reproducer = """
+void main() {
+    asm("mov rax, 0x65b2e276ad27c67");
+    asm("mov rbx, 0x62f34955226b2b5d");
+    asm("blsmsk eax, ebx");
+}
+"""
+additional = """This bug is discovered by research conducted by KAIST SoftSec."""
+semantic = "yes"
+----
+
+For the following mailing thread, output only a toml with the corresponding variables. If an information cannot be gathered, put "n/a" instead. But you have to determine, if it is a semantic bug or not: