Commit Graph

5 Commits

Author SHA1 Message Date
Pavel Labath f92756e9ec Reapply "Make Scalar::GetValue more consistent"
this is a resubmission of r280476. The problem with the original commit was that it was printing
out all numbers as signed, which was wrong for unsigned numbers with the MSB set. Fix that and
add a unit test covering that case.

llvm-svn: 280480
2016-09-02 10:58:52 +00:00
Pavel Labath e6ece918e9 Revert "Make Scalar::GetValue more consistent"
This reverts commit r280476 as it breaks several tests on i386. I was fixing an 32-bit
breakage, and I did not run the 32-bit test suite before submitting, oops.

llvm-svn: 280478
2016-09-02 09:52:18 +00:00
Pavel Labath 21159ee681 Make Scalar::GetValue more consistent
Summary:
It seems the original intention of the function was printing signed values in decimal format, and
unsigned values in hex (without the leading "0x"). However, signed and unsigned long were
exchanged, which lead to amusing test failures in TestMemoryFind.py.

Instead of just switching the two, I think we should just print everything in decimal here, as
the current behaviour is very confusing (especially when one does not request printing of types).
Nothing seems to depend on this behaviour except and we already have a way for the user to
request the format he wants when printing values for most commands (which presumably does not go
through this function).

I also add a unit tests for the function in question.

Reviewers: clayborg, granata.enrico

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D24126

llvm-svn: 280476
2016-09-02 09:25:36 +00:00
Pavel Labath cce9a609fb XFail TestMemoryFind on 32-bit architectures
the test fails for a very prosaic reason: `(const char *)0x1000` returns "4096" on x86_64 and
"1000" (without the "0x") on i386. I haven't tried other 32-bit arches, but I am guessing the
behaviour is the same. XFAIL until someone can get a chance to look at this.

llvm-svn: 280344
2016-09-01 09:17:37 +00:00
Enrico Granata 7eef5fa147 Change "memory find" over to using a variation of the Boyer–Moore search algorithm
Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally)

llvm-svn: 280327
2016-09-01 00:09:59 +00:00