lldb support

lldb support

[Perry E. Metzger]

Was a final decision ever made about lldb support for gud mode? (No, I
don't want to open up an argument, I just want to know if it was
settled. I recognize this is potentially contentious and would
appreciate the shortest possible factual answer.)

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: lldb support

[Stefan Monnier]

> Was a final decision ever made about lldb support for gud mode?

I had taken the decision to accept such support code.  But that code was
never submitted, and instead it was even removed from the LLVM
repository, IIRC.


        Stefan

Re: lldb support

[Perry E. Metzger]

On Mon, 07 Nov 2016 15:20:14 -0500 Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> > Was a final decision ever made about lldb support for gud mode?  
> 
> I had taken the decision to accept such support code.  But that
> code was never submitted, and instead it was even removed from the
> LLVM repository, IIRC.

But if new code was written, it would be accepted then.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: lldb support

[Stefan Monnier]

>> > Was a final decision ever made about lldb support for gud mode?  
>> I had taken the decision to accept such support code.  But that
>> code was never submitted, and instead it was even removed from the
>> LLVM repository, IIRC.
> But if new code was written, it would be accepted then.

It would have been accepted when I was maintainer.
I don't know what is John and Eli's opinion on this.


        Stefan

Re: lldb support

[John Wiegley]

>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> > Was a final decision ever made about lldb support for gud mode? I had
>>> taken the decision to accept such support code. But that code was never
>>> submitted, and instead it was even removed from the LLVM repository, IIRC.
>> But if new code was written, it would be accepted then.

SM> It would have been accepted when I was maintainer.
SM> I don't know what is John and Eli's opinion on this.

I would love to accept lldb support, especially since I'd like to use it.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: lldb support

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But if new code was written, it would be accepted then.

Would you please remind me what lldb does?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: lldb support

[Daniel Colascione]

On 11/08/2016 04:54 PM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > But if new code was written, it would be accepted then.
>
> Would you please remind me what lldb does?
>

LLDB is GDB with an evil goatee.

It's a debugger that does the same job as GDB, but it's based on the 
Clang and LLVM toolkit for looking at the world, not binutils, GCC, etc. 
Compared to GDB, LLDB has a different and (IMHO) uglier command syntax, 
but both LLDB and GDB support the MI protocol.

Re: lldb support

[John Wiegley]

>>>>> "RS" == Richard Stallman <rms@gnu.org> writes:

RS> Would you please remind me what lldb does?

It's what gdb is/does, but from the clang/llvm project. Very similar
interface, and use cases.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: lldb support

[Perry E. Metzger]

On Tue, 08 Nov 2016 19:54:16 -0500 Richard Stallman <rms@gnu.org>
wrote:
>   > But if new code was written, it would be accepted then.  
> 
> Would you please remind me what lldb does?
> 

It is a free debugger. The controversy was that you felt it competed
with gdb. However, gud has support for proprietary debuggers, so it
seems unfortunate not to be supporting a free one, if a non-GNU one.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: lldb support

[Eli Zaretskii]

> From: Daniel Colascione <dancol@dancol.org>
> Date: Tue, 8 Nov 2016 17:17:04 -0800
> Cc: emacs-devel@gnu.org
> 
> but both LLDB and GDB support the MI protocol.

If LLDB supports the MI protocol, why does it need special support
code?  It should be able to use gdb-mi.el without any changes, no?

Re: lldb support

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It is a free debugger. The controversy was that you felt it competed
  > with gdb.

Could you please tell me roughly when we discussed it?  I would like
to look up that previous discussion.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: lldb support

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It's a debugger that does the same job as GDB, but it's based on the 
  > Clang and LLVM toolkit for looking at the world, not binutils, GCC, etc. 
  > Compared to GDB, LLDB has a different and (IMHO) uglier command syntax, 
  > but both LLDB and GDB support the MI protocol.

Why would we want to support it
rather than saying, "We support GDB -- use that."?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: lldb support

[Daniel Colascione]

On 11/09/2016 04:24 PM, Richard Stallman wrote:
>   > It's a debugger that does the same job as GDB, but it's based on the
>   > Clang and LLVM toolkit for looking at the world, not binutils, GCC, etc.
>   > Compared to GDB, LLDB has a different and (IMHO) uglier command syntax,
>   > but both LLDB and GDB support the MI protocol.
>
> Why would we want to support it
> rather than saying, "We support GDB -- use that."?

All the usual reasons people prefer tool A over tool B: compatibility 
with a specific environment, personal customizations, familiarity, and 
personal preference. LLDB is free software. We should support it.

Re: lldb support

[John Mastro]

Richard Stallman <rms@gnu.org> wrote:
> Could you please tell me roughly when we discussed it?  I would like
> to look up that previous discussion.

It was in early-mid February 2015. The subject was "Contributing
LLVM.org patches to gud.el". The messages are available on the web here:

https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00274.html
https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00656.html

I hope that Emacs will ultimately integrate support for LLDB (assuming
someone writes it).

        John

Re: lldb support

[Perry E. Metzger]

On Wed, 09 Nov 2016 19:24:11 -0500 Richard Stallman <rms@gnu.org>
wrote:
>   > It's a debugger that does the same job as GDB, but it's based
>   > on the Clang and LLVM toolkit for looking at the world, not
>   > binutils, GCC, etc. Compared to GDB, LLDB has a different and
>   > (IMHO) uglier command syntax, but both LLDB and GDB support the
>   > MI protocol.  
> 
> Why would we want to support it
> rather than saying, "We support GDB -- use that."?

Because there are platforms that do not ship with gdb.
macOS for example ships with lldb these days. lldb is also the
debugger of choice for a bunch of languages like Swift that have no
gdb support. (The reference Swift implementation is free
software.) I'm not sure if Rust only is supported by lldb but I think
that may be the case, I would have to check.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: lldb support

[Perry E. Metzger]

On Wed, 09 Nov 2016 19:24:11 -0500 Richard Stallman <rms@gnu.org>
wrote:
> Why would we want to support it
> rather than saying, "We support GDB -- use that."?

Oh, and in addition to the fact that there are things like languages
that lldb supports that gdb does not, that there are people who
prefer it for whatever reason, and that it is shipped with some
platforms that gdb is not shipped by default on:

gud mode supports completely unfree debuggers. lldb is free software.
It seems like bad policy to encourage the use of non-free tools by
supporting them better than free tools.


Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: lldb support

[Eli Zaretskii]

> Date: Wed, 9 Nov 2016 20:57:24 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: Daniel Colascione <dancol@dancol.org>, emacs-devel@gnu.org
> 
> gud mode supports completely unfree debuggers. lldb is free software.
> It seems like bad policy to encourage the use of non-free tools by
> supporting them better than free tools.

Daniel said lldb supports the MI protocol.  If that is true, lldb is
already supported.  Can someone try that and see if that works, and if
not, tell why?

Thanks.

Re: lldb support

[Toon Claes]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> Daniel said lldb supports the MI protocol.  If that is true, lldb is
> already supported.  Can someone try that and see if that works, and if
> not, tell why?
>
> Thanks.

The tool `lldb-mi` is not installed on macOS by default (on 10.11 El Capitan
that is). But it can be installed with Homebrew.

    brew install llvm --with-lldb --with-clang

But that is outside the question.
I tried to use it:

    M-x gud-gdb /usr/local/opt/llvm/bin/lldb-mi hello

and when setting a breakpoint I got the following error:

    error: command 'breakpoint' did not recognize 'hello .swift:28' as valid (subcommand might be invalid).
    ambiguous command 'break'. Possible completions:
    	breakpoint

So, no, it is not working at the moment.


Regards,
Toon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

Re: lldb support

[Perry E. Metzger]

On Thu, 10 Nov 2016 05:43:26 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Wed, 9 Nov 2016 20:57:24 -0500
> > From: "Perry E. Metzger" <perry@piermont.com>
> > Cc: Daniel Colascione <dancol@dancol.org>, emacs-devel@gnu.org
> > 
> > gud mode supports completely unfree debuggers. lldb is free
> > software. It seems like bad policy to encourage the use of
> > non-free tools by supporting them better than free tools.  
> 
> Daniel said lldb supports the MI protocol.  If that is true, lldb is
> already supported.  Can someone try that and see if that works, and
> if not, tell why?

When I last tried things didn't work correctly but I don't understand
gud mode's internals yet and could not give you a reasonable bug
report or patch as of yet.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: lldb support

[Eli Zaretskii]

> From: Toon Claes <toon@iotcl.com>
> Cc: "Perry E. Metzger" <perry@piermont.com>,  dancol@dancol.org,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Thu, 10 Nov 2016 10:33:41 +0100
> 
> > Daniel said lldb supports the MI protocol.  If that is true, lldb is
> > already supported.  Can someone try that and see if that works, and if
> > not, tell why?
> >
> > Thanks.
> 
> The tool `lldb-mi` is not installed on macOS by default (on 10.11 El Capitan
> that is). But it can be installed with Homebrew.
> 
>     brew install llvm --with-lldb --with-clang
> 
> But that is outside the question.
> I tried to use it:
> 
>     M-x gud-gdb /usr/local/opt/llvm/bin/lldb-mi hello
> 
> and when setting a breakpoint I got the following error:
> 
>     error: command 'breakpoint' did not recognize 'hello .swift:28' as valid (subcommand might be invalid).
>     ambiguous command 'break'. Possible completions:
>     	breakpoint
> 
> So, no, it is not working at the moment.

Thanks.

"M-x gud-gdb" doesn't use the MI protocol, so this is not the command
that should be used to probe that.

Instead, please invoke "M-x gdb RET".  It will suggest a command line
that assumes GDB; please change it as lldb-mi requires.

If that starts okay and succeeds to load the debuggee, please see if
the basic features work: setting breakpoints by clicking on the
fringe, running the program from the tool-bar buttons and from the GUD
buffer, displaying the various windows ("M-x gdb-many-windows"), etc.

Thanks again.

Re: lldb support

[Eli Zaretskii]

> > Daniel said lldb supports the MI protocol.  If that is true, lldb is
> > already supported.  Can someone try that and see if that works, and
> > if not, tell why?
> 
> When I last tried things didn't work correctly but I don't understand
> gud mode's internals yet and could not give you a reasonable bug
> report or patch as of yet.

GUD doesn't use the MI protocol, you should use gdb-mi.el (which is
invoked by "M-x gdb RET").  See the instructions I posted a few
minutes ago.

Thanks.

Re: lldb support

[Toon Claes]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> Instead, please invoke "M-x gdb RET".  It will suggest a command line
> that assumes GDB; please change it as lldb-mi requires.

Well, I also tried that. But gives the error:

    Error: you did not specify -i=mi on GDB's command line!

After that also a lot of other errors occur:

    5^error,msg="Driver. Received command '5-file-list-exec-source-files'. It was not handled. Command 'file-list-exec-source-files' not in Command Factory"
    6^error,msg="Driver. Received command '6-file-list-exec-source-file'. It was not handled. Command 'file-list-exec-source-file' not in Command Factory"
    8^error,msg="Command 'stack-info-frame'. Invalid process during debug session"
    10^error,msg="Driver. Received command '10-break-list'. It was not handled. Command 'break-list' not in Command Factory"
    12^error,msg="Driver. Received command '12-break-list'. It was not handled. Command 'break-list' not in Command Factory"

So results aren't very hopeful.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

Re: lldb support

[Eli Zaretskii]

> From: Toon Claes <toon@iotcl.com>
> Cc: dancol@dancol.org,  emacs-devel@gnu.org,  rms@gnu.org,  perry@piermont.com
> Date: Thu, 10 Nov 2016 17:27:18 +0100
> 
> > Instead, please invoke "M-x gdb RET".  It will suggest a command line
> > that assumes GDB; please change it as lldb-mi requires.
> 
> Well, I also tried that. But gives the error:
> 
>     Error: you did not specify -i=mi on GDB's command line!

Doesn't lldb-mi accept the --interpreter=mi argument on its command
line?  That would be strange, since it's supposed to be a
compatibility shim, and is advertised to work with Eclipse.

If you disable this test in gdb-mi.el, do you get better results?

> After that also a lot of other errors occur:
> 
>     5^error,msg="Driver. Received command '5-file-list-exec-source-files'. It was not handled. Command 'file-list-exec-source-files' not in Command Factory"
>     6^error,msg="Driver. Received command '6-file-list-exec-source-file'. It was not handled. Command 'file-list-exec-source-file' not in Command Factory"
>     8^error,msg="Command 'stack-info-frame'. Invalid process during debug session"
>     10^error,msg="Driver. Received command '10-break-list'. It was not handled. Command 'break-list' not in Command Factory"
>     12^error,msg="Driver. Received command '12-break-list'. It was not handled. Command 'break-list' not in Command Factory"
> 
> So results aren't very hopeful.

These could be the result of not activating the MI mode in lldb-mi,
because of the previous error message.  How about asking the lldb-mi
maintainers what should be the correct invocation of this tool?

Thanks.

Re: lldb support

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Why would we want to support it
  > > rather than saying, "We support GDB -- use that."?

  > All the usual reasons people prefer tool A over tool B: compatibility 
  > with a specific environment, personal customizations, familiarity, and 
  > personal preference. LLDB is free software. We should support it.

Your argument disregards the important fact that LLDB is part
of a project that aims to replace many important GNU packages,
and its success is the GNU Project's loss.

I think that that is not important to you, but it is very
important for the GNU Project.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: lldb support

[Stefan Monnier]

> Your argument disregards the important fact that LLDB is part
> of a project that aims to replace many important GNU packages,
> and its success is the GNU Project's loss.

I believe this is false.  LLDB is not a part of that.  It's probably
true of a part of LLVM/LLDB/Clang, but let's not get carried away.


        Stefan

Re: lldb support

[Nikolaus Rath]

On Nov 10 2016, Richard Stallman <rms@gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > Why would we want to support it
>   > > rather than saying, "We support GDB -- use that."?
>
>   > All the usual reasons people prefer tool A over tool B: compatibility 
>   > with a specific environment, personal customizations, familiarity, and 
>   > personal preference. LLDB is free software. We should support it.
>
> Your argument disregards the important fact that LLDB is part
> of a project that aims to replace many important GNU packages,
> and its success is the GNU Project's loss.
>
> I think that that is not important to you, but it is very
> important for the GNU Project.

Doesn't the same apply to the Linux kernel, whose success is the GNU
(Hurd) Project's loss? Yet Emacs seems to support Linux even better than
it supports Hurd.

(Just curious).

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: lldb support

[Philippe Vaucher]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

>
> Your argument disregards the important fact that LLDB is part
> of a project that aims to replace many important GNU packages,
> and its success is the GNU Project's loss.
>

I don't think the aim is to replace GNU packages, but to give everyone
better tools. Without the GNU packages none of it would have been possible.

If people find the alternative better it should be intencive to improve the
GNU packages... not to try to find ways of preventing them to use the
alternative (which is the wrong answer in my honest opinion, it's a sort of
vendor lockin).

You have to understand that these sort of tactics simply don't work: none
of these users will switch to GDB just because Emacs does not support the
alternative. They will simply write the code in emacs and debug it outside
emacs, so the result is actually the opposite of what you want (the users
using GNU tools all the time).



> I think that that is not important to you, but it is very
> important for the GNU Project.
>

I don't think that promoting the GNU project should be more important than
having Emacs support free software, especially for something most Emacs
user would expect it to do.

I understand that GNU draws the line about commercial software tho, and I
understand the conflict of interests in this affair. It's not easy.

Philippe

[-- Attachment #2: Type: text/html, Size: 1876 bytes --]

Re: lldb support

[Stefan Monnier]

> I don't think the aim is to replace GNU packages, but to give everyone
> better tools.  Without the GNU packages none of it would have been possible.

There's a long history between Apple, GCC, and the GPL.
So, yes, Apple's investment into LLVM was specifically to avoid the GPL.

But LLVM (and surrounding tools) exists independently from Apple.

> You have to understand that these sort of tactics simply don't work: none
> of these users will switch to GDB just because Emacs does not support the
> alternative. They will simply write the code in emacs and debug it outside
> emacs, so the result is actually the opposite of what you want (the users
> using GNU tools all the time).

Indeed.  By avoiding LLVM/Clang/... we're just harming
ourselves, AFAICT.


        Stefan

Re: lldb support

[Stefan Huchler]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

> You have to understand that these sort of tactics simply don't work: none of these users will switch to GDB just because Emacs does not support the alternative. They will simply write the code in emacs and debug it
> outside emacs, so the result is actually the opposite of what you want (the users using GNU tools all the time).

Yes maybe non or not much of the current lldb users will switch to GDB, but what is
with users that have for their first time a problem to debug, and use a
debugger tool first time in their live. if they are emacs users then
would likely use gdb.

So on them it would work, or at least on some of them. If that is
moralicly something good or bad is another question, I am shure Richard
or others here have more profound knowledge than I do.

Re: lldb support

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

>>>>> "PV" == Philippe Vaucher <philippe.vaucher@gmail.com> writes:

VP> If people find the alternative better it should be intencive to improve
PV> the GNU packages... not to try to find ways of preventing them to use the
PV> alternative (which is the wrong answer in my honest opinion, it's a sort
PV> of vendor lockin).

[...]

PV> I don't think that promoting the GNU project should be more important than
VP> having Emacs support free software, especially for something most Emacs
VP> user would expect it to do.

I strongly agree. Inhibiting users' freedom to choose other *free* software,
because that other free software is not part of the GNU project, makes it
sound like the ubiquity of the GNU project, and not user freedom, is the goal.

I understand believing that "GNU everywhere" could increase freedom due to the
nature of the GPL, but now it starts to sound a lot more like "freedom to use
what the FSF thinks you should use", rather than real freedom -- especially
when the FSF's choices are less capable than other free alternatives.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: lldb support

[Sam Steingold]

> * Richard Stallman <ezf@tah.bet> [2016-11-10 20:26:18 -0500]:
>
>   > All the usual reasons people prefer tool A over tool B:
>   > compatibility with a specific environment, personal
>   > customizations, familiarity, and personal preference. LLDB is free
>   > software. We should support it.
>
> Your argument disregards the important fact that LLDB is part
> of a project that aims to replace many important GNU packages,
> and its success is the GNU Project's loss.

What is wrong with replacing a GNU package with a non-GNU
package which is free software?

How is it a loss for GNU?

It seems that if there is a better free debugger than gdb, GNU can
switch the resources currently devoted to gdb to another project.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://mideasttruth.com
http://think-israel.org http://thereligionofpeace.com https://jihadwatch.org
Linux: Telling Microsoft where to go since 1991.

Re: lldb support

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Doesn't the same apply to the Linux kernel, whose success is the GNU
  > (Hurd) Project's loss? Yet Emacs seems to support Linux even better than
  > it supports Hurd.

There is substantial similarity and a substantial difference.  One
difference is that we never got the Hurd to work well and become
popular; indeed, Linux became available before the Hurd worked at all.

Another difference is that Linux is not an attack on the GPL; it is
under the GPL.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: lldb support

[Perry E. Metzger]

On Thu, 10 Nov 2016 20:26:18 -0500 Richard Stallman <rms@gnu.org>
wrote:
>   > > Why would we want to support it
>   > > rather than saying, "We support GDB -- use that."?  
> 
>   > All the usual reasons people prefer tool A over tool B:
>   > compatibility with a specific environment, personal
>   > customizations, familiarity, and personal preference. LLDB is
>   > free software. We should support it.  
> 
> Your argument disregards the important fact that LLDB is part
> of a project that aims to replace many important GNU packages,
> and its success is the GNU Project's loss.

I thought the goal of the GNU Project was to further the cause of
free software and not to make some particular brand of free software
more popular. Was I mistaken?

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: lldb support

[Stefan Huchler]

John Wiegley <jwiegley@gmail.com> writes:

> I understand believing that "GNU everywhere" could increase freedom due to the
> nature of the GPL, but now it starts to sound a lot more like "freedom to use
> what the FSF thinks you should use", rather than real freedom -- especially
> when the FSF's choices are less capable than other free alternatives.

Not including something does not limit choices in my mind? Everybody is
free in forking something or write a extension. But thats just my 2
cents on that.

So I think it should be watched more from a gain and loss
perspective. Like you would discuss other features. So what would be the
harm and what the gain.

The gain is that maybe more people use Emacs? I doubt that somebody uses
emacs because of that feature or not, either you love emacs or you hate
it, there is not much room between that. But maybe I am wrong here.

But lets say a few use emacs then, and send maybe patches or write
packages for it.

The negative is that maybe some users will use lldb instead of gdb, and
send patches for lldb instead of gdb. Therefor lldb will be more
usefull, and some companies that make proprietary software will not only
profit from it, they could even sell proprietary extensions to it?

Something like that? I mean companies could and shurly do use also gdb
to develop proprietary software, so its more about the proprietary
extensions.

Isnt that the core conflict between the opensource movement and the free
software movement? That you care about such stuff, while the opensource
movement only want better tools and a more productive development system?

Or why does the gpl exist in the first place if its just replacable and
the same as such public domain like bsd lisense?

Re: lldb support

[Stefan Huchler]

Sam Steingold <sds@gnu.org> writes:

> What is wrong with replacing a GNU package with a non-GNU
> package which is free software?
>
> How is it a loss for GNU?
>
> It seems that if there is a better free debugger than gdb, GNU can
> switch the resources currently devoted to gdb to another project.

I think Free is != free, bsd != gpl.

One is copyleft the other not. Or like MS would call it the one is viral
the other not.

Re: lldb support

[Toon Claes]

[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> Doesn't lldb-mi accept the --interpreter=mi argument on its command
> line?  That would be strange, since it's supposed to be a
> compatibility shim, and is advertised to work with Eclipse.

Yes, it does support the argument, but gdb-mi.el does not seem to
recognize it.

> If you disable this test in gdb-mi.el, do you get better results?

These are the errors I am getting when trying to set a breakpoint and
running the process.

Command: break hello.swift:19
Command: -exec-run
Driver. Received command '5-file-list-exec-source-files'. It was not handled. Command 'file-list-exec-source-files' not in Command Factory
Driver. Received command '6-file-list-exec-source-file'. It was not handled. Command 'file-list-exec-source-file' not in Command Factory
Command 'stack-info-frame'. Invalid process during debug session
Driver. Received command '10-break-list'. It was not handled. Command 'break-list' not in Command Factory
Driver. Received command '12-break-list'. It was not handled. Command 'break-list' not in Command Factory
Driver. Received command '14-break-list'. It was not handled. Command 'break-list' not in Command Factory
Driver. Received command '16-break-list'. It was not handled. Command 'break-list' not in Command Factory
Driver. Received command '18-break-list'. It was not handled. Command 'break-list' not in Command Factory


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

Re: lldb support

[Eli Zaretskii]

> From: Toon Claes <toon@iotcl.com>
> Cc: perry@piermont.com,  dancol@dancol.org,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 12 Nov 2016 08:04:39 +0100
> 
> > Doesn't lldb-mi accept the --interpreter=mi argument on its command
> > line?  That would be strange, since it's supposed to be a
> > compatibility shim, and is advertised to work with Eclipse.
> 
> Yes, it does support the argument, but gdb-mi.el does not seem to
> recognize it.

What do you mean by "doesn't recognize"?  gdb-mi.el doesn't look at
the invocation command, it looks at the 1st response returned by the
debugger.  See the function gdb--check-interpreter in gdb-mi.el.
Evidently, the response produced by lldb-mi doesn't match the criteria
there.  Can you look at the value of 'string' in that function and
tell what it is?

> > If you disable this test in gdb-mi.el, do you get better results?
> 
> These are the errors I am getting when trying to set a breakpoint and
> running the process.
> 
> Command: break hello.swift:19
> Command: -exec-run
> Driver. Received command '5-file-list-exec-source-files'. It was not handled. Command 'file-list-exec-source-files' not in Command Factory
> Driver. Received command '6-file-list-exec-source-file'. It was not handled. Command 'file-list-exec-source-file' not in Command Factory
> Command 'stack-info-frame'. Invalid process during debug session
> Driver. Received command '10-break-list'. It was not handled. Command 'break-list' not in Command Factory
> Driver. Received command '12-break-list'. It was not handled. Command 'break-list' not in Command Factory
> Driver. Received command '14-break-list'. It was not handled. Command 'break-list' not in Command Factory
> Driver. Received command '16-break-list'. It was not handled. Command 'break-list' not in Command Factory
> Driver. Received command '18-break-list'. It was not handled. Command 'break-list' not in Command Factory

I guess lldb-mi is not yet up to speed in its support of the MI
protocol, if it doesn't even support the basic MI input syntax and/or
the '-break-list' command.  The description of the MI protocol input
(in the GDB manual) clearly says that an MI command has the following
formal syntax:

  'MI-COMMAND ==>'
     '[ TOKEN ] "-" OPERATION ( " " OPTION )* [ " --" ] ( " " PARAMETER )* NL'

So it looks like lldb-mi either didn't implement the TOKEN part, or
doesn't yet support the '-break-list' command itself.  This TOKEN part
is very important for the front-end to know which response of the
debugger corresponds to which front-end command.  And '-break-list'
is, of course, a very important command.  Perhaps consider reporting
this to the lldb-mi developers, as these are significant omissions,
and make the tool not very useful with front-ends, to say the least.

Re: lldb support

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > What is wrong with replacing a GNU package with a non-GNU
  > package which is free software?

  > How is it a loss for GNU?

It's clear that the replacement of any GNU package is bad for the GNU
Project, even in cases where it is not an injustice.

However, it is misleading to say that GDB would be replaced with other
free software.  There is a program called lldb which is free, but
since it is not copylefted, we must expect it to be the core of a
collection of software _some of which is nonfree_.

In the case of GDB, the corresponding collection has to be free
software, due to the GNU GPL.

A noncopylefted free program is not ipso facto an injustice, but it
fails to resist injustice.  Replacing a copylefted free program with a
noncopylefted free program opens a door to nonfree software, where
previously we resisted it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: lldb support

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The more a person shares my general goals and views, the more I value
that person's advice and opinions about my specific decisions.

I think you and I don't have the same goals or the same ideas, so it
is no surprise that you disagree with some of my decisions, or don't
understand them.  That doesn't mean I'm mistaken.  That you think I
contradicted myself doesn't mean that I did so -- it could simply
mean you don't get the point.

I explain my decisions to the list since that is useful to do.  Didn't
I already explain, in 2015, why I think it would be a mistake to
collaborate with a plan to replace our copylefted tools with
non-copylefted ones?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: lldb support

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I strongly agree. Inhibiting users' freedom to choose other *free* software,
  > because that other free software is not part of the GNU project, makes it
  > sound like the ubiquity of the GNU project, and not user freedom, is the goal.

I am not sure what course of action is best here, but this sort of
argument are not cogent because it is a fundamental misunderstanding.
This decision has no effect on any user's freedom.

The developers of a free program never have a moral obligation
to support any particular platform or interoperation, because users
who don't like their decision are free to change the code.

When the developers of a free program decide which features to
include, including which platforms or interoperation to support, the
question at stake is not what uses to _allow_, but rather which uses
to _facilitate_.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: lldb support

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> When the developers of a free program decide which features to include,
> including which platforms or interoperation to support, the question at
> stake is not what uses to _allow_, but rather which uses to _facilitate_.

I do see what you mean. If a volunteer is willing to give us code to support
using lldb, does it then become a question of which uses to _not facilitate_?
That's really what I reacting to. I totally understand not *making an effort*
to support something that might inhibit the growth of gdb; but if we're in the
position of receiving code to support lldb, then should the same argument be
used to deny its acceptance. Or is this not what you're saying?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: lldb support

[Joseph Mingrone]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

John Wiegley <jwiegley@gmail.com> writes:
> If a volunteer is willing to give us code to support using lldb, does it then
> become a question of which uses to _not facilitate_?  That's really what I
> reacting to. I totally understand not *making an effort* to support something
> that might inhibit the growth of gdb; but if we're in the position of
> receiving code to support lldb, then should the same argument be used to deny
> its acceptance. Or is this not what you're saying?

Such code to support LLDB exists.

https://svnweb.freebsd.org/ports/head/editors/emacs/files/extrapatch-lldb-gud.el?view=log

It's available now for Emacs users on at least one (free) operating system.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 930 bytes --]

Re: lldb support

[Stefan Monnier]

>> If a volunteer is willing to give us code to support using lldb, does it then
>> become a question of which uses to _not facilitate_?  That's really what I
>> reacting to. I totally understand not *making an effort* to support something
>> that might inhibit the growth of gdb; but if we're in the position of
>> receiving code to support lldb, then should the same argument be used to deny
>> its acceptance. Or is this not what you're saying?

> Such code to support LLDB exists.
>
> https://svnweb.freebsd.org/ports/head/editors/emacs/files/extrapatch-lldb-gud.el?view=log
>
> It's available now for Emacs users on at least one (free) operating system.

This is the patch that was retracted from the LLVM repository because of
copyright issues, IIRC.

So, it's clearly not an option for inclusion into Emacs.


        Stefan

Re: lldb support

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I've been delayed a long time in responding to that discussion
because I was busy.

  > > When the developers of a free program decide which features to include,
  > > including which platforms or interoperation to support, the question at
  > > stake is not what uses to _allow_, but rather which uses to _facilitate_.

  > I do see what you mean. If a volunteer is willing to give us code to support
  > using lldb, does it then become a question of which uses to _not facilitate_?

Yes, it does.  The question is which uses the package should facilitate
and which uses the package should not facilitate.

  > That's really what I reacting to. I totally understand not *making an effort*
  > to support something that might inhibit the growth of gdb; but if we're in the
  > position of receiving code to support lldb, then should the same argument be
  > used to deny its acceptance.

Who wrote the code is not the issue.  The issue is, do we want to HAVE
code in Emacs to do that particular thing.

I am not sure whether the this particular feature is a significant
issue.  Maybe it is a minor issue; maybe there is no real need to
refuse to facilitate using LLDB in this particular way.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: lldb support

[Toon Claes]

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]

On 10 Nov 2016, at 18:19, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> These could be the result of not activating the MI mode in lldb-mi,
> because of the previous error message.  How about asking the lldb-mi
> maintainers what should be the correct invocation of this tool?
> 
> Thanks.

Sorry for the late reply.
But I did contact the llvm-dev mailing list (because I was not allowed to post on the lldb-dev mailing list) and I got this reply from Adrian Prantl:
> The subset of MI commands that lldb-mi currently understands is very narrow and was added to support one specific consumer (I think it might have been Eclipse, but I could be misremembering). In any case, it looks like lldb-mi is missing the implementation for certain MI commands that Emacs is expecting. Adding these shouldn't be too much work if you're building on top of the LLDB scripting API.

(see http://lists.llvm.org/pipermail/llvm-dev/2017-January/108663.html <http://lists.llvm.org/pipermail/llvm-dev/2017-January/108663.html>)

So I think it would be best to submit patches to lldb instead of emacs.


-- Toon


[-- Attachment #2: Type: text/html, Size: 1860 bytes --]