Re: [Qemu-devel] [Bug 1791796] Re: unimplemented thread syscalls in nios2 user-mode emulation

["Alex Bennée" <alex.bennee@linaro.org>]

Sandra Loosemore <1791796@bugs.launchpad.net> writes:

> If you need a Nios II GNU/Linux toolchain, I think the most recent
> CodeBench Lite release will work:
>
> https://sourcery.mentor.com/GNUToolchain/subscription42545

Hmm I tried automating that but it seems the installer has GTK
dependencies!?

  Setup:
  GTK+ Version Check
  Setup:
  An error has occurred. See the log file
  /root/.mentor/logs/20180911185933/.metadata/.log.
  root@0ef91b5e50f2:/opt# cat /root/.mentor/logs/20180911185933/.metadata/.log
  !SESSION 2018-09-11 18:59:36.197 -----------------------------------------------
  eclipse.buildId=unknown
  java.version=1.8.0_102
  java.vendor=Oracle Corporation
  BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US
  Framework arguments:  -install.once -install.data=/root/.mentor
  Command-line arguments:  -os linux -ws gtk -arch x86 -install.once -install.data=/root/.mentor -data /root/.mentor/logs/20180911185933

  !ENTRY org.eclipse.osgi 4 0 2018-09-11 18:59:37.407
  !MESSAGE Application error
  !STACK 1
  java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
          /tmp/sourceryg++-2018.05-5-nios2-linux-gnu.bin_sfx.f9eaefb7/installer/configuration/org.eclipse.osgi/148/0/.cp/libswt-pi-gtk-4530.so: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory
          no swt-pi-gtk in java.library.path
          Can't load library: /root/.swt/lib/linux/x86/libswt-pi-gtk-4530.so
          Can't load library: /root/.swt/lib/linux/x86/libswt-pi-gtk.so
          /root/.swt/lib/linux/x86/libswt-pi-gtk-4530.so: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

Should I just try the tarball approach?

> We're planning on adding user-mode QEMU to the upcoming 2018.11
> release....  that's actually what I've been testing it for.  Results on
> the GCC testsuite actually don't look too bad,

OK - I'm a little surprised given the failures I saw in our own
test/tcg/multiarch but it's totally possible that:

  - the buildroot toolchain if foobar
  - the (ancient) tests need tweaking

but it would be nice if we get to a point that QEMU's internal
linux-user tests also pass.

> but I have a patch I
> haven't submitted yet that's required to make the GDB stub work, and
> there are a lot of GDB test failures I haven't triaged yet.

When you do post the gdb patch feel free to CC me as I've poked around
in that before.

--
Alex Bennée