diff options
| -rwxr-xr-x | ollama/llm.py | 31 | ||||
| -rw-r--r-- | ollama/mail | 184 | ||||
| -rwxr-xr-x | ollama/ollama.py | 17 | ||||
| -rw-r--r-- | ollama/preambel | 62 |
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: |