[lldb-dev] FW: Problems selecting correct Platform
Vince Harron
vharron at google.com
Thu Mar 26 09:57:32 PDT 2015
+lldb-dev
I've just tried running the Linux remote tests again and I hit some
problems.
"connect to debug monitor on port NNN failed"
We will look into it soon.
We've never tried it on Ubuntu 12.04 AFAIK. One problem with 12.04 could
be causing all of those failures.
Sincerely,
Vince
On Thu, Mar 26, 2015 at 7:41 AM, Ted Woodward <ted.woodward at codeaurora.org>
wrote:
> Hi Vince,
>
>
>
> I build top of tree from a couple days ago on Ubuntu 12, then ran the
> tests normally and got 4 failures. I ran the remote tests using the
> instructions below, and got 65 failures out of 360 tests, with lldb-server
> in platform mode on another Ubuntu 12 machine.
>
>
>
> I’m trying to establish a baseline before making my changes; are that many
> failures expected?
>
>
>
> Ted
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* Vince Harron [mailto:vharron at google.com]
> *Sent:* Tuesday, March 24, 2015 12:54 PM
>
> *To:* Ted Woodward
> *Subject:* Re: FW: [lldb-dev] Problems selecting correct Platform
>
>
>
> It's been on my todo list for a long time to document this. I've made
> some edits in this email, please email if you hit any problems.
>
>
>
> (We run cmake ../../llvm ... in "$TARGETIP/build/host" folder)
>
>
>
> host1$ TARGETIP=192.168.100.132
>
> host1$ cd $ROOT_DIR/build/host
>
> host1$ rsync -hav bin/lldb-server* $TARGETIP:host/bin/
>
> host1$ rsync -havL lib/python2.7 $TARGETIP:host/lib/
>
> host2$ $ROOT_DIR/build/bin/lldb-server platform --listen *:5432
> --stay-alive -c "log enable -f /tmp/plat.log gdb-remote all"
>
>
>
> host1$ cd $ROOT_DIR/llvm/tools/lldb/test
>
> host1$ DOTEST_OPTS="--executable $ROOT_DIR/build/host/bin/lldb -A x86_64
> -C clang-3.5 -s $ROOT_DIR/build/host/lldb-test-traces -u CXXFLAGS -u CFLAGS"
>
> (these next lines are what enable remote test suite)
>
> host1$ export LLDB_TEST_THREADS=1
>
> host1$ export DOTEST_OPTS="$DOTEST_OPTS --platform-name remote-linux
> --platform-url connect://$TARGETIP:5432 --platform-working-dir /tmp"
>
> host1$ ./dosep.py --options "$DOTEST_OPTS"
>
>
>
>
>
>
>
> On Tue, Mar 24, 2015 at 9:52 AM, Ted Woodward <ted.woodward at codeaurora.org>
> wrote:
>
> I want to run linux->remote linux test; how do I do that?
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* Vince Harron [mailto:vharron at google.com]
> *Sent:* Monday, March 23, 2015 6:00 PM
> *To:* Ted Woodward
> *Subject:* Re: FW: [lldb-dev] Problems selecting correct Platform
>
>
>
> Hi Ted,
>
> I'm going to be busy with non-LLDB stuff this week. So I won't have time
> to give this question the attention it deserves.
>
> If you make this change and we can still run the tests suite cleanly
> Linux->remote/local Linux, I think it's fine. But I reserve the right to
> complain later. :)
>
> On Mar 23, 2015 3:46 PM, "Ted Woodward" <ted.woodward at codeaurora.org>
> wrote:
>
>
> Hi Vince,
>
> I'm trying to get LLDB on Windows to load a Linux binary and choose the
> remote Linux Platform, but r226712, which gets the remote-linux platform
> able to run processes, is causing some trouble.
>
> Specifically, the call to debugger.GetTargetList().CreateTarget() was
> changed to call the version of CreateTarget() that takes an ArchSpec
> instead
> of a triple. The version that takes the triple will go through all the
> platforms looking for one that matches the triple, then call the version
> that takes an ArchSpec. The version that takes an ArchSpec will only use
> the
> current platform.
>
> I'd like to change this back to the original implementation; would that be
> a
> problem?
>
> Ted
>
> -----Original Message-----
> From: lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu]
> On
> Behalf Of Ted Woodward
> Sent: Thursday, March 19, 2015 5:53 PM
> To: 'Greg Clayton'; 'Vince Harron'
> Cc: lldb-dev at cs.uiuc.edu
> Subject: Re: [lldb-dev] Problems selecting correct Platform
>
>
>
>
> > -----Original Message-----
> > From: Greg Clayton [mailto:gclayton at apple.com]
> > Sent: Thursday, March 19, 2015 4:45 PM
> >
> > > On Mar 19, 2015, at 12:15 PM, Ted Woodward
> > <ted.woodward at codeaurora.org> wrote:
> > >
> > > I've got a Hexagon platform, that launches the Hexagon simulator and
> > > is used for standalone development. Now I'm working on supporting
> > > Hexagon Linux, but it's not choosing the Linux platform, instead
> > > it's choosing the Hexagon platform.
> > >
> > > I want LLDB to use the Hexagon Platform if my executable's triple is
> > > "hexagon-unknown-elf" (which is really hexagon-unknown-unknown) and
> > > use the Linux platform if my executable's triple is
> "hexagon-unknown-linux".
> > >
> > >
> > > First problem:
> > > "target create" doesn't search platforms for one matching the
> > > executable's triple. It used to, but when TargetList::CreateTarget
> > > was switched to call CreateTargetInternal, "target create" was
> > > changed to call the method that takes an ArchSpec instead of a
> > > triple. This method doesn't search for a compatible Platform, but
> > > instead chooses the
> > current Platform.
> > >
> > > Is this intended behavior?
> >
> > No. Sounds like you have an old snapshot of LLDB. The current one was
> recently
> > fixed to search for the platform with revision 216115.
>
> I've got 216115. My snapshot includes up to 227289 from 1/27/15. We're
> trying to get better about staying closer to top-of-tree, but it's
> something
> we're not good enough at yet.
>
> 226712 from 1/21/15 changed how "target create" called CreateTarget() in
> TargetList.cpp. Before that rev, it called the CreateTarget() that took a
> triple, but after that rev it calls the CreateTarget() that takes an
> ArchSpec. These 2 methods do different things; the triple one calls the
> (internal) ArchSpec one at the end. One thing that is missing in the one
> that takes an ArchSpec is the chunk of code that searches for a valid
> platform for the specified architecture:
>
> else if (platform_arch.IsValid())
> {
> // if "arch" isn't valid, yet "platform_arch" is, it means we
> have an executable file with
> // a single architecture which should be used
> ArchSpec fixed_platform_arch;
> if (!platform_sp->IsCompatibleArchitecture(platform_arch,
> false,
> &fixed_platform_arch))
> {
> platform_sp =
> Platform::GetPlatformForArchitecture(platform_arch, &fixed_platform_arch);
> if (platform_sp)
>
> debugger.GetPlatformList().SetSelectedPlatform(platform_sp);
> }
> }
>
> That code is not currently called by a "target create".
>
> Vince, would changing the CreateTarget() call in CommandObjectTarget.cpp
> back to the pre-226712 call break the remote-linux platform run process
> fix?
>
> > > Second problem:
> > > I change DoExecute() in CommandObjectTarget.cpp to call the ArchSpec
> > > version if the ArchSpec is valid, and the triple version if it is not.
> > > This has LLDB going through platforms to find a match, but there's
> > > another problem when it gets to PlatformLinux.
> > > PlatformLinux::GetSupportedArchitectureAtIndex() will only return
> > > host
> > architectures.
> >
> > This is a bug and should be fixed with code below...
> >
> > > So in my case, running on Windows, it returns x86_64-pc-windows-msvc
> > > or i386-pc-windows-msvc. Neither is a match for Linux.
> > >
> > > Shouldn't the Linux platform match anything with a triple *-*-linux?
> > > Or does the platform not matter if I'm just going to use gdb-remote
> > > to connect to gdbserver or LLGS on a remote Hexagon Linux board?
>
> I added the code below to PlatformLinux.cpp and now my Windows LLDB
> correctly selects the remote-linux platform for Hexagon Linux. Thanks!
>
> > So a platform can say what architectures it supports. This is how we
> > match architectures up to a binary that is supplied. Each platform
> > should give
> an
> > exhaustive list of the architectures they support.
> >
> > The current code is:
> >
> > bool
> > PlatformLinux::GetSupportedArchitectureAtIndex (uint32_t idx, ArchSpec
> > &arch) {
> > if (idx == 0)
> > {
> > arch = HostInfo::GetArchitecture(HostInfo::eArchKindDefault);
> > return arch.IsValid();
> > }
> > else if (idx == 1)
> > {
> > // If the default host architecture is 64-bit, look for a
> > 32-bit
> variant
> > ArchSpec hostArch =
> > HostInfo::GetArchitecture(HostInfo::eArchKindDefault);
> > if (hostArch.IsValid() && hostArch.GetTriple().isArch64Bit())
> > {
> > arch = HostInfo::GetArchitecture(HostInfo::eArchKind32);
> > return arch.IsValid();
> > }
> > }
> > return false;
> > }
> >
> >
> > This is only correct if Platform::IsHost() returns true. Otherwise
> > linux
> will need
> > to say all architectures that is supports:
> >
> >
> > x86_64-*-linux
> > i386-*-linux
> > arm*-*-linux
> > aarch64-*-linux
> > mips64-*linux
> >
> > The "*" above for the vendor should be set an an "unspecified
> > unknown". So
> the
> > code should be:
> >
> > bool
> > PlatformLinux::GetSupportedArchitectureAtIndex (uint32_t idx, ArchSpec
> > &arch) {
> > if (IsHost())
> > {
> > if (idx == 0)
> > {
> > arch = HostInfo::GetArchitecture(HostInfo::eArchKindDefault);
> > return arch.IsValid();
> > }
> > else if (idx == 1)
> > {
> > // If the default host architecture is 64-bit, look for a
> 32-bit variant
> > ArchSpec hostArch =
> > HostInfo::GetArchitecture(HostInfo::eArchKindDefault);
> > if (hostArch.IsValid() && hostArch.GetTriple().isArch64Bit())
> > {
> > arch = HostInfo::GetArchitecture(HostInfo::eArchKind32);
> > return arch.IsValid();
> > }
> > }
> > }
> > else
> > {
> > llvm::Triple triple;
> > // Set the OS to linux
> > triple.setOS(llvm::Triple::Linux);
> > // Set the architecture
> > switch (idx)
> > {
> > case 0: arch.setArchName("x86_64"); break;
> > case 1: arch.setArchName("i386"); break;
> > case 2: arch.setArchName("arm"); break;
> > case 3: arch.setArchName("aarch64"); break;
> > case 4: arch.setArchName("mips64"); break;
> > case 5: arch.setArchName("hexagon"); break;
> > default: return false;
> > }
> > // Leave the vendor as "llvm::Triple:UnknownVendor" and don't
> specify
> > the vendor by
> > // calling triple.SetVendorName("unknown") so that it is a
> "unspecified
> > unknown".
> > // This means when someone calls triple.GetVendorName() it will
> > return an empty string
> > // which indicates that the vendor can be set when two
> architectures are
> > merged
> >
> > // Now set the triple into "arch" and return true
> > arch.SetTriple(triple);
> > return true;
> > }
> > return false;
> > }
> >
> > Then things should work a bit better for you.
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
>
>
>
> --
>
>
>
> Vince Harron |
>
> Technical Lead Manager |
>
> vharron at google.com |
>
> 858-442-0868
>
>
>
--
Vince Harron | Technical Lead Manager | vharron at google.com | 858-442-0868
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150326/46169f5f/attachment.html>
More information about the lldb-dev
mailing list