https://bugs.kde.org/show_bug.cgi?id=372358
--- Comment #2 from Julian Seward ---
I can't reproduce this. Are you sure this is right? I tried
thusly:
int main ( void )
{
__asm__ __volatile__(
".byte 0xC5, 0xFA, 0x7F, 0x45, 0x80, 0xC5, 0xFA, 0x7F, 0x4D, 0x90"
:
https://bugs.kde.org/show_bug.cgi?id=371989
--- Comment #4 from Julian Seward ---
I'd fix this, if I could think of a sane way to do so. Alas ..
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=372794
--- Comment #1 from Julian Seward ---
Ach, the logic there that verifies whether the instruction decode is
valid, is wrong. Try this:
change
// Paranoia ..
vassert(szBlg2 <= 3);
if (szBlg2 < 3) { vassert(tt2 == 16/*i
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #16 from Julian Seward ---
I would be happy to make a generalised version of Maran's fixes,
so as to get arm{32,64} working on these cores. I don't really
want it to be the default implementation though, since we lose
correct
https://bugs.kde.org/show_bug.cgi?id=348616
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=352767
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=371966
--- Comment #12 from Julian Seward ---
Probably your least-worst option at this point is to compile the test
program in the configuration where the errors are not reported, and hope
that it all gets compiled into a single function (which it looks like
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #18 from Julian Seward ---
Some comments on the v3 patch:
Mostly it looks fine. Below [1] some small comments.
Larger comments:
* I assume there are no regressions with correctness or performance
with this, yes? Could you do a self
https://bugs.kde.org/show_bug.cgi?id=372120
--- Comment #2 from Julian Seward ---
(In reply to Mark Wielaard from comment #1)
> Yeah, I think it would be a good idea to at least recognize the
> default (gnu_v3) style c++ mangling, which always starts with _Z.
> Something like the
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #15 from Julian Seward ---
(In reply to Peter Maydell from comment #14)
> [..] so you might find your
> autodetect test code passed but later generated code didn't.
True.
> Plus on big.LITTLE you might later be running o
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #12 from Julian Seward ---
Andrew, do you know how well Maran's proposal
https://bugs.kde.org/show_bug.cgi?id=344524#c8 worked on MIPS64r3 (Octeon 3) ?
IOW is it worth taking and generalising?
--
You are receiving this mail because
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #11 from Julian Seward ---
(In reply to Andrew Pinski from comment #10)
Another possibility is to run a test sequence on the host CPU at startup,
whilst we are still single threaded, containing LL, SC and some stores in
between, and see if
https://bugs.kde.org/show_bug.cgi?id=371491
--- Comment #2 from Julian Seward ---
Sounds plausible, and it's nice that it's easy to fix. But I'm a bit concerned
about the untestability of this. Is there no easy way to test this?
--
You are receiving this mail because:
You a
https://bugs.kde.org/show_bug.cgi?id=344524
--- Comment #12 from Julian Seward ---
Maran, the same problem has been reported for ARM64/OCTEON3 at
https://bugs.kde.org/show_bug.cgi?id=369459. So let me ask: how well
does your proposed solution in comments 9 and 10 work? Did you deploy
it
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #9 from Julian Seward ---
Maybe we could use Maran's proposal for fixing the same problem on
MIPS OCTEON3. https://bugs.kde.org/show_bug.cgi?id=344524#c8 (and 9
and 10).
This provides a correct implementation, including coverage o
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #7 from Julian Seward ---
Hmm, I see stuff like this:
9858: 885ffe62ldaxr w2, [x19]
985c: 6b1f005fcmp w2, wzr
9860: 54fff7e1b.ne975c <__pthread_mutex_lock+0x44>
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #6 from Julian Seward ---
(In reply to Andrew Pinski from comment #5)
> One idea I have is to pattern match on the ldxr/stxr sequence and produce a
> single instruction in the IR and then decode them after the fact.
On considerat
https://bugs.kde.org/show_bug.cgi?id=371065
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=368507
--- Comment #5 from Julian Seward ---
I had hoped to do this for 3.12.0, but after looking at the #ifdef swamp
in VG_(am_startup) that sets aspacem_maxAddr, I think it is too risky,
because of the number of different cases that need to be verified.
So
https://bugs.kde.org/show_bug.cgi?id=359645
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=368419
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=357059
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=357932
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=369264
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=352197
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=358213
--- Comment #7 from Julian Seward ---
Should we close this now?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=365208
--- Comment #7 from Julian Seward ---
What CPU are you running on here?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=351282
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=366817
--- Comment #2 from Julian Seward ---
ping?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=367942
--- Comment #1 from Julian Seward ---
There have been commits to the trunk which make V more robust to
bad parameters to rt_sigaction and friends. Can you re-try with the
trunk, or with the upcoming 3.12.0 release?
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=355803
--- Comment #8 from Julian Seward ---
Frank, ping me when this hits the mainline kernel. Then we can take
the patch in V.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=352767
--- Comment #3 from Julian Seward ---
(In reply to austinengl...@gmail.com from comment #2)
> Not currently, but I took a quick look. There are several more syscalls that
> wine uses in the source that are bsd/osx specific, but I can't
https://bugs.kde.org/show_bug.cgi?id=366079
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=356112
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=369723
--- Comment #2 from Julian Seward ---
(In reply to chh from comment #0)
> Suggested fix, to add VG_MINIMAL_SETJMP and VG_MINIMAL_LONGJMP for
> VGP_arm64_linux:
> [..patch follows..]
Thank you for looking into this. This looks like a good so
https://bugs.kde.org/show_bug.cgi?id=360571
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=368120
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=368823
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=360571
--- Comment #11 from Julian Seward ---
Committed on trunk, r16073.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=365327
--- Comment #5 from Julian Seward ---
(In reply to Rhys Kidd from comment #4)
> Preliminary support added in r15976.
Merged to 3_12_BRANCH in r16071.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=352197
--- Comment #4 from Julian Seward ---
Petar: Duncan: the patch fixes only the mips32 case. Is the mips64 path
correct, or does that also need to be fixed?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=370398
Julian Seward changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=370398
--- Comment #1 from Julian Seward ---
The code is as intended. Compare with line 1688 (a few lines up) and you'll
see why it is written how it is.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=370028
--- Comment #9 from Julian Seward ---
This feels to me like hiding misalignment problems. I'd prefer to remove
misaligned
accesses where possible. Building with --enable-usban at least makes it
possible
to see, on any platform, where the run
https://bugs.kde.org/show_bug.cgi?id=369439
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=369854
--- Comment #2 from Julian Seward ---
What version of Valgrind are you using here?
Can you re-run with the extra flag --partial-loads-ok=yes ?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=360571
--- Comment #7 from Julian Seward ---
Created attachment 101476
--> https://bugs.kde.org/attachment.cgi?id=101476&action=edit
Proposed fix (lacks documentation, but seems to work)
For example, to keep the test program (next attachment
https://bugs.kde.org/show_bug.cgi?id=360571
--- Comment #9 from Julian Seward ---
Anton, can you perhaps try this on aarch64 ? Would this work for you?
(Apologies .. there's one line in the test program you'll have to change.)
--
You are receiving this mail because:
You are watchi
https://bugs.kde.org/show_bug.cgi?id=360571
--- Comment #8 from Julian Seward ---
Created attachment 101477
--> https://bugs.kde.org/attachment.cgi?id=101477&action=edit
A simple test program.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=354274
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #3 from Julian Seward ---
Andrew, do you know which implementation this is? eg is it a Cortex
A-something,
or something else?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=369175
--- Comment #24 from Julian Seward ---
(In reply to Ulrich Weigand from comment #23)
> However, adding calls to fnptr_to_fnentry at a high level likewise seems
> wrong, since once you've done that, you've forgotten where the function
https://bugs.kde.org/show_bug.cgi?id=369175
--- Comment #22 from Julian Seward ---
Looking for helper calls in the the whole of guest_ppc_toIR.c, by searching for
the
string "mkIRExprVec_", I found the following non-wrapped uses of function
pointers. They should all be
https://bugs.kde.org/show_bug.cgi?id=369175
--- Comment #5 from Julian Seward ---
Still can't repro it, but with a test case for this insn, the two calls look
like
this:
IR and virtual-registerised code:
-- t127 =
1Sto32(32to1(64to32(And64(is_BCDstring128_helper{0x38174610}(0x1:I64,t117
https://bugs.kde.org/show_bug.cgi?id=357932
--- Comment #5 from Julian Seward ---
Mark, I think the patch is OK. In these insns we have, redundantly:
REX.W=1, which says that this insn is 64-bits wide w.r.t. how it interacts
with the integer register set, which is irrelevant because it doesn
https://bugs.kde.org/show_bug.cgi?id=367995
--- Comment #16 from Julian Seward ---
Philippe, thank you for looking at this. And Ruurd, for your patience.
> The overhead is only incurred by custom allocators using the auto-free
> feature,
> not by any existing applications or alloca
https://bugs.kde.org/show_bug.cgi?id=369175
--- Comment #4 from Julian Seward ---
Comment 3 assumes that the block that segfaults is the same one where
the (we assume) mis-translation occurred. It might be that some previous
block was mis-translated and causes the simulated machine state to be
https://bugs.kde.org/show_bug.cgi?id=369175
--- Comment #3 from Julian Seward ---
This kind of thing could well be due to incorrect register allocation around
the calls, perhaps corrupting the values passed to the calls or corrupting
values in registers around the call site, that both caller
https://bugs.kde.org/show_bug.cgi?id=361253
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=361253
Julian Seward changed:
What|Removed |Added
CC||ar...@linux.vnet.ibm.com
https://bugs.kde.org/show_bug.cgi?id=366413
Julian Seward changed:
What|Removed |Added
CC||ar...@linux.vnet.ibm.com
https://bugs.kde.org/show_bug.cgi?id=365327
--- Comment #3 from Julian Seward ---
The patches look OK to me. Only one nit:
--- coregrind/m_syswrap/syswrap-amd64-darwin.c(revision 15949)
+++ coregrind/m_syswrap/syswrap-amd64-darwin.c(working copy)
+# elif DARWIN_VERS == DARWIN_10_9
https://bugs.kde.org/show_bug.cgi?id=351692
Julian Seward changed:
What|Removed |Added
CC||mips3...@gmail.com
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=362953
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=367995
--- Comment #9 from Julian Seward ---
Ivo, thank you for reviewing this; Ruurd, thank you for addressing
Ivo's comments.
I looked at the revised patch. I am generally a bit nervous about
mempool changes given that they are not much used and I a
https://bugs.kde.org/show_bug.cgi?id=355197
Julian Seward changed:
What|Removed |Added
CC||philippe.waroquiers@skynet
https://bugs.kde.org/show_bug.cgi?id=355231
--- Comment #3 from Julian Seward ---
I think we might be talking at cross purposes. Sure, the silicon supports
VMOVDQU
(and other AVX insns) in both 32- and 64-bit modes. What I meant is, Valgrind
doesn't; 32-bit support doesn't extend be
https://bugs.kde.org/show_bug.cgi?id=357059
--- Comment #3 from Julian Seward ---
If I had to guess, I would say that the Sept 2015 Intel docs are wrong,
and that this instruction (cvtpi2ps) should behave the same way as
cvtpi2pd does -- that is, a transition to MMX state happens only if
the
https://bugs.kde.org/show_bug.cgi?id=357059
--- Comment #2 from Julian Seward ---
I'm not sure your test program is correct. The tag word is 16 bits
at byte offsets 8 and 9, but the program tests fenv[9] and [10].
That said .. even after changing the 9 and 10 to 8 and 9, it still
https://bugs.kde.org/show_bug.cgi?id=358856
Julian Seward changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=355231
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=357673
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=362934
--- Comment #1 from Julian Seward ---
What CPU/SOC is this? Do you know if it is NEON capable?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=356823
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=339596
--- Comment #21 from Julian Seward ---
*** Bug 356138 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=356138
Julian Seward changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=356392
Julian Seward changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=356392
--- Comment #2 from Julian Seward ---
Oh, you mean the "Zero Divide" flag that is bit 2 of %fpscr.
The simulation for FP is somewhat approximate and in particular only
%fpscr.{C0,C1,C2,C3,TOP} are simulated. So in your case it's not g
https://bugs.kde.org/show_bug.cgi?id=354931
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=356392
--- Comment #1 from Julian Seward ---
I'm a bit confused by this. My Intel docs (Nov 2015) say:
FPU Flags Affected
C1 Set to 0 if stack underflow occurred.
Set if result was rounded up; cleared otherwise.
C0, C2, C3 Undefined.
https://bugs.kde.org/show_bug.cgi?id=352549
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=368791
--- Comment #3 from Julian Seward ---
Hmm, we should pull those wrappers about of being mips64-linux specific
bucket and make them linux-general instead. Also it looks like they are
missing
a PRE_MEM_RASCIIZ call on the path arguments, assuming it
https://bugs.kde.org/show_bug.cgi?id=368791
--- Comment #4 from Julian Seward ---
s/about of being/out of the
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=322935
--- Comment #30 from Julian Seward ---
(In reply to Peter Maydell from comment #29)
> The way QEMU's JIT handles this kind of thing [..]
Thanks for the explanation. I was indeed wondering how QEMU handled this.
Yes .. if I could redo the b
https://bugs.kde.org/show_bug.cgi?id=368507
--- Comment #3 from Julian Seward ---
The primary_map array, I mean. I didn't mean the whole 128GB needs to be
zeroed out at startup.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=368507
--- Comment #2 from Julian Seward ---
In the trunk right now we have N_PRIMARY_BITS = 20, which according to the svn
log makes the maximum usable memory amount be 64G. That was done at end-Jan
2013 and should surely be in 3.10 and later.
Maybe we
https://bugs.kde.org/show_bug.cgi?id=368419
--- Comment #2 from Julian Seward ---
Keno, thank you for the patch. It looks OK, apart from this fragment
+ case VKI_PERF_EVENT_IOC_SET_FILTER: {
+ char *filter = (char *)ARG3;
+ PRE_MEM_READ("ioctl(VKI_PERF_EVENT_IOC_SET_F
https://bugs.kde.org/show_bug.cgi?id=367995
Julian Seward changed:
What|Removed |Added
CC||jsew...@acm.org
--- Comment #3 from Julian
https://bugs.kde.org/show_bug.cgi?id=367543
--- Comment #1 from Julian Seward ---
The Intel documentation has changed, it seems. The Nov 2007 docs say
(about BT)
The CF flag contains the value of the selected bit.
The OF, SF, ZF, AF, and PF flags are undefined.
The Jan 2015 docs say
https://bugs.kde.org/show_bug.cgi?id=366817
--- Comment #1 from Julian Seward ---
Do you have a suggested patch that we could look at? That would be helpful.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=322935
Julian Seward changed:
What|Removed |Added
CC||noloa...@gmail.com
--- Comment #28 from Julian
https://bugs.kde.org/show_bug.cgi?id=366464
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=322935
--- Comment #27 from Julian Seward ---
This keeps cropping up, for example most recently in bug 366464. Maybe
I should explain more why this isn't supported. It's because we don't have
a feasible way to do it. Valgrind's JIT ins
https://bugs.kde.org/show_bug.cgi?id=366345
--- Comment #3 from Julian Seward ---
With the trunk, gcc-5.3 -O3 (note, default trunk settings are -O2), on
amd64-linux,
I get only one warning:
m_aspacemgr/aspacemgr-linux.c: In function ‘vgPlain_am_munmap_valgrind’:
m_aspacemgr/aspacemgr-linux.c
https://bugs.kde.org/show_bug.cgi?id=366237
Julian Seward changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=366142
Julian Seward changed:
What|Removed |Added
Resolution|--- |UNMAINTAINED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=368412
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=366079
--- Comment #7 from Julian Seward ---
Petar, is it possible you could test/land the follow-on patches in
comment 5 and comment 6?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=366035
--- Comment #12 from Julian Seward ---
Philippe, is there anything we can or should do here?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=364948
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|CONFIRMED
701 - 800 of 900 matches
Mail list logo