Instructions implementing another missing facility,
getting us a bit closer to being able to upgrade the
default tcg cpu.

Plus one bug fix for an existing instruction that
isn't used unless we upgrade the tcg cpu.


r~


The following changes since commit 4871b51b9241b10f4fd8e04bbb21577886795e25:

  vmgenid-test: use boot-sector infrastructure (2017-07-14 17:03:03 +0100)

are available in the git repository at:

  git://github.com/rth7680/qemu.git tags/pull-s390-20170715

for you to fetch changes up to 4fb4047e74c21a3692360b9b1df473d7512d8055:

  target/s390x: Fix risbg handling (2017-07-15 07:17:36 -1000)

----------------------------------------------------------------
Queued s390x tcg patches

----------------------------------------------------------------
David Hildenbrand (1):
      target/s390x: Allow to enable "idtes" feature for TCG

Richard Henderson (7):
      target/s390x: Implement CSST
      target/s390x: Implement CONVERT UNICODE insns
      target/s390x: Tidy SRST
      target/s390x: Implement SRSTU
      target/s390x: Implement TRTR
      target/s390x: Mark ETF3 and ETF3_ENH facilities as available
      target/s390x: Fix risbg handling

 target/s390x/helper.h      |  11 +-
 target/s390x/cpu_models.c  |   5 +
 target/s390x/mem_helper.c  | 585 +++++++++++++++++++++++++++++++++++++++++++--
 target/s390x/translate.c   |  99 +++++++-
 target/s390x/insn-data.def |  21 +-
 5 files changed, 696 insertions(+), 25 deletions(-)

On 15 July 2017 at 18:30, Richard Henderson <rth@twiddle.net> wrote:
> Instructions implementing another missing facility,
> getting us a bit closer to being able to upgrade the
> default tcg cpu.
>
> Plus one bug fix for an existing instruction that
> isn't used unless we upgrade the tcg cpu.
>
>
> r~
>
>
> The following changes since commit 4871b51b9241b10f4fd8e04bbb21577886795e25:
>
>   vmgenid-test: use boot-sector infrastructure (2017-07-14 17:03:03 +0100)
>
> are available in the git repository at:
>
>   git://github.com/rth7680/qemu.git tags/pull-s390-20170715
>
> for you to fetch changes up to 4fb4047e74c21a3692360b9b1df473d7512d8055:
>
>   target/s390x: Fix risbg handling (2017-07-15 07:17:36 -1000)
>
> ----------------------------------------------------------------
> Queued s390x tcg patches

Hi. This fails to link with clang (OSX, linux, freebsd):

Undefined symbols for architecture x86_64:
  "_helper_atomic_cmpxchgq_be_mmu", referenced from:
      _helper_csst in mem_helper.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

thanks
-- PMM

On 07/17/2017 12:46 AM, Peter Maydell wrote:
> Hi. This fails to link with clang (OSX, linux, freebsd):
> 
> Undefined symbols for architecture x86_64:
>    "_helper_atomic_cmpxchgq_be_mmu", referenced from:
>        _helper_csst in mem_helper.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)

What os and clang version?

Because, frankly, I can't even get this far with clang 3.9 as shipped with 
fedora 25.  As far as I can see top-of-tree doesn't build at all with that 
compiler.


r~

On 17 July 2017 at 20:36, Richard Henderson <rth@twiddle.net> wrote:
> On 07/17/2017 12:46 AM, Peter Maydell wrote:
>>
>> Hi. This fails to link with clang (OSX, linux, freebsd):
>>
>> Undefined symbols for architecture x86_64:
>>    "_helper_atomic_cmpxchgq_be_mmu", referenced from:
>>        _helper_csst in mem_helper.o
>> ld: symbol(s) not found for architecture x86_64
>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>
>
> What os and clang version?
>
> Because, frankly, I can't even get this far with clang 3.9 as shipped with
> fedora 25.  As far as I can see top-of-tree doesn't build at all with that
> compiler.

This was OSX 10.12.5 (Sierra) running
Apple LLVM version 7.0.0 (clang-700.1.76)
(running strings on the binary suggests this is based
on upstream clang 3.7.0)

and Linux Ubuntu x86_64 Xenial running
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)

and FreeBSD 11.0 running
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
LLVM 3.8.0)

If we don't build with clang 3.9 that's worth fixing;
it's not in my test set, which will be why the
breakage has slipped through.

thanks
-- PMM

On 07/17/2017 10:31 AM, Peter Maydell wrote:
> and Linux Ubuntu x86_64 Xenial running
> clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)

Ok, I can reproduce this just fine with debian stretch and clang 3.8.

> If we don't build with clang 3.9 that's worth fixing;
> it's not in my test set, which will be why the
> breakage has slipped through.

There's one bit of cpuid.h breakage and one bit of user error there.

Should we simply stop relying on the cpuid.h shipped with the compiler and 
provide our own?  Or at least wrap the compiler's version and add #ifndef for 
every bit_FOO used within qemu?


r~