[lldb-dev] FW: Problems selecting correct Platform
Ted Woodward
ted.woodward at codeaurora.org
Thu Mar 26 10:20:59 PDT 2015
I’m seeing the same issue. On the server side, I get:
Launched '/local/scratch/ted/plat/bin/lldb-server' as process 1986...
Some tests are running fine; some are failing in this manner.
--
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: Thursday, March 26, 2015 11:58 AM
To: Ted Woodward; lldb-dev at cs.uiuc.edu
Subject: Re: FW: [lldb-dev] Problems selecting correct Platform
+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 <mailto: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 <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 <mailto: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 <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 <mailto: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> [mailto: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 <mailto:lldb-dev at cs.uiuc.edu>
Subject: Re: [lldb-dev] Problems selecting correct Platform
> -----Original Message-----
> From: Greg Clayton [mailto:gclayton at apple.com <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 <mailto: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 <mailto:lldb-dev at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
--
Vince Harron |
Technical Lead Manager |
vharron at google.com <mailto:vharron at google.com> |
858-442-0868 <tel:858-442-0868>
--
Vince Harron |
Technical Lead Manager |
vharron at google.com <mailto:vharron at google.com> |
858-442-0868
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150326/aaacc466/attachment.html>
More information about the lldb-dev
mailing list