On Saturday 09 May 2015, Jan Engelhardt wrote:

On Saturday 2015-05-09 12:18, Ruediger Meier wrote:

...

On armv6l and aarch64 I've noticed that we have strange process names in /proc/PID/*. It's always "qemu-arm" or "qemu-arm64".

For example running in bash we get:

$ cat /proc/$$/status | grep "Name:" qemu-arm $ ls -l /proc/$$/exe lrwxrwxrwx 1 abuild abuild 0 May 9 09:53 /proc/5526/exe -> /usr/bin/qemu-arm $ cat /proc/$$/cmdline /usr/bin/qemu-arm-0bash/bin/bash/home/abuild/rpmbuild/SOURCES/build_ host_info.sh

Is it possible to get this fixed?

Note that the contents of $$/cmdline are dependent on program memory, and that a program is free to modify the bytes referenced by argv.

perl -e '$0 = "foo"; system "cat /proc/$$/cmdline";'

Yes this shows "foo". But /proc/PID/comm does not. BTW the programs I've tested do not change argv.

Doing so does not change the fact that you are still running the same executable, hence the "exe" symlinks stays the same.

It does not show the executed binary.

(Notabug.)

cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Saturday 09 May 2015, Andreas Schwab wrote:

Ruediger Meier writes:

...

Is it possible to get this fixed?

No, because that _is_ the binary that executes (emulates) your processes.

But then this obs build host does not behave like a "normal" host. In my case it brakes the test-suite. This is something which should work IMO: $ sleep 100 & $ killall sleep Also sudo does not work. It's a releated issue I guess. cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Saturday 09 May 2015, Andreas Schwab wrote:

Ruediger Meier writes:

...

But then this obs build host does not behave like a "normal" host. In my case it brakes the test-suite.

That's just the consequence of using an emulation layer. You get the same discrepancy with valgrind, or when running a binary via ld.so.

If you want a "normal" host, you need to use at least full system emulation, if not native hardware.

Exactly, why we don't do this for armv6 and aarch64? All other build hosts (armv7l) are fully simulated. I have a lot more issues beside this /proc issue. cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Thank you for explaining this. It helped me to work around a problem we had with GNUstep not getting the command line arguments correctly from the /proc file system. BTW, why did I have to test for armv6hl in #ifarch instead of armv6l as it is called externally? Fred On the road Am 09.05.2015 um 13:45 schrieb Andreas Schwab :

Ruediger Meier writes:

...

But then this obs build host does not behave like a "normal" host. In my case it brakes the test-suite.

That's just the consequence of using an emulation layer. You get the same discrepancy with valgrind, or when running a binary via ld.so.

If you want a "normal" host, you need to use at least full system emulation, if not native hardware.

Andreas. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org