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 in
n't support
XML files 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
---
target/ppc/gdbstub.c | 26 ++
n't support
XML files 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
---
target/ppc/gdbstub.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions
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 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 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
> https://gith
Hi,
On Tue, 25 Feb 2014, Peter Maydell wrote:
> On 25 February 2014 13:33, Michael Matz 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 sy
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 gene
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 Thu, 6 Feb 2014, Peter Maydell wrote:
> On 6 February 2014 13:45, Michael Matz 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 sup
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
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 cas
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
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, y
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. S
and logical.
> > In particular, C and V are always zero.
That's done correctly with the fixed pstate helpers coming with a later
patch (see attached as well). reg31 is zero, so that's flags as if for
"dest == dest + 0", and PSTATE_C and PSTATE_V will be zero. That is, t
Hi,
On Tue, 29 Oct 2013, Peter Maydell wrote:
> On 29 October 2013 18:55, Alex Bennée 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 how far it gets.
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,
> >
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
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
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 a
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
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.
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"
Hi,
[answering to a forwarded mail, hence breaking thread, sorry]
[and keep me CCed :) ]
On Fri, 18 Jan 2008, Alexander Graf wrote:
> >From: Johannes Schindelin <[EMAIL PROTECTED]>
> >Date: January 18, 2008 3:05:58 AM GMT+01:00
> >To: consul <[EMAIL PROTECTED]>
> >Cc: qemu-devel@nongnu.org
> >Su
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" compi
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 c
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 alread
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 t
Hi,
On Wed, 29 Aug 2007, Andreas Färber wrote:
> > >What do you mean with 0.9.0-cvs? The 0.9.0 GCC4 patches for OSX/Intel
> >
> >Do you mean my patches?
>
> No. Are yours already OSX-compatible?
No OSX, no idea :)
> I referred to previous patches, specifically those currently applied for
> Q:
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, Andreas Färber wrote:
> Am I right to assume that compiling with gcc3 will still work with your
> patch?
Yes.
> In that case your patch would enable qemu to run on gcc4-only platforms
> (where performance doesn't matter too much yet) while allowing to
> compile with
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 f
33 matches
Mail list logo
