diff options
Diffstat (limited to 'results/classifier/gemma3:12b/debug/1072')
| -rw-r--r-- | results/classifier/gemma3:12b/debug/1072 | 25 |
1 files changed, 25 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/debug/1072 b/results/classifier/gemma3:12b/debug/1072 new file mode 100644 index 000000000..0181b249b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1072 @@ -0,0 +1,25 @@ + +different behavior when remote debugger is used +Description of problem: +I found Qemu shows different behavior when I run Qemu with hello-world (statically linked binary enclosed) directly or run it through remote debugger. I need help to understand the following: + +1. Is this intended behavior? +1. Any way to make the two approaches have consistent behavior (I prefer the behavior shown in the 2nd approach described below) +1. If it is intended behavior, any explanation why or suggestions how to dig further to root cause the difference. + +The corresponding source code is the line 86 in [filedoalloc.c](https://code.woboq.org/userspace/glibc/libio/filedoalloc.c.html#86). It tests if the file (stdout) is char special device (S_ISCHR) +The preprocessed code is as follows: + if (((((st.st_mode)) & 0170000) == (0020000))) + +I then compared two different approaches to run Qemu: + +1. I used the following command line to collect the trace: qemu_aarch64 -strace -plugin $QEMU_ROOT/build/contrib/plugins/libexeclog.so -d plugin hello.a64. This one tests False for S_ISCHR +1. when I used gdb to connect to Qemu and single-step the instructions, S_ISCHR tests True, which is different from running qemu directly (approach 1). + +Thanks! +Steps to reproduce: +1.[hello.a64](/uploads/4b4ccae8c1e4b045c39ceae6a094d55a/hello.a64) +2. +3. +Additional information: + |