Re: [Qemu-devel] [Bug 1625295] Re: qemu-arm dies with libarmmem inside ld.so.preload

[Stu]

Yup, got it - cheers :)

On 20 October 2016 at 08:41, Peter Maydell 
wrote:

> NB that commit 9b6a3ea7a69959416 had a bug (it broke exception return to
> Thumb code), so you should also make sure you have commit fb0e8e79a9d77
> which fixes that bug.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1625295
>
> Title:
>   qemu-arm dies with libarmmem inside ld.so.preload
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1625295

Title:
  qemu-arm dies with libarmmem inside ld.so.preload

Status in QEMU:
  Fix Committed

Bug description:
  When running raspbian inside qemu,the user has to first comment out
  the following line from /etc/ld.so.conf:

  /usr/lib/arm-linux-gnueabihf/libarmmem.so

  
  Will future qemus will be able to work without changine /etc/ld.so.conf ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions

[Qemu-devel] [Bug 1625295] Re: qemu-arm dies with libarmmem inside ld.so.preload

[Stu]

Quick followup on this, finally got the time to build this + can
confirming I can boot raspbian with the default /etc/ld.so.conf to the
command prompt (both raspbian jessie lite and the default distro).

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1625295

Title:
  qemu-arm dies with libarmmem inside ld.so.preload

Status in QEMU:
  Fix Committed

Bug description:
  When running raspbian inside qemu,the user has to first comment out
  the following line from /etc/ld.so.conf:

  /usr/lib/arm-linux-gnueabihf/libarmmem.so

  
  Will future qemus will be able to work without changine /etc/ld.so.conf ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions

Re: [Qemu-devel] [Bug 1625295] Re: qemu-arm dies with libarmmem inside ld.so.preload

[Stu]

Awesome, thanks :)

On 4 October 2016 at 15:55, Peter Maydell 
wrote:

> Now fixed in QEMU master, commit 9b6a3ea7a69959416.
>
>
> ** Changed in: qemu
>Status: In Progress => Fix Committed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1625295
>
> Title:
>   qemu-arm dies with libarmmem inside ld.so.preload
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1625295

Title:
  qemu-arm dies with libarmmem inside ld.so.preload

Status in QEMU:
  Fix Committed

Bug description:
  When running raspbian inside qemu,the user has to first comment out
  the following line from /etc/ld.so.conf:

  /usr/lib/arm-linux-gnueabihf/libarmmem.so

  
  Will future qemus will be able to work without changine /etc/ld.so.conf ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions

Re: [Qemu-devel] [Bug 1625295] Re: qemu-arm dies with libarmmem inside ld.so.preload

[Stu]

Awesome, cheers :)

On 20 September 2016 at 14:29, Peter Maydell 
wrote:

> Thanks. I can reproduce this with the current QEMU, so there is still a
> problem of some kind here.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1625295
>
> Title:
>   qemu-arm dies with libarmmem inside ld.so.preload
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1625295

Title:
  qemu-arm dies with libarmmem inside ld.so.preload

Status in QEMU:
  New

Bug description:
  When running raspbian inside qemu,the user has to first comment out
  the following line from /etc/ld.so.conf:

  /usr/lib/arm-linux-gnueabihf/libarmmem.so

  
  Will future qemus will be able to work without changine /etc/ld.so.conf ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions

Re: [Qemu-devel] [Bug 1625295] Re: qemu-arm dies with libarmmem inside ld.so.preload

[Stu]

Are bash scripts OK ?


I put everything into some scripts - I'm on ubuntu, debian should be
similar - not sure about other platforms.


# Grab scripts
$ git clone https://github.com/stuaxo/raspbian-qemu-scripts
$ cd raspbian-qemu-scripts

# Download current raspbian lite to /tmp/raspbian:
$ ./download-raspbian.sh



# Test that may fail - run
/tmp/raspbian/2016-05-27-raspbian-jessie-lite.img in qemu:
$ ./run_qemu.sh


# If the above fails, then it's you can edit /etc/ld.so.preload ---
$ ./mount-raspbian.sh

^ mounts the image to /tmp/raspbian/

Now edit the file  /tmp/raspbian/etc/ld.so.preload  and comment any lines,
e.g

$ sudo nano -w /tmp/raspbian/mnt/etc/ld.so.preload

$ umount /tmp/raspbian

## Test again in qemu

$ ./run_qemu.sh


One I get do the edit, qemu works for me.
To get chroot working, one has to mount the image and copy the file

$ ./mount-raspbian.sh
$ sudo cp /usr/bin/qemu-arm-static /tmp/raspbian/mnt/usr/bin

# After that chroot works...
$ sudo chroot /tmp/raspbian/mnt

-- Remember to umount the image before using qemu + but mount for chroot
:)






On 20 September 2016 at 11:22, Peter Maydell 
wrote:

> As I say, for providing reproduction instructions you have to assume I
> know nothing about raspbian, so "trying stock raspbian in qemu" is not
> detailed enough. I was looking for details more like "download this
> particular image from this website and then run this specific QEMU
> commandline, and then in the guest do  and it fails in  way>".
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1625295
>
> Title:
>   qemu-arm dies with libarmmem inside ld.so.preload
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1625295

Title:
  qemu-arm dies with libarmmem inside ld.so.preload

Status in QEMU:
  New

Bug description:
  When running raspbian inside qemu,the user has to first comment out
  the following line from /etc/ld.so.conf:

  /usr/lib/arm-linux-gnueabihf/libarmmem.so

  
  Will future qemus will be able to work without changine /etc/ld.so.conf ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions

Re: [Qemu-devel] [Bug 1625295] Re: qemu-arm dies with libarmmem inside ld.so.preload

[Stu]

Cheers :)

May as well close this, I'll re-open it if I try 2.7 and find the same
bug.

Testing involves trying stock raspbian in qemu.


On 20 September 2016 at 10:26, Peter Maydell <peter.mayd...@linaro.org>
wrote:

> On 20 September 2016 at 00:02, Stu <stu.a...@gmail.com> wrote:
> > - I'm on Ubuntu 16.04, and it looks like it's 2.6.1
> >
> > qemu-arm version 2.6.1 (Debian 1:2.6.1+dfsg-0~16.04), Copyright (c)
> > 2003-2008 Fabrice Bellard
> >
> > Is there a PPA for qemu 2.7 somewhere ?
>
> You'd need to ask the Ubuntu folks about that. Upstream
> we provide source code distributions only.
>
> thanks
> -- PMM
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1625295
>
> Title:
>   qemu-arm dies with libarmmem inside ld.so.preload
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1625295

Title:
  qemu-arm dies with libarmmem inside ld.so.preload

Status in QEMU:
  New

Bug description:
  When running raspbian inside qemu,the user has to first comment out
  the following line from /etc/ld.so.conf:

  /usr/lib/arm-linux-gnueabihf/libarmmem.so

  
  Will future qemus will be able to work without changine /etc/ld.so.conf ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions

Re: [Qemu-devel] [Bug 1625295] Re: qemu-arm dies with libarmmem inside ld.so.preload

[Stu]

- I'm on Ubuntu 16.04, and it looks like it's 2.6.1

qemu-arm version 2.6.1 (Debian 1:2.6.1+dfsg-0~16.04), Copyright (c)
2003-2008 Fabrice Bellard

Is there a PPA for qemu 2.7 somewhere ?


On 19 September 2016 at 21:27, Peter Maydell 
wrote:

> Which version of QEMU are you using? This is I think due to SETEND
> emulation, which I thought we had implemented now.
>
> If this still doesn't work on QEMU 2.7, please can you provide full
> instructions to reproduce the problem (assume I know nothing about how
> to get raspbian or run it on QEMU).
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1625295
>
> Title:
>   qemu-arm dies with libarmmem inside ld.so.preload
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1625295

Title:
  qemu-arm dies with libarmmem inside ld.so.preload

Status in QEMU:
  New

Bug description:
  When running raspbian inside qemu,the user has to first comment out
  the following line from /etc/ld.so.conf:

  /usr/lib/arm-linux-gnueabihf/libarmmem.so

  
  Will future qemus will be able to work without changine /etc/ld.so.conf ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions

[Qemu-devel] [Bug 1625295] [NEW] qemu-arm dies with libarmmem inside ld.so.preload

[Stu]

Public bug reported:

When running raspbian inside qemu,the user has to first comment out the
following line from /etc/ld.so.conf:

/usr/lib/arm-linux-gnueabihf/libarmmem.so


Will future qemus will be able to work without changine /etc/ld.so.conf ?

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1625295

Title:
  qemu-arm dies with libarmmem inside ld.so.preload

Status in QEMU:
  New

Bug description:
  When running raspbian inside qemu,the user has to first comment out
  the following line from /etc/ld.so.conf:

  /usr/lib/arm-linux-gnueabihf/libarmmem.so

  
  Will future qemus will be able to work without changine /etc/ld.so.conf ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions

[Qemu-devel] PowerPC code generation and the program counter

[Stu Grossman]

I've been using qemu-12.4 to trace accesses to non-existent addresses, but I've
found that the PC is incorrect when cpu_abort() is called from within the
unassigned memory helper routines (unassigned_mem_read[bwl] and
unassigned_mem_write[bwl]).  Even nearby instructions (plus or minus 10
instructions or so) don't match the type of load or store being done, so this
isn't a PC being current_instr+4 kind of thing.

I ended up modifying the GEN_LD* and GEN_ST* macros (in target-ppc/translate.c)
to call gen_update_nip(ctx, ctx-nip - 4).  This fixed the above problem, which
has helped enormously.

Since I'm not a qemu expert, I was wondering about several things:

1) Was it really necessary to add gen_update_nip to the load and store
   instructions in order to get the correct PC?  Could the correct PC
   have been derived some other way, without a runtime cost for all
   basic loads and stores?
2) As the current code lacks that fix, the basic load and store
   instructions will save an incorrect PC if an exception occurs.  If
   so, how come nobody noticed this before?  I think that exceptions
   would have srr0 pointing at the last instruction which called
   gen_update_nip.  So when the target returns from a data exception,
   it might re-execute some instructions.  Possibly harmless, but could
   lead to subtle bugs...

Thanks, Stu

Here's the patch if anybody is interested:

*** translate.c~Sat Sep 11 23:43:25 2010
--- translate.c Sun Sep 12 20:49:53 2010
***
*** 2549,2554 
--- 2549,2555 
  {
 \
  TCGv EA;
 \
  gen_set_access_type(ctx, ACCESS_INT);
 \
+ gen_update_nip(ctx, ctx-nip - 4);
   \
  EA = tcg_temp_new();
 \
  gen_addr_imm_index(ctx, EA, 0);
 \
  gen_qemu_##ldop(ctx, cpu_gpr[rD(ctx-opcode)], EA);
 \
***
*** 2564,2569 
--- 2565,2571 
  gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
 \
  return;
 \
  }
 \
+ gen_update_nip(ctx, ctx-nip - 4);
   \
  gen_set_access_type(ctx, ACCESS_INT);
 \
  EA = tcg_temp_new();
 \
  if (type == PPC_64B)
 \
***
*** 2584,2589 
--- 2586,2592 
  gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
 \
  return;
 \
  }
 \
+ gen_update_nip(ctx, ctx-nip - 4);
   \
  gen_set_access_type(ctx, ACCESS_INT);
 \
  EA = tcg_temp_new();
 \
  gen_addr_reg_index(ctx, EA);
 \
***
*** 2596,2601 
--- 2599,2605 
  static void glue(gen_, name##x)(DisasContext *ctx)
 \
  {
 \
  TCGv EA;
 \
+ gen_update_nip(ctx, ctx-nip - 4);
   \
  gen_set_access_type(ctx, ACCESS_INT);
 \
  EA = tcg_temp_new();
 \
  gen_addr_reg_index(ctx, EA);
 \
***
*** 2693,2698 
--- 2697,2703 
  static void glue(gen_, name)(DisasContext *ctx)
 \
  {
 \
  TCGv EA;
 \
+ gen_update_nip(ctx, ctx-nip - 4);
   \
  gen_set_access_type(ctx, ACCESS_INT);
 \
  EA = tcg_temp_new();
 \
  gen_addr_imm_index(ctx, EA, 0);
 \
***
*** 2708,2713 
--- 2713,2719 
  gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
 \
  return;
 \
  }
 \
+ gen_update_nip(ctx, ctx-nip - 4);
   \
  gen_set_access_type(ctx, ACCESS_INT);
 \
  EA = tcg_temp_new();
 \
  if (type == PPC_64B)
 \
***
*** 2727,2732 
--- 2733,2739 
  gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
 \
  return;
 \
  }
 \
+ gen_update_nip(ctx, ctx-nip - 4);
   \
  gen_set_access_type(ctx, ACCESS_INT);
 \
  EA = tcg_temp_new();
 \
  gen_addr_reg_index(ctx, EA);
 \
***
*** 2739,2744 
--- 2746,2752 
  static void glue(gen_, name##x)(DisasContext *ctx)
 \
  {
 \
  TCGv EA;
 \
+ gen_update_nip(ctx, ctx-nip - 4);
   \
  gen_set_access_type(ctx, ACCESS_INT);
 \
  EA = tcg_temp_new();
 \
  gen_addr_reg_index(ctx, EA);
 \