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=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=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 watching all bug ch
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) happy:
./vg
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=369439
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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-time misa
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=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=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=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=368823
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=360571
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 solution to
m
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=366079
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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 easily test.
> Sh
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=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 beca
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=351282
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=352197
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=357932
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=368419
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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 I
https://bugs.kde.org/show_bug.cgi?id=351632
Julian Seward changed:
What|Removed |Added
CC||jsew...@acm.org
--- Comment #4 from Julian Sewa
https://bugs.kde.org/show_bug.cgi?id=357734
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=357928
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=358620
--- Comment #3 from Julian Seward ---
This is with 3.7.0, which is really old now. Can you try again with 3.11.0 or
better
with the current SVN trunk?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=359524
--- Comment #1 from Julian Seward ---
What you're seeing is the result of a kludge, in which btq for a register
operand
is implemented by pushing the argument on the (guest) stack temporarily,
and then executing the same IR as for btq with a memory oper
https://bugs.kde.org/show_bug.cgi?id=359524
--- Comment #2 from Julian Seward ---
Honestly .. do you think any large program would actually run properly on
Valgrind
if these instructions had really been misimplemented?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=359524
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=359767
Julian Seward changed:
What|Removed |Added
Status|CLOSED |RESOLVED
--
You are receiving this mail becaus
https://bugs.kde.org/show_bug.cgi?id=359950
--- Comment #5 from Julian Seward ---
(In reply to Tom Hughes from comment #3)
> Although I'm not clear if that is what has happened here (and this should
> only happen when not running under valgrind) that's not actually true with
> x87 because if the
https://bugs.kde.org/show_bug.cgi?id=361615
--- Comment #2 from Julian Seward ---
Do you have a small test case which demonstrates that Valgrind's behaviour at
present, differs from when the program is run "natively" ? I'd be happier
about
this if you have something directly that demonstrates th
https://bugs.kde.org/show_bug.cgi?id=362935
--- Comment #1 from Julian Seward ---
valgrind: m_transtab.c:2459 (vgPlain_init_tt_tc): Assertion 'sizeof(TTEntryC)
<= 88' failed
was a temporary problem; I am sure it has now been fixed.
--
You are receiving this mail because:
You are watching all bu
https://bugs.kde.org/show_bug.cgi?id=364435
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=360425
Julian Seward changed:
What|Removed |Added
CC||jh...@codeaurora.org
--- Comment #8 from Julian
https://bugs.kde.org/show_bug.cgi?id=359950
--- Comment #7 from Julian Seward ---
(In reply to Tom Hughes from comment #6)
> Note that I didn't mean spills/reloads that valgrind's internal
> implementation does, but rather any spills/reloads that the original
> compiler generated.
Yes -- that's
https://bugs.kde.org/show_bug.cgi?id=351726
--- Comment #1 from Julian Seward ---
I can't reproduce this on the trunk with the test program before, and I can't
find any commit in the past 4 years which might have fixed such a bug. So
I am mystified. Which version of valgrind was this?
int main
https://bugs.kde.org/show_bug.cgi?id=364948
--- Comment #3 from Julian Seward ---
(In reply to Carl Love from comment #2)
> expected output files are rather large, total size is 33MBytes.
33 MB is pretty large. That space will be in the distro tarballs for ever more
and also on the SVN server.
https://bugs.kde.org/show_bug.cgi?id=364948
--- Comment #4 from Julian Seward ---
(In reply to Carl Love from comment #1)
> Created attachment 99775 [details]
> Patch 5 of 5 to add VEX support for Power ISA 3.0 instructions
I have a number of concerns here, but nothing that can't be relatively
e
https://bugs.kde.org/show_bug.cgi?id=357338
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=360378
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=359838
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=359952
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=351491
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=351726
Julian Seward changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=356138
--- Comment #3 from Julian Seward ---
Is possibly
bextr $0x1000606,%edx,%edx
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=360415
--- Comment #2 from Julian Seward ---
jacobly.alt, what context (library, use case, etc) do these instructions appear
in?
I am surprised they don't get complained-about more.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=356715
--- Comment #1 from Julian Seward ---
c4 e2 7d 13 04 4avcvtph2ps (%rdx,%rcx,2),%ymm0
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=357932
--- Comment #1 from Julian Seward ---
f2 49 0f 5d 00 rex.WB minsd (%r8),%xmm0
f2 49 0f 5f 00 rex.WB maxsd (%r8),%xmm0
I'm sure these insns are handled really. It's just the redundant rex.WB prefix
that is causing them not to get de
https://bugs.kde.org/show_bug.cgi?id=362935
--- Comment #4 from Julian Seward ---
Err, sorry for the stupid bug. That value needs to be 96 on arm-linux, not 88.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=362935
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=353727
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=353384
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=366344
--- Comment #2 from Julian Seward ---
Try using the trunk. That supports all the crypto instructions in 64-bit mode.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=366344
--- Comment #3 from Julian Seward ---
Ah, sorry, I failed to read comment 1.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=366345
--- Comment #2 from Julian Seward ---
What version of gcc is this?
Do you get these warnings if you don't set CFLAGS yourself? We've played with
the
flags from time to time over the years, but mostly you can't crank much more
performance out of it by
https://bugs.kde.org/show_bug.cgi?id=360574
--- Comment #1 from Julian Seward ---
Anton: I don't have an easily available arm64-android device to test on. But I
think this is an easy fix. If I get you a patch, can you test it for me?
--
You are receiving this mail because:
You are watching a
https://bugs.kde.org/show_bug.cgi?id=360571
--- Comment #1 from Julian Seward ---
(In reply to Anton Kirilov from comment #0)
> The assembly language code that is emitted by ART at the beginning of each
> method, and that causes the warning, looks like this:
>
> sub r12, sp, #8192
> ldr.w r12,
https://bugs.kde.org/show_bug.cgi?id=357673
--- Comment #1 from Julian Seward ---
This was a bug caused by incorrectly accepting a 32 bit v8 crypto instruction
when it was not in fact supported. The invalid-IR failure was fixed in vex
r3233.
Implementation of 32 bit v8 crypto instructions is cur
https://bugs.kde.org/show_bug.cgi?id=360574
--- Comment #3 from Julian Seward ---
The problem is that the wrappers for android-specific ioctls on 64-bit ARM
are not enabled, so it handles them using the generic ioctl logic, which
in this case isn't appropriate. Can you try this patch?
Index: c
https://bugs.kde.org/show_bug.cgi?id=366344
--- Comment #4 from Julian Seward ---
(In reply to Jeffrey Walton from comment #1)
> It looks like 3.12-SVN is missing the some of the instructions for the CRC32
> checks:
> ARM64 front end: data_processing_register
> disInstr(arm64): unhandled instruc
https://bugs.kde.org/show_bug.cgi?id=360574
--- Comment #5 from Julian Seward ---
Fixed, valgrind r15923. Thanks for the test.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=360574
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=366344
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=366464
--- Comment #1 from Julian Seward ---
Can you use objdump -d to find out what instruction that actually is?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=360571
--- Comment #3 from Julian Seward ---
(In reply to Anton Kirilov from comment #0)
> Currently, the workaround that I have been using is manually patching the
> Valgrind source code (in particular, the VG_GCC296_BUG_STACK_SLOP constant
> in memcheck/mc_e
https://bugs.kde.org/show_bug.cgi?id=360571
--- Comment #5 from Julian Seward ---
(In reply to Anton Kirilov from comment #4)
> Just a quick idea - do you think it is worth it supporting more than one
> range (e.g. for running code generated by a compiler that misbehaves in the
> same way as GCC
https://bugs.kde.org/show_bug.cgi?id=364948
--- Comment #9 from Julian Seward ---
Thanks for the changes. Both patches look OK to me. Land.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=352364
--- Comment #2 from Julian Seward ---
Some more analysis:
typedef
struct { unsigned char c; int i; void *foo;
} S;
int main (int argc, char **argv) {
S x;
S *s = &x;
s->c = 1;
if (s->c == 0 && s->i == 205 && s->foo == s) return 1;
re
https://bugs.kde.org/show_bug.cgi?id=352364
--- Comment #3 from Julian Seward ---
In this example, "cmpld ; bne" translates to essentially this
// the cmpld
t54 = 64to8(CmpORD64U(t48,0xCD:I64))
// the bne
if (CmpEQ32(Xor32(And32(8Uto32(t54),0x2:I32),0x2:I32),0x0:I32))
{ PUT(12
https://bugs.kde.org/show_bug.cgi?id=330617
--- Comment #8 from Julian Seward ---
Properly fixing bug 352364 (https://bugs.kde.org/show_bug.cgi?id=352364)
will go a long way to fixing this one too. They are not exact duplicates,
though.
--
You are receiving this mail because:
You are watching
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 and
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
c
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 allocators.
In th
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't
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,t118):
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 wrapped in fnptr_to_fnentr
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
> descriptor was an
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=371065
Julian Seward changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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 consideration, I thin
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>
9864:
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 of ABA
cas
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=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 are watching all bug
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 i
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:
You ar
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 on a CPU with a
> d
https://bugs.kde.org/show_bug.cgi?id=339596
--- Comment #20 from Julian Seward ---
(In reply to Mark Wielaard from comment #18)
> Here are some testcases for the FMA4 instructions.
Excellent.
> I haven't looked yet at the XOP instructions.
> Maybe it is an idea to do FMA4 and XOP as separate pa
https://bugs.kde.org/show_bug.cgi?id=352767
--- Comment #1 from Julian Seward ---
Austin, do you have a patch for this? Or for bug 348616 ?
--
You are receiving this mail because:
You are watching all bug changes.
1 - 100 of 191 matches
Mail list logo
