Looks fine to me.

I'm happy to commit this for you.

I am happy to commit this for you since you have addressed the concerns raised by Sean.

Looks good to me, assuming that Tamas is happy also.

Its currently present in the official 2.7.10 windows x64 python distro from python.org.

If there are no objections, are you happy to accept this?

Hi Oleksiy,

This patch trys to address the issues raised by Tamas. Arm symbols will now also be added to the m_address_class_map too.

In D10062#179997, @tberghammer wrote:

In D10062#179982, @ADodds wrote:

In D10062#179593, @tberghammer wrote:

You have to add an entry to the m_address_class_map for arm symbols also because with the current change all address treated as thumb when you don't have mapping symbols.

P.S.: Next time please upload the diff with full context

Perhaps I have misunderstood your concern, but the symbol is only marked as eAddressClassCodeAlternateISA if it is THUMB since that happense inside:

if (symbol_type == eSymbolTypeCode && symbol.st_value & 1)

Are you suggesting that I need to add an 'else' to this check and mark it as eAddressClassCode? I can see that would make sense.

Yes, you have to add an entry for arm symbols also because of the way m_address_class_map is used (see ObjectFileELF::GetAddressClass). Basically an entry means that all address have the specified type until the next entry (ordered by address). The reason behind this layout is that you can query the address class of any address without have to resolve it to a symbol it belongs to.

In D10062#179593, @tberghammer wrote:

You have to add an entry to the m_address_class_map for arm symbols also because with the current change all address treated as thumb when you don't have mapping symbols.

P.S.: Next time please upload the diff with full context

Closed by commit r236486 on 05/05/2015.

Hi greg,

Hi Greg,

Hi Greg,
I forgot to remove two changes which accidentally made it threw in this patch. Could you please ignore the changes to PlatformWindows.cpp involving the software breakpoint opcode, and the change to GDBRemoteCommunicationClient.cpp which was committed this morning.
Sorry for the confusion.

Hi greg, I have pushed the loading code back inside of ProcessGDB remote as you suggested.
I wasnt quite following your suggestion regarding SetExecutable in the PosixDYLD, could you elaborate more on that please.

Thanks again Greg.

Thanks for having a look at my previous patch Greg. I have made a revision that hopefully addresses all the points you had raised earlier. Any other C&C is welcome.

This change adds support for gdbserver running on android Arm. It also fixes a bug where register discovery would bomb out if the osabi name wasnt given in target.xml. I have moved gdbserver register discovery inside of BuildDynamicRegisterInfo() so it will only be used when registers dont already exist (as intended).

Thanks for the insightful feedback and for commiting this change Zachary.

I have reworked my initial patch with the feedback from Zachary.
I have tested this patch on both x86 and x64 windows builds and successfully build lldb on both.

Selectively including .cpp files in CMake may be harder then it first looks since the LLVM cmake automaticaly throw an error when it finds unincluded .cpp files.
When I tried to bypass RegisterContextWindows_x86.cpp for x64 targets I get the following error:

Thanks very much for committing that Zachary.

Thanks for taking a look at this.
I had an idea that the correct fix may be just what you have mentioned.
I will revise this patch to bypass this file for x64 builds as you advise.

I have revised the patch after review by Zachary.

I should have added that I cloned from the git mirror at the following
revisions:

Hi Zachary,