[lldb-dev] Host::GetArchitecture and the default target triple

[Greg Clayton]

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...


> On Aug 19, 2014, at 2:24 PM, Zachary Turner <zturner at google.com> 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!
> 
> 
> On Tue, Aug 19, 2014 at 2:18 PM, <jingham at apple.com> wrote:
> Sorry, I didn't read closely enough.  Greg's answer is actually relevant to your question...
> 
> Jim
> 
> > On Aug 19, 2014, at 2:04 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > 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?
> >
> >
> > On Tue, Aug 19, 2014 at 1:58 PM, <jingham at apple.com> wrote:
> > 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
> >
> > > On Aug 19, 2014, at 1:52 PM, Zachary Turner <zturner at google.com> wrote:
> > >
> > > 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 at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> >
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev