Hello,
On Thu, 22 Jul 2021, Richard Biener via Gcc wrote:
> But how does TLS usage transfer between threads? On the gimple level
> the TLS pointer is not visible and thus we'd happily CSE its address:
Yes. All take-address operations then need to be encoded explicitely with
a non-CSE-able
for describing registers. Also the XER state in qemu
doesn't seem to use the high 32 bits, so sending it off to gdb
doesn't seem worthwhile.
[v2: fix formatting in moved line and adjust others]
Signed-off-by: Michael Matz <m...@suse.de>
---
target/ppc/gdbstub.c | 26 +--
for describing registers. Also the XER state in qemu
doesn't seem to use the high 32 bits, so sending it off to gdb
doesn't seem worthwhile.
Signed-off-by: Michael Matz <m...@suse.de>
---
target/ppc/gdbstub.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/
Hi,
On Sun, 9 Mar 2014, Peter Maydell wrote:
diff --git a/target-arm/translate-a64.c b/target-arm/translate-a64.c
index 6a3597d..2435c95 100644
--- a/target-arm/translate-a64.c
+++ b/target-arm/translate-a64.c
@@ -9007,9 +9007,8 @@ static void disas_simd_two_reg_misc(DisasContext *s,
Hi,
On Mon, 10 Mar 2014, Alex Bennée wrote:
Not sure there's much point looking very deeply into this. Java
programs are threaded, threaded programs don't work under QEMU =
don't try to run Java under QEMU :-)
Having said that I'm sure there was another SIGILL related crash on
Hi,
On Wed, 26 Feb 2014, Dann Frazier wrote:
I've narrowed down the changes that seem to prevent both types of
segfaults to the following changes that introduce a wrapper around
sigprocmask:
https://github.com/susematz/qemu/commit/f1542ae9fe10d5a241fc2624ecaef5f0948e3472
Hi,
On Tue, 25 Feb 2014, Andreas Färber wrote:
There are some pretty large differences between these trees with
respect to signal syscalls - is that the likely culprit?
Quite likely. We explicitly concentrated on the arch64 specific
instruction emulation leaving more generic patches
Hi,
On Tue, 25 Feb 2014, Peter Maydell wrote:
On 25 February 2014 13:33, Michael Matz m...@suse.de wrote
The biggest road-block is that signal vs syscall handling is
fundamentally broken in linux-user and it's unfixable without
assembler implementations of the syscall caller.
I'm
Hi,
On Wed, 5 Feb 2014, Peter Maydell wrote:
Changes v2 - v3:
* added a README clarifying that libvixl's disassembly support
is not complete and that contributions should go to libvixl
upstream first for preference
Hmm, why aren't we simply using the binutils disassembler? It's also
Hi,
On Thu, 6 Feb 2014, Peter Maydell wrote:
On 6 February 2014 13:45, Michael Matz m...@suse.de wrote:
Hmm, why aren't we simply using the binutils disassembler? It's also
(C) by ARM, so there shouldn't be any relicensing problems. And it
does support AdvSIMD and system instructions
Hi,
On Thu, 6 Feb 2014, Christopher Covington wrote:
The FSF always grants back rights on the contribution to the
contributor. ARM could simply double-license their original
contribution of the disassembler.
Is dual licensing always possible given a grant-back? What if the
Hi,
On Tue, 19 Nov 2013, Claudio Fontana wrote:
+uint64_t imm;
+uint64_t base;
+
+imm = get_sbits(insn, 5, 19) 2;
+imm |= get_bits(insn, 29, 2);
does this work with negative values?
Yes. get_sbits returns a sign extended (32bit) int, the shift doesn't
change
Hi,
On Tue, 19 Nov 2013, Janne Grunau wrote:
+static void handle_fpfpconv(DisasContext *s, uint32_t insn)
+{
+int opcode = get_bits(insn, 16, 3);
+int rmode = get_bits(insn, 20, 2);
rmode is at 19
+case 0x1: /* [S|U]CVTF (scalar-float) */
and it's case 0x0: for
.
Ciao,
Michael.From df54486da31d6329696effa61096eda5ab85395a Mon Sep 17 00:00:00 2001
From: Michael Matz m...@suse.de
Date: Sun, 24 Mar 2013 02:52:42 +0100
Subject: [PATCH] Fix 32bit rotates.
The 32bit shifts generally weren't careful with the upper parts,
either bits could leak in (for right shift
Hi,
On Mon, 18 Nov 2013, Peter Maydell wrote:
+case 3:
+tcg_gen_rotr_i64(r, cpu_reg(reg), tcg_shift);
+break;
Incorrect rotate for 32bit?
32bit rotates and shifts were fixed in a patch later than the 60er series
Alex posted. See attached. (Generally
Hi,
On Mon, 18 Nov 2013, Claudio Fontana wrote:
+tcg_gen_trunc_i64_i32(tmp, cpu_reg(reg));
+ tcg_gen_rotr_i32(tmp, tmp, tcg_shift);
Isn't this problematic?
We are using gen_rotr_i32, but passing tcg_shift, which is a TCGv_i64.
With CONFIG_DEBUG_TCG it'll break, yes.
Hi,
On Tue, 29 Oct 2013, Peter Maydell wrote:
On 29 October 2013 18:55, Alex Bennée alex.ben...@linaro.org wrote:
I think the problem is arm64 has been posted in several dependant patch
sets hence working from a git tree. I think for now I'll take off the
-Werror training wheels and see
Hi,
On Mon, 21 Mar 2011, Andre Przywara wrote:
.name = qemu64,
.level = 4,
.vendor1 = CPUID_VENDOR_AMD_1,
.vendor2 = CPUID_VENDOR_AMD_2,
.vendor3 = CPUID_VENDOR_AMD_3,
.family = 6,
.model = 2,
.stepping = 3,
Hi,
On Mon, 1 Nov 2010, Alexander Graf wrote:
No. Pointers of same type which are not void pointers can be compared.
There is even a data type ptrdiff_t, so you can also compare their
difference with zero.
Let's ask someone who definitely knows :).
Michael, is code like
char *x
Hi,
On Fri, 18 Jan 2008, Johannes Schindelin wrote:
Well, I can tell you why, but it doesn't help you: the 3.4.2 compiler
has different deficiencies in reload than the 4.x line of compilers.
To make the whole thingy work on all compilers trying and testing is
required to avoid all
Hi,
On Fri, 18 Jan 2008, Johannes Schindelin wrote:
asm ( ... movzbl %b1, %%edx\n ... : : r (blubb), r (bla) );
Okay, but this only concerns gcc4, apparently.
No, it's nothing to do with GCC.
But apparently it has! With gcc 4 I did never get the error.
As I tried to
Hi,
On Fri, 18 Jan 2008, Johannes Schindelin wrote:
But apparently it has! With gcc 4 I did never get the error.
As I tried to explain, this is pure luck.
Maybe.
Which probably means that gcc 4 did _not_ use ecx, and therefore it
does not have to be pushed and popped.
Hi,
On Fri, 18 Jan 2008, Johannes Schindelin wrote:
But I'm not talking about the clobber list at all. I reacted to the
first mail forwarded to me, which was a question specifically about the
hunk adding the q constraint, whose purpose I explained. Are you now
also asking about the
Hi,
On Fri, 18 Jan 2008, Johannes Schindelin wrote:
+#if DATA_SIZE == 1 || DATA_SIZE == 2
+ q (v),
+#else
r (v),
+#endif
i ((CPU_TLB_SIZE - 1) CPU_TLB_ENTRY_BITS),
i (TARGET_PAGE_BITS -
Hi,
On Thu, 30 Aug 2007, Thiemo Seufer wrote:
* ppc: adds -fno-section-anchors to OP_CFLAGS, as dyngen isn't prepared
to deal with the relocs resulting from using section anchors
Maybe this should be handled more generally then, not ppc specific, like
other offending compiler
Hi,
On Wed, 29 Aug 2007, Michael Matz wrote:
I solved that by placing one of the T[012] operands into memory
for HOST_I386, thereby freeing one reg. Here's some justification
of why that doesn't really cost performance: with three free regs
GCC is already
Hi,
On Wed, 29 Aug 2007, Johannes Schindelin wrote:
The whole patch is against a 0.9.0-cvs version from 2007-07-09 (Alex
might know the exact checkout date), so chances are that it still
applies :)
It is based on the z80 fork, but it applies relatively cleanly (one
trailing
Hi,
On Wed, 29 Aug 2007, Johannes Schindelin wrote:
Thanks for your effor Michael! Now, I only hope, one of the patches
that makes qemu gcc4 compliant are soon merged.
Well, to throw a spanner in the works: this patch is the 4th patch along
the lines that I came about. None of them
Hi,
On Wed, 29 Aug 2007, Paul Brook wrote:
I solved that by placing one of the T[012] operands into memory
for HOST_I386, thereby freeing one reg. Here's some justification
of why that doesn't really cost performance: with three free regs
GCC is already
Hi,
[please keep me CCed, I'm not on this list]
the below patch let's qemu be compiled by GCC 4.2 (probably also 4.1 and
others) for most hosts (i386,x86_64,ia64,ppc). s390 as host is missing,
and needs a compiler change to emit the literal store inline again, as the
literal pool at the end
30 matches
Mail list logo
