sas added a comment.
Friendly ping.
https://reviews.llvm.org/D39315
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
sas added a subscriber: fjricci.
sas added a comment.
In https://reviews.llvm.org/D39315#908284, @zturner wrote:
> So when you're using ds2 as the remote, are you still using the normal lldb
> test suite? `dotest.py`? If so, then we could have a test decorator that
> says `@expectedFailure(no
clayborg added a comment.
The test suite can be run remotely if ds2 supports the "lldb-server platform"
packets. I'll be happy to help you get this going Stephane. Ping me internally
if interested.
https://reviews.llvm.org/D39315
___
lldb-commits
zturner added a comment.
So when you're using ds2 as the remote, are you still using the normal lldb
test suite? `dotest.py`? If so, then we could have a test decorator that says
`@expectedFailure(not(debugserver=ds2))` or something. Then, even though
you're the only one that can run it, at
sas added a comment.
In https://reviews.llvm.org/D39315#908251, @zturner wrote:
> In https://reviews.llvm.org/D39315#908246, @sas wrote:
>
> > Same thing here, I have no idea how to go about testing something specific
> > like this. Given that this is Windows Phone, it's even worse than simply
davide added a comment.
In https://reviews.llvm.org/D39315#908246, @sas wrote:
> Same thing here, I have no idea how to go about testing something specific
> like this. Given that this is Windows Phone, it's even worse than simply
> Windows Desktop because the only way to test is by doing remot
zturner added a comment.
In https://reviews.llvm.org/D39315#908246, @sas wrote:
> Same thing here, I have no idea how to go about testing something specific
> like this. Given that this is Windows Phone, it's even worse than simply
> Windows Desktop because the only way to test is by doing remo
sas added a comment.
Same thing here, I have no idea how to go about testing something specific like
this. Given that this is Windows Phone, it's even worse than simply Windows
Desktop because the only way to test is by doing remote debugging. I suppose
checking in binaries to the tree so we ca
sas added a comment.
@clayborg: the follow-up to this change is in https://reviews.llvm.org/D39337,
where we implement `GetAddressClass()`.
https://reviews.llvm.org/D39315
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.
sas updated this revision to Diff 120447.
sas added a comment.
Address comments by @clayborg.
https://reviews.llvm.org/D39315
Files:
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
Index: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
===
davide requested changes to this revision.
davide added a comment.
This change should be unit-testable, no?
https://reviews.llvm.org/D39315
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
ok, just move the ARM detection out of the loop and use a
THUMB_ADDRESS_BIT_MASK for ARM symbols and this is good to go.
https://reviews.llvm.org/D39315
_
sas requested review of this revision.
sas added a comment.
I saw the `bool is_arm = ` pattern only in `ObjectFileMachO.cpp`. I'm not sure
about the specifics for Darwin targets, but having an object file with some
functions in ARM and some functions in Thumb is valid, so I think checking for
e
clayborg requested changes to this revision.
clayborg added inline comments.
This revision now requires changes to proceed.
Comment at: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp:651-659
+ ArchSpec header_arch;
+ GetArchitecture(header_arch);
+
sas created this revision.
Herald added subscribers: kristof.beyls, aemerson.
This assumes that the environment is always Thumb
Change by Walter Erquinigo
https://reviews.llvm.org/D39315
Files:
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
Index: source/Plugins/ObjectFile/PECOFF/O
15 matches
Mail list logo
