This assumes that the environment is always Thumb
Change by Walter Erquinigo <email@example.com>
sas on Oct 25 2017, 6:23 PM.Authored by
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 each symbol is the right thing to do.
As for the GetAddressClass function, I have another diff that does exactly what you are talking about. I'll upload it when this one goes in.
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 can analyze the symbols and ensure correctness is the only way to do it?
Do you guys not have access to Windows Desktops? It sounds like we need to get remote debugging of Windows targets working. I don't think I'm gonna be the one to do that in the near future, but if it's going to be a frequent thing that you're improving windows support for remote targets like Windows Phone, I imagine you're going to want the code to be tested, so hopefully you can convince someone to give you cycles to make remote debugging work properly, otherwise you're shipping untested code :-/
Well as far as I can tell, remote debugging for Windows does work, assuming you use ds2 on the remote, and that you have a few of our local patches (which I'm trying to send upstream currently). Remote Windows debugging is the only way we debug on Windows for now and the testing we have is just a combination of people using our tools internally as well as some end-to-end tests we run internally with full debug session setup + breakpoints + execution control, etc, with a remote session.
Given that this works for us, I'm gonna have a hard time justifying assigning people to bringing up windows remote debugging in lldb without ds2, and that leaves me in a state where testing stuff in lldb is hard/impossible for now.
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 least YOU are sure it works. Some coverage is better than nothing. Is something like this possible?
So there are two ways we test our stuff.
First part is centered around ds2 testing, and you can see it here: https://travis-ci.org/facebook/ds2/builds/292216534. We build ds2 for a bunch of different targets, and for some of them, we run dotest.py with LLDB_DEBUGSERVER_PATH=/path/to/ds2. This gives us a lot of coverage for non-Windows targets.
For Windows targets, we can only build ds2 (see https://ci.appveyor.com/project/a20012251/ds2/branch/master) and we are unable to run tests because we need a binary of lldb for Windows, but the builds available on http://releases.llvm.org/ were historically broken, and when @fjricci tried to fix them it didn't lead anywhere IIRC.
The second way we have to test our debugging tools is to simply run our debugging scripts with a known target, internally. That doesn't use dotest.py. It simply launches lldb and ds2, tries to set breakpoints, control the execution of the process, etc. The changes I am currently sending upstream work with that type of internal testing, but that's of no use for you because you can't run it yourself, nor can you see the results of our runs. :/