Re: [lldb-dev] Minimum required swig version?

[Davidino Italiano via lldb-dev]

> On Apr 16, 2020, at 3:08 PM, Jonas Devlieghere  wrote:
> 
> 
> 
> On Thu, Apr 16, 2020 at 2:42 PM Davidino Italiano via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> 
>> On Apr 16, 2020, at 2:28 PM, Ted Woodward via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> http://lldb.llvm.org/resources/build.html 
>>  Says we need swig 2 or later:
>> If you want to run the test suite, you’ll need to build LLDB with Python 
>> scripting support.
>> 
>> · Python 
>> · SWIG  2 or later.
>>  
>> I don’t think this is correct anymore.
>>  
>> test/API/python_api/sbenvironment/TestSBEnvironment.py has this line:
>> env.Set("FOO", "bar", overwrite=True)
>>  
>> lldb built with swig 2.0.11 fails this test with the error:
>> env.Set("FOO", "bar", overwrite=True)
>> TypeError: Set() got an unexpected keyword argument 'overwrite'
>>  
>> It works when lldb is built with swig 3.0.8.
>>  
> 
> Yes, we bumped the swig requirements.
> Swig-2, among others, don’t support python 3 correctly.
> 
> I think you're confusing SWIG 1.x and SWIG 2.x. We bumped the requirements to 
> 2, because that's the first version that correctly supported Python 3. 
> Personally I don't mind bumping the version again, but this seems more like a 
> bug that we should be able to fix with SWIG 2. 
>  


While swig 2 has support for python 3, it doesn’t work in all cases (there are 
bugs). Hence the choice of the word “correctly”, rather than “at all”.
If you go past this, you’ll probably find other problems, as I did when I 
originally made the transition. Some of them are trivial, some of them cause 
the python code generate to be incorrect and tests to fail.
If you want to fix them, be my guest. But realistically everybody I’ve seen 
builds using swig-3 [or swig-4]. Pick your poison.

—
Davide___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Minimum required swig version?

[Jonas Devlieghere via lldb-dev]

On Thu, Apr 16, 2020 at 2:42 PM Davidino Italiano via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
>
> On Apr 16, 2020, at 2:28 PM, Ted Woodward via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> http://lldb.llvm.org/resources/build.html Says we need swig 2 or later:
>
> If you want to run the test suite, you’ll need to build LLDB with Python
> scripting support.
> · Python 
> · SWIG  2 or later.
>
> I don’t think this is correct anymore.
>
> test/API/python_api/sbenvironment/TestSBEnvironment.py has this line:
> env.Set("FOO", "bar", overwrite=True)
>
> lldb built with swig 2.0.11 fails this test with the error:
> env.Set("FOO", "bar", overwrite=True)
> TypeError: Set() got an unexpected keyword argument 'overwrite'
>
> It works when lldb is built with swig 3.0.8.
>
>
>
> Yes, we bumped the swig requirements.
> Swig-2, among others, don’t support python 3 correctly.
>

I think you're confusing SWIG 1.x and SWIG 2.x. We bumped the requirements
to 2, because that's the first version that correctly supported Python 3.
Personally I don't mind bumping the version again, but this seems more like
a bug that we should be able to fix with SWIG 2.


>
> Feel free to submit a patch.
>
> —
> D
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Minimum required swig version?

[Davidino Italiano via lldb-dev]

> On Apr 16, 2020, at 2:28 PM, Ted Woodward via lldb-dev 
>  wrote:
> 
> http://lldb.llvm.org/resources/build.html 
>  Says we need swig 2 or later:
> If you want to run the test suite, you’ll need to build LLDB with Python 
> scripting support.
> 
> · Python 
> · SWIG  2 or later.
>  
> I don’t think this is correct anymore.
>  
> test/API/python_api/sbenvironment/TestSBEnvironment.py has this line:
> env.Set("FOO", "bar", overwrite=True)
>  
> lldb built with swig 2.0.11 fails this test with the error:
> env.Set("FOO", "bar", overwrite=True)
> TypeError: Set() got an unexpected keyword argument 'overwrite'
>  
> It works when lldb is built with swig 3.0.8.
>  

Yes, we bumped the swig requirements.
Swig-2, among others, don’t support python 3 correctly.

Feel free to submit a patch.

—
D___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Minimum required swig version?

[Ted Woodward via lldb-dev]

http://lldb.llvm.org/resources/build.html Says we need swig 2 or later:

If you want to run the test suite, you'll need to build LLDB with Python 
scripting support.
* Python
* SWIG 2 or later.

I don't think this is correct anymore.

test/API/python_api/sbenvironment/TestSBEnvironment.py has this line:
env.Set("FOO", "bar", overwrite=True)

lldb built with swig 2.0.11 fails this test with the error:
env.Set("FOO", "bar", overwrite=True)
TypeError: Set() got an unexpected keyword argument 'overwrite'

It works when lldb is built with swig 3.0.8.

inspect.getsource(lldb.SBEnvironment) gives the following:
swig 2.0.11:
  """Set(SBEnvironment self, char const * name, char const * value, bool 
overwrite) -> bool"""\nreturn _lldb.SBEnvironment_Set(self, *args)\n\n
swig 3.0.8:
"""Set(SBEnvironment self, char const * name, char const * value, bool 
overwrite) -> bool"""\nreturn _lldb.SBEnvironment_Set(self, name, 
value, overwrite)\n\n\n

Is swig 3 required? Do we need to update the build page?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB problems on remote debugging

[Ted Woodward via lldb-dev]

Hi Rui,

What you describe is almost identical to what we do with the Hexagon simulator.

There are 2 ways to launch your program - “run” (process launch) and gdb-remote 
(an attach).

“run” will require some plumbing to launch your simulator the same way that 
lldb-server/debugserver is launched. That’s fairly involved, so I’m going to 
skip it for now.


For the attach case, you run your simulator, with the program on the command 
line. Then in a separate shell you launch lldb with the program, and run the 
gdb-remote command to connect to it. You’ve got this already, from your message 
below.

When you attach to the simulator, it comes up stopped, probably at the 
entrypoint, but that’s dependent on your simulator. To continue, issue a 
“continue” command. You’ll probably want to set a breakpoint first!

To answer your questions:

  1.  There is no “load” command, but if you make a platform for your target 
you can add one. Existing platforms (like the remote Linux platform) have the 
capability to send the binary to the remote server and tell it to run. For 
Hexagon we don’t do that; instead when we “run” we build a hexagon-sim command 
line that tells the simulator to load the program. If you’re launching the 
simulator separately for the attach case it’s easiest to include the binary on 
the simulator command line.
  2.  No, “gdb-remote” only makes the RSP connection.
  3.  That depends on your simulator. It looks like it just does an attach, and 
you’ll need to do the continue manually. That’s probably best, because lldb 
expects the remote gdbserver to be stopped when you connect to it.
  4.  No, but it’s probably easiest.

Ted

From: lldb-dev  On Behalf Of Rui Hong via 
lldb-dev
Sent: Thursday, April 16, 2020 4:31 AM
To: lldb-dev 
Subject: [EXT] [lldb-dev] LLDB problems on remote debugging

Hi LLDB devs,

I'm working on porting LLDB to work with an existing simulator(which has GDB 
stub, remote debugging). This simulator used to work with GDB. When using with 
GDB, the target file(ELF) is loaded by GDB command "load" or "remote put".
>From a LLVM talk project which is very similar to my project, their target 
>file is loaded by the simulator itself(   ./sim a.out   , something like 
>that), and lldb sets breakpoint, use "gdb-remote" command to connect to the 
>simulator, the program starts to run immediately and stop at the breakpoint.
I can't find any lldb command that is equal to "load" in GDB. And right now 
when I use "gdb-remote" to connect lldb to my simulator, lldb has command line 
output "Process 10115 stopped，thread #1, stop reason = signal SIGTRAP，frame #0: 
0x". Does this mean the program has already started to run? I 
haven't loaded the binary.

To sum my questions:
1. Does lldb has similar command like "load/remote put" in GDB?
2. Does "gdb-remote" command in lldb do the "loading binary" job?
3. Will the program start to run immediately after "gdb-remote" command in lldb?
4. Do I have to let my simulator to load the binary by itself?

Kind regards,
Rui

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB problems on remote debugging

[Rui Hong via lldb-dev]

Hi LLDB devs,

I'm working on porting LLDB to work with an existing simulator(which has GDB 
stub, remote debugging). This simulator used to work with GDB. When using with 
GDB, the target file(ELF) is loaded by GDB command "load" or "remote put".
From a LLVM talk project which is very similar to my project, their target file 
is loaded by the simulator itself( ./sim a.out , 
something like that), and lldb sets breakpoint, use "gdb-remote" command to 
connect to the simulator, the program starts to run immediately and stop at the 
breakpoint.
I can't find any lldb command that is equal to "load" in GDB. And right now 
when I use "gdb-remote" to connect lldb to my simulator, lldb has command line 
output "Process 10115 stopped??thread #1, stop reason = signal SIGTRAP??frame 
#0: 0x". Does this mean the program has already started to run? 
I haven't loaded the binary.


To sum my questions:
1. Does lldb has similar command like "load/remote put" in GDB?
2. Does "gdb-remote" command in lldb do the "loading binary" job?
3. Will the program start to run immediately after "gdb-remote" command in lldb?
4. Do I have to let my simulator to load the binary by itself?



Kind regards,
Rui___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev