Strange x86_64 RegisterContext behaviour

I'm puzzled by a few uses of amd64 vs. 386 register contexts.

In POSIXThread::GetRegisterName (and a few other places in that file) it reads the host architecture in order to decide what kind of context to create. Is this right? Surely it should be using the target's architecture instead?

And in RegisterContext_x86_64::ConvertRegisterKindToRegisterNumber, it switches based on the target's architecture. But surely the target's architecture _has_ to be eCore_x86_64_x86_64, otherwise we wouldn't have created a 64-bit register context?

Please let me know if I'm just misunderstanding how it should work :slight_smile:

We use the host arch to determine which register context to create because that's the way ptrace behaves -- if ptrace is called from a 64-bit application (LLDB) it fills a 64-bit register structure regardless of the architecture of the inferior. LLDB internally then converts this to 32-bit regs as needed based on the target arch. At least that's my understanding...

That's not to say there might not be a better way to do this; I believe there was a thread about this topic not too long ago.

Cheers,
Dan

Ok thanks, that makes sense (well, kinda).

Malea, Daniel wrote:

I'm puzzled by a few uses of amd64 vs. 386 register contexts.

In POSIXThread::GetRegisterName (and a few other places in that file) it reads the host architecture in order to decide what kind of context to create. Is this right? Surely it should be using the target's architecture instead?

Yes, when we support remote targets, then we'll have to use the target's architecture. Currently, the i386 register context is just a stub. As Daniel mentioned below, ptrace deals with a 64-bit register set, and i386 applications use register halves. We've tested with an i386 target using the x86-64 build of LLDB. Cheers,

- Ashok