[Bug 20755] New: llgs: RSP qProcessInfo should return triple on Linux, not cputype/cpusubtype.

Bug ID 20755
Summary llgs: RSP qProcessInfo should return triple on Linux, not cputype/cpusubtype.
Product lldb
Version unspecified
Hardware PC
OS Linux
Status NEW
Severity normal
Priority P
Component All Bugs
Assignee lldb-dev@cs.uiuc.edu
Reporter tfiala@google.com
Classification Unclassified

1. Fix GDBRemoteCommunicationServer to send a triple instead of
cputype/cpusubtype when llgs is running on non-__APPLE__.

2. Modify GDBRemoteCommunicationClient::GetCurrentProcessInfo () to accept a
triple and adjust ArchSpec appropriately when provided.

This will fix an issue where llgs is mis-interpreting the remote process exe
triple.

Todd Fiala changed bug 20755

Hi Todd,

Will it still be possible that some non-Apple stuff (e.g. kalimba) can extract a subtype field (from say qProcessInfo or qHostInfo)? I'll need this to support kalimba architecture variants at some stage. (Bear in mind that CSR don't use share GDBRemoteCommunicationServer, only GDBRemoteCommunicationClient.

thanks,
Matt

Hey Matthew,

Right now the code is setup to either generate the architecture based on cputype/cpusubtype (which IIRC map directly to xnu/Mach values) and build the ArchSpec from that + other details, OR to use the triple to generate the ArchSpecs. The cputype/cpusubtype are really geared toward the darwin side of the house.

However, there is no reason why you couldn’t use those fields aside from the caveat above. Care will just need to be taken to ensure the ArchSpec based on parsing these works correctly, and (probably) some of the Apple-specific setup paths may need to be guarded with OS checks if you want different behavior than what darwin is doing.

Feel free to send up snippets of code you’re considering. I’ve had to debug through quite a bit of code around these areas lately as I get llgs running for local debugging. (This bug needed to be resolved as part of that effort).

Hi Todd,

Ok, I'll let you know what I'll need when I get to "how to support kalimba variant recognition from gdb-remote".

As you may have seen from

"r216541 - Add support for kalimba architecture variants 3, 4 and 5."

I've already added recognition of kal variants from ELF parse.

cheers
Matt

Todd Fiala wrote: