[lldb-dev] [Bug 36997] New: lit: unable to parse tools/lldb/lit/lit.cfg
https://bugs.llvm.org/show_bug.cgi?id=36997 Bug ID: 36997 Summary: lit: unable to parse tools/lldb/lit/lit.cfg Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: matthias.krue...@famsik.de CC: llvm-b...@lists.llvm.org Hi, I'm trying to run a "check-all" but lit crashes due to broken lldb lit config: [ 90%/10/1/11,17.496] Running all regression tests llvm-lit: /home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/utils/lit/lit/llvm/config.py:334: note: using clang: /home/matthias/LLVM/LLVM_dev/stage_3_tests/objects/bin/clang llvm-lit: /home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/utils/lit/lit/llvm/config.py:334: note: using clang: /home/matthias/LLVM/LLVM_dev/stage_3_tests/objects/bin/clang llvm-lit: /home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/utils/lit/lit/TestingConfig.py:101: fatal: unable to parse config file '/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/tools/lldb/lit/lit.cfg', traceback: Traceback (most recent call last): File "/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/utils/lit/lit/TestingConfig.py", line 88, in load_from_path exec(compile(data, path, 'exec'), cfg_globals, None) File "/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/tools/lldb/lit/lit.cfg", line 125, in if re.match(r'icc', config.cc): File "/usr/lib/python2.7/re.py", line 141, in match return _compile(pattern, flags).match(string) TypeError: expected string or buffer FAILED: CMakeFiles/check-all I have python 2.7.14 installed (also regex module 2018.02.21-1) This is my build script: https://github.com/matthiaskrgr/llvm_bootstrap/blob/master/build_git.sh#L361 -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 36997] lit: unable to parse tools/lldb/lit/lit.cfg
https://bugs.llvm.org/show_bug.cgi?id=36997 lab...@google.com changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |lab...@google.com -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Can I call a python script from LLDB c++ code?
The easiest solution may be turn your python script into a full-fledged
forwarder (instead of just a port-number-finder). Then, from lldb's point
of view it would just be launching a debugserver (that happens to be
implemented in python) and communicating with it. And all the forwarding
magic would happen inside your script.
pl
On Wed, 4 Apr 2018 at 00:30, Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Responses inline
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
> > -Original Message-
> > From: Greg Clayton [mailto:clayb...@gmail.com]
> > Sent: Tuesday, April 03, 2018 5:19 PM
> > To: Ted Woodward
> > Cc: lldb-dev@lists.llvm.org
> > Subject: Re: [lldb-dev] Can I call a python script from LLDB c++ code?
> >
> >
> >
> > > On Apr 3, 2018, at 12:18 PM, Ted Woodward via lldb-dev > d...@lists.llvm.org> wrote:
> > >
> > > LLDB for Hexagon can automatically launch and connect to the Hexagon
> > > simulator, much like LLDB can launch and connect to debugserver/lldb-
> > server.
> > > I've got a copy of GDBRemoteCommunication::StartDebugserverProcess
> > > that does this. A copy because there are feature incompatibilities
> > > between hexagon-sim and debugserver/lldb-server.
> > >
> > > On a hardware target, our OS has a debug stub. We'd like to run the
> > > lldb test suite talking to this stub on the simulator, instead of
> > > talking to the RSP interface the simulator publishes. We have a module
> > > that will forward ports to the OS under simulation, but to do this I
> need to:
> > > 1) open an http connection to port x
> > > 2) parse some xml coming back that contains the actual port for the
> > > stub I want to connect to
> > > 3) connect to the new port
> >
> >
> > Can't you forward ports in advance and then run lldb-server in platform
> mode
> > and tell it to use only those ports? Then lldb-server will do everything
> it needs.
> > There is a port offset option to lldb-server that can be used in case the
> lldb-
> > server that runs on the simulator returns say port , but it needs to
> have
> > 1 added to it...
>
> Short answer - no. It's a custom stub, not lldb-server, but that's not the
> issue.
> The issue is that the mechanism to get data into the simulation mimics what
> we do on
> hardware, where the DSP doesn't have access to the outside world, and
> everything
> goes through an Android app. The system publishes 1 port per process that
> the stub
> controls. These ports are picked randomly, and are set up when the http
> connection
> is made. The data that is read over that connection needs to be parsed to
> find the
> ports that the stub is publishing.
>
> > > I have a python script that will do this, but I need to do it inside
> > > LLDB
> > > c++ code in GDBRemoteCommunication.cpp, so when I do a "run" it will
> > > c++ jump
> > > through the correct hoops and connect to the stub under simulation.
> > >
> > > Is there a good way to call a python script from LLDB c++ code and get
> > > a result back? Or is there a better solution?
> > >
> >
> > The the main question is can you run lldb-server in the simulator and
> have
> the
> > test suite just work? What is stopping you from being able to do that if
> the
> > answer is no?
>
> I've got the test suite working using the simulator's RSP interface, but
> the
> next step
> is to exercise the OS stub. And to get to it I have to jump through the
> hoops I talked
> about earlier.
>
> > It sounds like a real hack if you have to run a python script in
> > ProcessGDBRemote. It sounds like you need to just modify your hexagon
> > simulator platform code to "do the right thing".
>
> "Do the right thing" in this case involves opening an http connection,
> parsing XML,
> and telling LLDB to connect to the port I get from the XML. The launch is
> done inside
> Process::Launch, which is called from the platform, so I can't do any
> processing
> In the platform.
>
> Worst case I could do something like 'system("python sim_stub_connect.py")'
> to get the port
> that's being published, if using LLDB's interpreter is not a good idea.
>
> > > Ted
> > >
> > > --
> > > 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@lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Can I call a python script from LLDB c++ code?
> On Apr 3, 2018, at 4:30 PM, Ted Woodward wrote:
>
> Responses inline
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>> -Original Message-
>> From: Greg Clayton [mailto:clayb...@gmail.com]
>> Sent: Tuesday, April 03, 2018 5:19 PM
>> To: Ted Woodward
>> Cc: lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] Can I call a python script from LLDB c++ code?
>>
>>
>>
>>> On Apr 3, 2018, at 12:18 PM, Ted Woodward via lldb-dev > d...@lists.llvm.org> wrote:
>>>
>>> LLDB for Hexagon can automatically launch and connect to the Hexagon
>>> simulator, much like LLDB can launch and connect to debugserver/lldb-
>> server.
>>> I've got a copy of GDBRemoteCommunication::StartDebugserverProcess
>>> that does this. A copy because there are feature incompatibilities
>>> between hexagon-sim and debugserver/lldb-server.
>>>
>>> On a hardware target, our OS has a debug stub. We'd like to run the
>>> lldb test suite talking to this stub on the simulator, instead of
>>> talking to the RSP interface the simulator publishes. We have a module
>>> that will forward ports to the OS under simulation, but to do this I
> need to:
>>> 1) open an http connection to port x
>>> 2) parse some xml coming back that contains the actual port for the
>>> stub I want to connect to
>>> 3) connect to the new port
>>
>>
>> Can't you forward ports in advance and then run lldb-server in platform
> mode
>> and tell it to use only those ports? Then lldb-server will do everything
> it needs.
>> There is a port offset option to lldb-server that can be used in case the
> lldb-
>> server that runs on the simulator returns say port , but it needs to
> have
>> 1 added to it...
>
> Short answer - no. It's a custom stub, not lldb-server, but that's not the
> issue.
> The issue is that the mechanism to get data into the simulation mimics what
> we do on
> hardware, where the DSP doesn't have access to the outside world, and
> everything
> goes through an Android app. The system publishes 1 port per process that
> the stub
> controls. These ports are picked randomly, and are set up when the http
> connection
> is made. The data that is read over that connection needs to be parsed to
> find the
> ports that the stub is publishing.
>
>>> I have a python script that will do this, but I need to do it inside
>>> LLDB
>>> c++ code in GDBRemoteCommunication.cpp, so when I do a "run" it will
>>> c++ jump
>>> through the correct hoops and connect to the stub under simulation.
>>>
>>> Is there a good way to call a python script from LLDB c++ code and get
>>> a result back? Or is there a better solution?
>>>
>>
>> The the main question is can you run lldb-server in the simulator and have
> the
>> test suite just work? What is stopping you from being able to do that if
> the
>> answer is no?
>
> I've got the test suite working using the simulator's RSP interface, but the
> next step
> is to exercise the OS stub. And to get to it I have to jump through the
> hoops I talked
> about earlier.
>
>> It sounds like a real hack if you have to run a python script in
>> ProcessGDBRemote. It sounds like you need to just modify your hexagon
>> simulator platform code to "do the right thing".
>
> "Do the right thing" in this case involves opening an http connection,
> parsing XML,
> and telling LLDB to connect to the port I get from the XML. The launch is
> done inside
> Process::Launch, which is called from the platform, so I can't do any
> processing
> In the platform.
>
> Worst case I could do something like 'system("python sim_stub_connect.py")'
> to get the port
> that's being published, if using LLDB's interpreter is not a good idea.
The other way would be to modify your platform code for hexagon such that when
you do:
(lldb) platform select hexagon-simulator
(lldb) platform connect
(lldb) file a.out
(lldb) run
It will defer to your platform. Do I understand correctly that you have two
ways to launch? One that works with the RSP, but you also want to sometimes
connect the OS stub? If so, then I would recommend you modify the to
"platform connect" so you can store the information about which type of
connection this is and "do the right thing" in the platform code that starts a
debug session where you open the http connection, and follow the other steps
you must do. Am I missing something?
Greg
>
>>> Ted
>>>
>>> --
>>> 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@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
___
lldb-dev mailing list
lldb-dev@lists.
