Host::GetArchitecture and the default target triple

Looking over the apple code path for Host::GetArchitecture, I’m a little confused about why all this custom logic is needed. What are the situations in which llvm::sys::getDefaultTargetTriple() will return something other than what we want? Specifically, a concrete example might help illustrate the problem.

I understand from the comment that it has something to do with being able to run 32 and 64-bit executables in the same operating system. Isn’t this the case everywhere? I can run 32-bit executables on Windows x64 as well. llvm::Triple has a function called get32BitArchVariant() that I thought returns a 32-bit triple for this case. Does this not work for some Apple configuration?

It seems like this logic should be able to be sunk into llvm::Triple somehow. Conceptually speaking, it seems like there should be two cases:

64-bit:
host_arch_64 = llvm::Triple::getDefaultTargetTriple()
host_arch_32 = llvm::Triple::getDefaultTargetTriple().get32BitArchVariant()

32-bit
host_arch_64 =
host_arch_32 = llvm::Triple::getDefaultTargetTriple()

Why doesn’t this work?

Mac OS X is more complex because lldb also supports apps running in the iOS simulator on OS X. Those apps are x86 or x86_64 processes, but their OS is "ios", not "darwin". The platforms and a bunch of other fiddly bits rely on getting the OS right as well.

Jim

I am not sure if this would work. At Apple we can have either:

x86_64h-apple-macosx or x86_64-apple-macosx for 64 bit enabled machines. Not sure which llvm::Triple::getDefaultTargetTriple() returns. I highly doubt it detects x86_64h, though I could be wrong.

i386-apple-macosx for 32 bit.

I am happy to switch over if llvm::Triple::getDefaultTargetTriple() properly detects x86_64h on Haswell enabled macs. I will let others comment on their systems (FreeBSD, linux, windows, MingGW).

In this case though, we’re talking about Host::GetArchitecture, which is a static function and is supposed to report information about the OS that the debugger is running on, and not the target that the debuggee is running on. Does this mean that a single instance of LLDB cannot debug both an app running in the simulator, and an app running in darwin? So you have to exit LLDB and start a new instance of LLDB in “simulator mode” or “mac mode”? Or am I misunderstanding?

Sorry, I didn't read closely enough. Greg's answer is actually relevant to your question...

Jim

Ok. So it looks like x86_64h is not currently supported by llvm::Triple. I will find out about adding support for it. If it’s possible to get that into llvm::Triple, I’ll post a patch that updates Host::GetArchitecture() to use it, and then maybe one of you guys can test it in the various configurations.

Thanks!

You would need to verify with the llvm/clang folks if x86_64h is desired as the result of getDefaultTargetTriple() first. I am not sure they want that. The debugger really wants to know what the hardware currently supports and that might not be the same as what the default triple should be...

Hi Zachary,

I'm not sure whether what I'm going to say is relevant to your current quest, but I can see that you're doing a lot of refactoring, and that you mentioned the Triple stuff. It took me sometime to get CSRs Kalimba processors vaguely debuggable using lldb. A lot of my struggle was in the Triple/ArchSpec area... I thought just mention that our kalimbas run bare-metal (no OS) so when you any refactoring, please be sure that the UnknownOS cases still work!

Apologies if my post is dreadfully off-target, but when the word triple was mentioned, I thought that I should pipe up.

thanks
Matt

Zachary Turner wrote:

Ok. So it looks like x86_64h is not currently supported by llvm::Triple. I will find out about adding support for it. If it's possible to get that into llvm::Triple, I'll post a patch that updates Host::GetArchitecture() to use it, and then maybe one of you guys can test it in the various configurations.

Thanks!

    Sorry, I didn't read closely enough. Greg's answer is actually
    relevant to your question...

    Jim

    >
    > In this case though, we're talking about Host::GetArchitecture,
    which is a static function and is supposed to report information
    about the OS that the debugger is running on, and not the target
    that the debuggee is running on. Does this mean that a single
    instance of LLDB cannot debug both an app running in the
    simulator, and an app running in darwin? So you have to exit LLDB
    and start a new instance of LLDB in "simulator mode" or "mac
    mode"? Or am I misunderstanding?
    >
    > Mac OS X is more complex because lldb also supports apps running
    in the iOS simulator on OS X. Those apps are x86 or x86_64
    processes, but their OS is "ios", not "darwin". The platforms and
    a bunch of other fiddly bits rely on getting the OS right as well.
    >
    > Jim
    >
    > >
    > > Looking over the apple code path for Host::GetArchitecture,
    I'm a little confused about why all this custom logic is needed. What are the situations in which
    llvm::sys::getDefaultTargetTriple() will return something other
    than what we want? Specifically, a concrete example might help
    illustrate the problem.
    > >
    > > I understand from the comment that it has something to do with
    being able to run 32 and 64-bit executables in the same operating
    system. Isn't this the case everywhere? I can run 32-bit
    executables on Windows x64 as well. llvm::Triple has a function
    called get32BitArchVariant() that I thought returns a 32-bit
    triple for this case. Does this not work for some Apple
    configuration?
    > >
    > > It seems like this logic should be able to be sunk into
    llvm::Triple somehow. Conceptually speaking, it seems like there
    should be two cases:
    > >
    > > 64-bit:
    > > host_arch_64 = llvm::Triple::getDefaultTargetTriple()
    > > host_arch_32 =
    llvm::Triple::getDefaultTargetTriple().get32BitArchVariant()
    > >
    > > 32-bit
    > > host_arch_64 = <empty>
    > > host_arch_32 = llvm::Triple::getDefaultTargetTriple()
    > >
    > > Why doesn't this work?
    > > _______________________________________________
    > > lldb-dev mailing list
    > > lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu>
    > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
    >

To report this email as spam click here <https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==>.

_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.