Contributing LLVM.org patches to gud.el

Contributing LLVM.org patches to gud.el

[Andrew L. Moore]

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

The LLVM source repository includes a patch adding basic lldb support to gud.el.  The patch adapted to current gud.el (Github-mirror commit 7e09ef09a479731d01b1ca46e94ddadd73ac98e3) is attached below.  Although I’m not affiliated with llvm.org <http://llvm.org/>, I’d be interested to know if and how this might be accepted into the Emacs distribution, RMS’s opinion of LLVM notwithstanding. Thank you!
-AM


[-- Attachment #2.1: Type: text/html, Size: 729 bytes --]

[-- Attachment #2.2: lldb-gud.el.patch --]
[-- Type: application/octet-stream, Size: 13325 bytes --]

diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el
index 42c5b20..7f2e9c0 100644
--- a/lisp/progmodes/gud.el
+++ b/lisp/progmodes/gud.el
@@ -35,7 +35,7 @@
 ;; kluge with the gud-xdb-directories hack producing gud-dbx-directories.
 ;; Derek L. Davies <ddavies@world.std.com> added support for jdb (Java
 ;; debugger.)  Jan Nieuwenhuizen added support for the Guile REPL (Guile
-;; debugger).
+;; debugger). llvm.org added support for lldb.
 
 ;;; Code:
 
@@ -56,7 +56,7 @@
 
 (defgroup gud nil
   "The \"Grand Unified Debugger\" interface.
-Supported debuggers include gdb, sdb, dbx, xdb, perldb,
+Supported debuggers include lldb, gdb, sdb, dbx, xdb, perldb,
 pdb (Python), and jdb."
   :group 'processes
   :group 'tools)
@@ -141,12 +141,12 @@ Used to gray out relevant toolbar icons.")
 			       (display-graphic-p)
 			       (fboundp 'x-show-tip))
 		  :visible (memq gud-minor-mode
-				'(gdbmi guiler dbx sdb xdb pdb))
+				'(lldb gdbmi guiler dbx sdb xdb pdb))
 	          :button (:toggle . gud-tooltip-mode))
     ([refresh]	"Refresh" . gud-refresh)
     ([run]	menu-item "Run" gud-run
                   :enable (not gud-running)
-		  :visible (memq gud-minor-mode '(gdbmi gdb dbx jdb)))
+		  :visible (memq gud-minor-mode '(lldb gdbmi gdb dbx jdb)))
     ([go]	menu-item (if (bound-and-true-p gdb-active-process)
 			      "Continue" "Run") gud-go
 		  :visible (and (eq gud-minor-mode 'gdbmi)
@@ -164,18 +164,18 @@ Used to gray out relevant toolbar icons.")
     ([tbreak]	menu-item "Temporary Breakpoint" gud-tbreak
                   :enable (not gud-running)
 		  :visible (memq gud-minor-mode
-				'(gdbmi gdb sdb xdb)))
+				'(lldb gdbmi gdb sdb xdb)))
     ([break]	menu-item "Set Breakpoint" gud-break
                   :enable (not gud-running)
 		  :visible (gud-tool-bar-item-visible-no-fringe))
     ([up]	menu-item "Up Stack" gud-up
 		  :enable (not gud-running)
 		  :visible (memq gud-minor-mode
-				 '(gdbmi gdb guiler dbx xdb jdb pdb)))
+				 '(lldb gdbmi gdb guiler dbx xdb jdb pdb)))
     ([down]	menu-item "Down Stack" gud-down
 		  :enable (not gud-running)
 		  :visible (memq gud-minor-mode
-				 '(gdbmi gdb guiler dbx xdb jdb pdb)))
+				 '(lldb gdbmi gdb guiler dbx xdb jdb pdb)))
     ([pp]	menu-item "Print S-expression" gud-pp
                   :enable (and (not gud-running)
 				  (bound-and-true-p gdb-active-process))
@@ -187,7 +187,7 @@ Used to gray out relevant toolbar icons.")
 			      "Dump object"
 			    "Print Dereference") gud-pstar
                   :enable (not gud-running)
-		  :visible (memq gud-minor-mode '(gdbmi gdb jdb)))
+		  :visible (memq gud-minor-mode '(lldb gdbmi gdb jdb)))
     ([print]	menu-item "Print Expression" gud-print
                   :enable (not gud-running))
     ([watch]	menu-item "Watch Expression" gud-watch
@@ -196,13 +196,13 @@ Used to gray out relevant toolbar icons.")
     ([finish]	menu-item "Finish Function" gud-finish
                   :enable (not gud-running)
 		  :visible (memq gud-minor-mode
-				 '(gdbmi gdb guiler xdb jdb pdb)))
+				 '(lldb gdbmi gdb guiler xdb jdb pdb)))
     ([stepi]	menu-item "Step Instruction" gud-stepi
                   :enable (not gud-running)
-		  :visible (memq gud-minor-mode '(gdbmi gdb dbx)))
+		  :visible (memq gud-minor-mode '(lldb gdbmi gdb dbx)))
     ([nexti]	menu-item "Next Instruction" gud-nexti
                   :enable (not gud-running)
-		  :visible (memq gud-minor-mode '(gdbmi gdb dbx)))
+		  :visible (memq gud-minor-mode '(lldb gdbmi gdb dbx)))
     ([step]	menu-item "Step Line" gud-step
                   :enable (not gud-running))
     ([next]	menu-item "Next Line" gud-next
@@ -237,7 +237,7 @@ Used to gray out relevant toolbar icons.")
 	:visible (not (eq gud-minor-mode 'gdbmi)))
        ([menu-bar run] menu-item
 	,(propertize "run" 'face 'font-lock-doc-face) gud-run
-	:visible (memq gud-minor-mode '(gdbmi gdb dbx jdb)))
+	:visible (memq gud-minor-mode '(lldb gdbmi gdb dbx jdb)))
        ([menu-bar go] menu-item
 	,(propertize " go " 'face 'font-lock-doc-face) gud-go
 	:visible (and (eq gud-minor-mode 'gdbmi)
@@ -356,6 +356,7 @@ are interpreted specially if present.  These are:
   %l -- Number of current source line.
   %e -- Text of the C lvalue or function-call expression surrounding point.
   %a -- Text of the hexadecimal address surrounding point.
+  %b -- Text of the most recently created breakpoint id.
   %p -- Prefix argument to the command (if any) as a number.
   %c -- Fully qualified class name derived from the expression
         surrounding point (jdb only).
@@ -964,6 +965,131 @@ SKIP is the number of chars to skip on each line, it defaults to 0."
 
 \f
 ;; ======================================================================
+;; lldb functions
+
+;; History of argument lists passed to lldb.
+(defvar gud-lldb-history nil)
+
+;; Keeps track of breakpoint created.  In the following case, the id is "1".
+;; It is used to implement temporary breakpoint.
+;; (lldb) b main.c:39
+;; breakpoint set --file 'main.c' --line 39
+;; Breakpoint created: 1: file ='main.c', line = 39, locations = 1
+(defvar gud-breakpoint-id nil)
+
+(defun lldb-extract-breakpoint-id (string)
+  ;; Search for "Breakpoint created: \\([^:\n]*\\):" pattern.
+  (if (string-match "Breakpoint created: \\([^:\n]*\\):" string)
+      (progn
+        (setq gud-breakpoint-id (match-string 1 string))
+        (message "breakpoint id: %s" gud-breakpoint-id)))
+)
+
+(defun gud-lldb-marker-filter (string)
+  (setq gud-marker-acc
+	(if gud-marker-acc (concat gud-marker-acc string) string))
+  (lldb-extract-breakpoint-id gud-marker-acc)
+  (let (start)
+    ;; Process all complete markers in this chunk
+    (while (or
+            ;; (lldb) r
+            ;; Process 15408 launched: '/Volumes/data/lldb/svn/trunk/test/conditional_break/a.out' (x86_64)
+            ;; (lldb) Process 15408 stopped
+            ;; * thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread
+            (string-match " at \\([^:\n]*\\):\\([0-9]*\\), stop reason = .*\n"
+                          gud-marker-acc start)
+            ;; (lldb) frame select -r 1
+            ;; frame #1: 0x0000000100000e09 a.out`main + 25 at main.c:44
+            (string-match "\nframe.* at \\([^:\n]*\\):\\([0-9]*\\)\n"
+                           gud-marker-acc start))
+      (setq gud-last-frame
+            (cons (match-string 1 gud-marker-acc)
+                  (string-to-number (match-string 2 gud-marker-acc)))
+            start (match-end 0)))
+
+    ;; Search for the last incomplete line in this chunk
+    (while (string-match "\n" gud-marker-acc start)
+      (setq start (match-end 0)))
+
+    ;; If we have an incomplete line, store it in gud-marker-acc.
+    (setq gud-marker-acc (substring gud-marker-acc (or start 0))))
+  string)
+
+;; Keeps track of whether the Python lldb_oneshot_break function definition has
+;; been exec'ed.
+(defvar lldb-oneshot-break-defined nil)
+
+;;;###autoload
+(defun lldb (command-line)
+  "Run lldb on program FILE in buffer *gud-FILE*.
+The directory containing FILE becomes the initial working directory
+and source-file directory for your debugger."
+  (interactive (list (gud-query-cmdline 'lldb)))
+
+  (gud-common-init command-line nil 'gud-lldb-marker-filter)
+  (set (make-local-variable 'gud-minor-mode) 'lldb)
+  (setq lldb-oneshot-break-defined nil)
+
+  (gud-def gud-listb  "breakpoint list"
+                      "l"    "List all breakpoints.")
+  (gud-def gud-bt     "thread backtrace"
+                      "b"    "Show stack for the current thread.")
+  (gud-def gud-bt-all "thread backtrace all"
+                      "B"    "Show stacks for all the threads.")
+
+  (gud-def gud-break  "breakpoint set -f %f -l %l"
+                      "\C-b" "Set breakpoint at current line.")
+  (gud-def gud-tbreak
+	   (progn (gud-call "breakpoint set -f %f -l %l")
+                  (sit-for 1)
+                  (if (not lldb-oneshot-break-defined)
+                      (progn
+                        ;; The "\\n"'s are required to escape the newline chars
+                        ;; passed to the lldb process.
+                        (gud-call (concat "script exec \"def lldb_oneshot_break(frame, bp_loc):\\n"
+                                                        "    target=frame.GetThread().GetProcess().GetTarget()\\n"
+                                                        "    bp=bp_loc.GetBreakpoint()\\n"
+                                                        "    print 'Deleting oneshot breakpoint:', bp\\n"
+                                                        "    target.BreakpointDelete(bp.GetID())\""))
+                        (sit-for 1)
+                        ;; Set the flag since Python knows about the function def now.
+                        (setq lldb-oneshot-break-defined t)))
+                  (gud-call "breakpoint command add -p %b -o 'lldb_oneshot_break(frame, bp_loc)'"))
+	              "\C-t" "Set temporary breakpoint at current line.")
+  (gud-def gud-remove "breakpoint clear -f %f -l %l"
+                      "\C-d" "Remove breakpoint at current line")
+  (gud-def gud-step   "thread step-in"
+                      "\C-s" "Step one source line with display.")
+  (gud-def gud-stepi  "thread step-inst"
+                      "\C-i" "Step one instruction with display.")
+  (gud-def gud-next   "thread step-over"
+                      "\C-n" "Step one line (skip functions).")
+  (gud-def gud-nexti  "thread step-inst-over"
+                      nil    "Step one instruction (skip functions).")
+  (gud-def gud-cont   "process continue"
+                      "\C-r" "Continue with display.")
+  (gud-def gud-finish "thread step-out"
+                      "\C-f" "Finish executing current function.")
+  (gud-def gud-up     "frame select -r %p"
+                      "<"    "Up 1 stack frame.")
+  (gud-def gud-down   "frame select -r -%p"
+                      ">"    "Down 1 stack frame.")
+  (gud-def gud-print  "expression -- %e"
+                      "\C-p" "Evaluate C expression at point.")
+  (gud-def gud-pstar  "expression -- *%e"
+                      nil    "Evaluate C dereferenced pointer expression at point.")
+  (gud-def gud-run    "run"
+                      nil    "Run the program.")
+  (gud-def gud-stop-subjob    "process kill"
+                      nil    "Stop the program.")
+
+  (setq comint-prompt-regexp  "\\(^\\|\n\\)\\*")
+  (setq paragraph-start comint-prompt-regexp)
+  (run-hooks 'lldb-mode-hook)
+  )
+
+\f
+;; ======================================================================
 ;; sdb functions
 
 ;; History of argument lists passed to sdb.
@@ -2499,9 +2625,10 @@ gud, see `gud-mode'."
   "Major mode for interacting with an inferior debugger process.
 
    You start it up with one of the commands M-x gdb, M-x sdb, M-x dbx,
-M-x perldb, M-x xdb, or M-x jdb.  Each entry point finishes by executing a
-hook; `gdb-mode-hook', `sdb-mode-hook', `dbx-mode-hook',
-`perldb-mode-hook', `xdb-mode-hook', or `jdb-mode-hook' respectively.
+M-x perldb, M-x xdb, M-x jdb, or M-x lldb.  Each entry point finishes by
+executing a hook; `gdb-mode-hook', `sdb-mode-hook', `dbx-mode-hook',
+`perldb-mode-hook', `xdb-mode-hook', `jdb-mode-hook', or `lldb-mode-hook'
+respectively.
 
 After startup, the following commands are available in both the GUD
 interaction buffer and any source buffer GUD visits due to a breakpoint stop
@@ -2531,7 +2658,7 @@ Under gdb, sdb and xdb, \\[gud-tbreak] behaves exactly like \\[gud-break],
 except that the breakpoint is temporary; that is, it is removed when
 execution stops on it.
 
-Under gdb, dbx, and xdb, \\[gud-up] pops up through an enclosing stack
+Under gdb, dbx, xdb, and lldb, \\[gud-up] pops up through an enclosing stack
 frame.  \\[gud-down] drops back down through one.
 
 If you are using gdb or xdb, \\[gud-finish] runs execution to the return from
@@ -2858,7 +2985,7 @@ Obeying it means displaying in another window the specified file and line."
 	result)
     (while (and str
 		(let ((case-fold-search nil))
-		  (string-match "\\([^%]*\\)%\\([adefFlpc]\\)" str)))
+		  (string-match "\\([^%]*\\)%\\([abdefFlpc]\\)" str)))
       (let ((key (string-to-char (match-string 2 str)))
 	    subst)
 	(cond
@@ -2886,6 +3013,8 @@ Obeying it means displaying in another window the specified file and line."
 	  (setq subst (gud-find-expr)))
 	 ((eq key ?a)
 	  (setq subst (gud-read-address)))
+	 ((eq key ?b)
+	  (setq subst gud-breakpoint-id))
 	 ((eq key ?c)
 	  (setq subst
                 (gud-find-class
@@ -3520,6 +3649,7 @@ With arg, dereference expr if ARG is positive, otherwise do not dereference."
 (defun gud-tooltip-print-command (expr)
   "Return a suitable command to print the expression EXPR."
   (pcase gud-minor-mode
+    (`lldb (concat "expression -o -- \"" expr "\""))
     (`gdbmi (concat "-data-evaluate-expression \"" expr "\""))
     (`guiler expr)
     (`dbx (concat "print " expr))

[-- Attachment #2.3: Type: text/html, Size: 233 bytes --]

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

"Andrew L. Moore" <slewsys@gmail.com> writes:

> The LLVM source repository includes a patch adding basic lldb support
> to gud.el. The patch adapted to current gud.el (Github-mirror commit
> 7e09ef09a479731d01b1ca46e94ddadd73ac98e3) is attached below. Although
> I’m not affiliated with llvm.org, I’d be interested to know if and how
> this might be accepted into the Emacs distribution, RMS’s opinion of
> LLVM notwithstanding. Thank you!

The general position with regard to proprietary software (which LLVM
isn't, but there can be proprietary variants) is that we don't want to
support functionality that isn't supported by free software in order not
to provide an incentive to use non-free software.

Now anything supporting the free LLVM variant does not force one to use
non-free software, so the rule does not really apply.  However, we still
want to have people prefer GNU software over GPLed software, and GPLed
software over non-copylefted software, so this case may be considered
somewhat analogous.

In this particular case, gdb is already fully supported.  So my opinion
would be, for what it's worth, that "basic lldb support" should be
unproblematic as long as it does not involve functionality absent from
gud-gdb.

Naturally, it's best to wait what Richard has to say on that.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Stefan Monnier]

> The LLVM source repository includes a patch adding basic lldb support
> to gud.el. The patch adapted to current gud.el (Github-mirror commit
> 7e09ef09a479731d01b1ca46e94ddadd73ac98e3) is attached below. Although
> I’m not affiliated with llvm.org, I’d be interested to know if and how
> this might be accepted into the Emacs distribution, RMS’s opinion of
> LLVM notwithstanding. Thank you!

Thanks, Andrew.  I'd be happy to incorporate such a patch.
I took a quick look at the code, and seen from afar, there's no problem
with it, so all that is really needed is to clear the copyright status
of this code.

IOW, we need to know who is/are the author(s) (contributors of less than
about 15 lines of code don't need to be accounted for), and then make
sure they have signed a copyright assignment.


        Stefan


> diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el
> index 42c5b20..7f2e9c0 100644
> --- a/lisp/progmodes/gud.el
> +++ b/lisp/progmodes/gud.el
> @@ -35,7 +35,7 @@
>  ;; kluge with the gud-xdb-directories hack producing gud-dbx-directories.
>  ;; Derek L. Davies <ddavies@world.std.com> added support for jdb (Java
>  ;; debugger.)  Jan Nieuwenhuizen added support for the Guile REPL (Guile
> -;; debugger).
> +;; debugger). llvm.org added support for lldb.
 
>  ;;; Code:
 
> @@ -56,7 +56,7 @@
 
>  (defgroup gud nil
>    "The \"Grand Unified Debugger\" interface.
> -Supported debuggers include gdb, sdb, dbx, xdb, perldb,
> +Supported debuggers include lldb, gdb, sdb, dbx, xdb, perldb,
>  pdb (Python), and jdb."
>    :group 'processes
>    :group 'tools)
> @@ -141,12 +141,12 @@ Used to gray out relevant toolbar icons.")
>  			       (display-graphic-p)
>  			       (fboundp 'x-show-tip))
>  		  :visible (memq gud-minor-mode
> -				'(gdbmi guiler dbx sdb xdb pdb))
> +				'(lldb gdbmi guiler dbx sdb xdb pdb))
>  	          :button (:toggle . gud-tooltip-mode))
>      ([refresh]	"Refresh" . gud-refresh)
>      ([run]	menu-item "Run" gud-run
>                    :enable (not gud-running)
> -		  :visible (memq gud-minor-mode '(gdbmi gdb dbx jdb)))
> +		  :visible (memq gud-minor-mode '(lldb gdbmi gdb dbx jdb)))
>      ([go]	menu-item (if (bound-and-true-p gdb-active-process)
>  			      "Continue" "Run") gud-go
>  		  :visible (and (eq gud-minor-mode 'gdbmi)
> @@ -164,18 +164,18 @@ Used to gray out relevant toolbar icons.")
>      ([tbreak]	menu-item "Temporary Breakpoint" gud-tbreak
>                    :enable (not gud-running)
>  		  :visible (memq gud-minor-mode
> -				'(gdbmi gdb sdb xdb)))
> +				'(lldb gdbmi gdb sdb xdb)))
>      ([break]	menu-item "Set Breakpoint" gud-break
>                    :enable (not gud-running)
>  		  :visible (gud-tool-bar-item-visible-no-fringe))
>      ([up]	menu-item "Up Stack" gud-up
>  		  :enable (not gud-running)
>  		  :visible (memq gud-minor-mode
> -				 '(gdbmi gdb guiler dbx xdb jdb pdb)))
> +				 '(lldb gdbmi gdb guiler dbx xdb jdb pdb)))
>      ([down]	menu-item "Down Stack" gud-down
>  		  :enable (not gud-running)
>  		  :visible (memq gud-minor-mode
> -				 '(gdbmi gdb guiler dbx xdb jdb pdb)))
> +				 '(lldb gdbmi gdb guiler dbx xdb jdb pdb)))
>      ([pp]	menu-item "Print S-expression" gud-pp
>                    :enable (and (not gud-running)
>  				  (bound-and-true-p gdb-active-process))
> @@ -187,7 +187,7 @@ Used to gray out relevant toolbar icons.")
>  			      "Dump object"
>  			    "Print Dereference") gud-pstar
>                    :enable (not gud-running)
> -		  :visible (memq gud-minor-mode '(gdbmi gdb jdb)))
> +		  :visible (memq gud-minor-mode '(lldb gdbmi gdb jdb)))
>      ([print]	menu-item "Print Expression" gud-print
>                    :enable (not gud-running))
>      ([watch]	menu-item "Watch Expression" gud-watch
> @@ -196,13 +196,13 @@ Used to gray out relevant toolbar icons.")
>      ([finish]	menu-item "Finish Function" gud-finish
>                    :enable (not gud-running)
>  		  :visible (memq gud-minor-mode
> -				 '(gdbmi gdb guiler xdb jdb pdb)))
> +				 '(lldb gdbmi gdb guiler xdb jdb pdb)))
>      ([stepi]	menu-item "Step Instruction" gud-stepi
>                    :enable (not gud-running)
> -		  :visible (memq gud-minor-mode '(gdbmi gdb dbx)))
> +		  :visible (memq gud-minor-mode '(lldb gdbmi gdb dbx)))
>      ([nexti]	menu-item "Next Instruction" gud-nexti
>                    :enable (not gud-running)
> -		  :visible (memq gud-minor-mode '(gdbmi gdb dbx)))
> +		  :visible (memq gud-minor-mode '(lldb gdbmi gdb dbx)))
>      ([step]	menu-item "Step Line" gud-step
>                    :enable (not gud-running))
>      ([next]	menu-item "Next Line" gud-next
> @@ -237,7 +237,7 @@ Used to gray out relevant toolbar icons.")
>  	:visible (not (eq gud-minor-mode 'gdbmi)))
>         ([menu-bar run] menu-item
>  	,(propertize "run" 'face 'font-lock-doc-face) gud-run
> -	:visible (memq gud-minor-mode '(gdbmi gdb dbx jdb)))
> +	:visible (memq gud-minor-mode '(lldb gdbmi gdb dbx jdb)))
>         ([menu-bar go] menu-item
>  	,(propertize " go " 'face 'font-lock-doc-face) gud-go
>  	:visible (and (eq gud-minor-mode 'gdbmi)
> @@ -356,6 +356,7 @@ are interpreted specially if present.  These are:
>    %l -- Number of current source line.
>    %e -- Text of the C lvalue or function-call expression surrounding point.
>    %a -- Text of the hexadecimal address surrounding point.
> +  %b -- Text of the most recently created breakpoint id.
>    %p -- Prefix argument to the command (if any) as a number.
>    %c -- Fully qualified class name derived from the expression
>          surrounding point (jdb only).
> @@ -964,6 +965,131 @@ SKIP is the number of chars to skip on each line, it defaults to 0."
 
>  \f
>  ;; ======================================================================
> +;; lldb functions
> +
> +;; History of argument lists passed to lldb.
> +(defvar gud-lldb-history nil)
> +
> +;; Keeps track of breakpoint created.  In the following case, the id is "1".
> +;; It is used to implement temporary breakpoint.
> +;; (lldb) b main.c:39
> +;; breakpoint set --file 'main.c' --line 39
> +;; Breakpoint created: 1: file ='main.c', line = 39, locations = 1
> +(defvar gud-breakpoint-id nil)
> +
> +(defun lldb-extract-breakpoint-id (string)
> +  ;; Search for "Breakpoint created: \\([^:\n]*\\):" pattern.
> +  (if (string-match "Breakpoint created: \\([^:\n]*\\):" string)
> +      (progn
> +        (setq gud-breakpoint-id (match-string 1 string))
> +        (message "breakpoint id: %s" gud-breakpoint-id)))
> +)
> +
> +(defun gud-lldb-marker-filter (string)
> +  (setq gud-marker-acc
> +	(if gud-marker-acc (concat gud-marker-acc string) string))
> +  (lldb-extract-breakpoint-id gud-marker-acc)
> +  (let (start)
> +    ;; Process all complete markers in this chunk
> +    (while (or
> +            ;; (lldb) r
> +            ;; Process 15408 launched: '/Volumes/data/lldb/svn/trunk/test/conditional_break/a.out' (x86_64)
> +            ;; (lldb) Process 15408 stopped
> +            ;; * thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread
> +            (string-match " at \\([^:\n]*\\):\\([0-9]*\\), stop reason = .*\n"
> +                          gud-marker-acc start)
> +            ;; (lldb) frame select -r 1
> +            ;; frame #1: 0x0000000100000e09 a.out`main + 25 at main.c:44
> +            (string-match "\nframe.* at \\([^:\n]*\\):\\([0-9]*\\)\n"
> +                           gud-marker-acc start))
> +      (setq gud-last-frame
> +            (cons (match-string 1 gud-marker-acc)
> +                  (string-to-number (match-string 2 gud-marker-acc)))
> +            start (match-end 0)))
> +
> +    ;; Search for the last incomplete line in this chunk
> +    (while (string-match "\n" gud-marker-acc start)
> +      (setq start (match-end 0)))
> +
> +    ;; If we have an incomplete line, store it in gud-marker-acc.
> +    (setq gud-marker-acc (substring gud-marker-acc (or start 0))))
> +  string)
> +
> +;; Keeps track of whether the Python lldb_oneshot_break function definition has
> +;; been exec'ed.
> +(defvar lldb-oneshot-break-defined nil)
> +
> +;;;###autoload
> +(defun lldb (command-line)
> +  "Run lldb on program FILE in buffer *gud-FILE*.
> +The directory containing FILE becomes the initial working directory
> +and source-file directory for your debugger."
> +  (interactive (list (gud-query-cmdline 'lldb)))
> +
> +  (gud-common-init command-line nil 'gud-lldb-marker-filter)
> +  (set (make-local-variable 'gud-minor-mode) 'lldb)
> +  (setq lldb-oneshot-break-defined nil)
> +
> +  (gud-def gud-listb  "breakpoint list"
> +                      "l"    "List all breakpoints.")
> +  (gud-def gud-bt     "thread backtrace"
> +                      "b"    "Show stack for the current thread.")
> +  (gud-def gud-bt-all "thread backtrace all"
> +                      "B"    "Show stacks for all the threads.")
> +
> +  (gud-def gud-break  "breakpoint set -f %f -l %l"
> +                      "\C-b" "Set breakpoint at current line.")
> +  (gud-def gud-tbreak
> +	   (progn (gud-call "breakpoint set -f %f -l %l")
> +                  (sit-for 1)
> +                  (if (not lldb-oneshot-break-defined)
> +                      (progn
> +                        ;; The "\\n"'s are required to escape the newline chars
> +                        ;; passed to the lldb process.
> +                        (gud-call (concat "script exec \"def lldb_oneshot_break(frame, bp_loc):\\n"
> +                                                        "    target=frame.GetThread().GetProcess().GetTarget()\\n"
> +                                                        "    bp=bp_loc.GetBreakpoint()\\n"
> +                                                        "    print 'Deleting oneshot breakpoint:', bp\\n"
> +                                                        "    target.BreakpointDelete(bp.GetID())\""))
> +                        (sit-for 1)
> +                        ;; Set the flag since Python knows about the function def now.
> +                        (setq lldb-oneshot-break-defined t)))
> +                  (gud-call "breakpoint command add -p %b -o 'lldb_oneshot_break(frame, bp_loc)'"))
> +	              "\C-t" "Set temporary breakpoint at current line.")
> +  (gud-def gud-remove "breakpoint clear -f %f -l %l"
> +                      "\C-d" "Remove breakpoint at current line")
> +  (gud-def gud-step   "thread step-in"
> +                      "\C-s" "Step one source line with display.")
> +  (gud-def gud-stepi  "thread step-inst"
> +                      "\C-i" "Step one instruction with display.")
> +  (gud-def gud-next   "thread step-over"
> +                      "\C-n" "Step one line (skip functions).")
> +  (gud-def gud-nexti  "thread step-inst-over"
> +                      nil    "Step one instruction (skip functions).")
> +  (gud-def gud-cont   "process continue"
> +                      "\C-r" "Continue with display.")
> +  (gud-def gud-finish "thread step-out"
> +                      "\C-f" "Finish executing current function.")
> +  (gud-def gud-up     "frame select -r %p"
> +                      "<"    "Up 1 stack frame.")
> +  (gud-def gud-down   "frame select -r -%p"
> +                      ">"    "Down 1 stack frame.")
> +  (gud-def gud-print  "expression -- %e"
> +                      "\C-p" "Evaluate C expression at point.")
> +  (gud-def gud-pstar  "expression -- *%e"
> +                      nil    "Evaluate C dereferenced pointer expression at point.")
> +  (gud-def gud-run    "run"
> +                      nil    "Run the program.")
> +  (gud-def gud-stop-subjob    "process kill"
> +                      nil    "Stop the program.")
> +
> +  (setq comint-prompt-regexp  "\\(^\\|\n\\)\\*")
> +  (setq paragraph-start comint-prompt-regexp)
> +  (run-hooks 'lldb-mode-hook)
> +  )
> +
> +\f
> +;; ======================================================================
>  ;; sdb functions
 
>  ;; History of argument lists passed to sdb.
> @@ -2499,9 +2625,10 @@ gud, see `gud-mode'."
>    "Major mode for interacting with an inferior debugger process.
 
>     You start it up with one of the commands M-x gdb, M-x sdb, M-x dbx,
> -M-x perldb, M-x xdb, or M-x jdb.  Each entry point finishes by executing a
> -hook; `gdb-mode-hook', `sdb-mode-hook', `dbx-mode-hook',
> -`perldb-mode-hook', `xdb-mode-hook', or `jdb-mode-hook' respectively.
> +M-x perldb, M-x xdb, M-x jdb, or M-x lldb.  Each entry point finishes by
> +executing a hook; `gdb-mode-hook', `sdb-mode-hook', `dbx-mode-hook',
> +`perldb-mode-hook', `xdb-mode-hook', `jdb-mode-hook', or `lldb-mode-hook'
> +respectively.
 
>  After startup, the following commands are available in both the GUD
>  interaction buffer and any source buffer GUD visits due to a breakpoint stop
> @@ -2531,7 +2658,7 @@ Under gdb, sdb and xdb, \\[gud-tbreak] behaves exactly like \\[gud-break],
>  except that the breakpoint is temporary; that is, it is removed when
>  execution stops on it.
 
> -Under gdb, dbx, and xdb, \\[gud-up] pops up through an enclosing stack
> +Under gdb, dbx, xdb, and lldb, \\[gud-up] pops up through an enclosing stack
>  frame.  \\[gud-down] drops back down through one.
 
>  If you are using gdb or xdb, \\[gud-finish] runs execution to the return from
> @@ -2858,7 +2985,7 @@ Obeying it means displaying in another window the specified file and line."
>  	result)
>      (while (and str
>  		(let ((case-fold-search nil))
> -		  (string-match "\\([^%]*\\)%\\([adefFlpc]\\)" str)))
> +		  (string-match "\\([^%]*\\)%\\([abdefFlpc]\\)" str)))
>        (let ((key (string-to-char (match-string 2 str)))
>  	    subst)
>  	(cond
> @@ -2886,6 +3013,8 @@ Obeying it means displaying in another window the specified file and line."
>  	  (setq subst (gud-find-expr)))
>  	 ((eq key ?a)
>  	  (setq subst (gud-read-address)))
> +	 ((eq key ?b)
> +	  (setq subst gud-breakpoint-id))
>  	 ((eq key ?c)
>  	  (setq subst
>                  (gud-find-class
> @@ -3520,6 +3649,7 @@ With arg, dereference expr if ARG is positive, otherwise do not dereference."
>  (defun gud-tooltip-print-command (expr)
>    "Return a suitable command to print the expression EXPR."
>    (pcase gud-minor-mode
> +    (`lldb (concat "expression -o -- \"" expr "\""))
>      (`gdbmi (concat "-data-evaluate-expression \"" expr "\""))
>      (`guiler expr)
>      (`dbx (concat "print " expr))

Re: Contributing LLVM.org patches to gud.el

[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 LLVM source repository includes a patch adding basic lldb support to gud.el.

It looks like there is a systematic effort to attack GNU packages.
The GNU Project needs to respond strategically, which means not by
having each GNU package cooperate with each attack.  For now, please
do NOT install this change.

I will talk with Moore about this, off the list, to find out more
about the situation.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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 LLVM source repository includes a patch adding basic lldb
>   > support to gud.el.
>
> It looks like there is a systematic effort to attack GNU packages.

I cannot see the support of gud.el from LLVM as part of a systematic
effort to attack GNU packages.

> The GNU Project needs to respond strategically, which means not by
> having each GNU package cooperate with each attack.  For now, please
> do NOT install this change.

I cannot see how it differs from us supporting MS Windows and MacOSX in
Emacs.  The metric we employed here was not to install support for any
functionality restricted to the use of those operating systems.

But "basic lldb support to gud.el", our generic debugger interface, does
not sound anything like that.

> I will talk with Moore about this, off the list, to find out more
> about the situation.

Sure, it makes sense to figure out whether the summary is accurate.  If
it is, however, I do not find my initial assessment in agreement with
yours.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[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 cannot see how it differs from us supporting MS Windows and MacOSX in
  > Emacs.  The metric we employed here was not to install support for any
  > functionality restricted to the use of those operating systems.

These are not similar cases.  Neither Windows nor MacOS was intended
to push major GNU packages out of use.  What I see here appears
possibly to be exactly that.  Whether that is the case is what I want
to find out.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Stefan Monnier]

> These are not similar cases.  Neither Windows nor MacOS was intended
> to push major GNU packages out of use.

You sound paranoid.

LLVM is not meant to kill GCC more than Windows is meant to kill GNU/Linux.

Yes, they compete.  But the intention is not to replace one with
another.  The intention of people working on LLVM is to solve their
immediate problem, and for one reason or another, they don't consider
GCC as a good way to solve their problem.

Nobody would benefit from killing GCC, really.  Not even control freaks
who think the GPL is the plague.


        Stefan

Re: Contributing LLVM.org patches to gud.el

[Helmut Eller]

On Fri, Feb 06 2015, Stefan Monnier wrote:

> Yes, they compete.  But the intention is not to replace one with
> another.  The intention of people working on LLVM is to solve their
> immediate problem, and for one reason or another, they don't consider
> GCC as a good way to solve their problem.
>
> Nobody would benefit from killing GCC, really.  Not even control freaks
> who think the GPL is the plague.

I wonder if there is enough room for more than one competitor.  If
evolutionary principles apply to software, then GCC might indeed be in
danger, because currently it does look like LLVM is more "fit", produces
(much) more "offspring" and generally takes resources away from GCC.

It also worries me that OpenGL drivers use LLVM to compile shader
programs, making LLVM quite an important part of the graphics stack.
And GCC has AFAIK no backend for any GPU.

Helmut

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Fri, Feb 06 2015, Stefan Monnier wrote:
>
>> Yes, they compete.  But the intention is not to replace one with
>> another.  The intention of people working on LLVM is to solve their
>> immediate problem, and for one reason or another, they don't consider
>> GCC as a good way to solve their problem.
>>
>> Nobody would benefit from killing GCC, really.  Not even control freaks
>> who think the GPL is the plague.
>
> I wonder if there is enough room for more than one competitor.
>
> If evolutionary principles apply to software, then GCC might indeed be
> in danger, because currently it does look like LLVM is more "fit",
> produces (much) more "offspring" and generally takes resources away
> from GCC.

If you want to argue evolutionary biology, it makes no sense to muddle
together all niches.  Humans don't need to compete with polar bears and
penguins.

GCC has been supplanted by LLVM as the compiler of choice for operating
systems in the BSD camp, yes.  The reasons are not technical.  Neither
are they substantially a desire to get get rid of software freedom but
rather a desire to cater to software freedom in the BSD style.

GCC has been a thorn in the side of the BSD camp that they are getting
rid of by converting to LLVM.  It has been a thorn in the side of the
BSD camp since GCC is licensed differently than the rest of their
software, and they are not in control of either development or licensing
of GCC.

The GPL and the GNU project is the stronghold of software freedom.  But
we are not going to do software freedom a favor by raiding and burning
down ourselves every fair happening outside of the protection of our
castle walls.  Our concern has to be to keep the state inside of the
castle walls both secure and welcoming.

Our past successes in matching both goals have contributed to and
enabled the rise of the BSD-based software universes and cultures.  That
there are significant bodies of software where the principal development
and dissemination of software is not under proprietary control and
interests is a result of the GNU project's guarantees of freedom and
openness moved development forward in a way that was hard to match with
closed and proprietary developments.

If we try to close down every cooperation with non-GNU free software, we
are sacrificing our goals for the sake of our temples.  Which is not
unusual: the most bloody and prolonged wars have been between people
praying to the same God in different temples and with different rites.

But there are no winners in that kind of war.

> It also worries me that OpenGL drivers use LLVM to compile shader
> programs, making LLVM quite an important part of the graphics stack.
> And GCC has AFAIK no backend for any GPU.

GCC is unsuitable for compilers intended to keep trade secrets hidden
away like those of most modern GPUs.  That's a feature, not a bug.
I don't see that we should strive to change that in any manner.  It
certainly is annoying that LLVM provides those GPU vendors with a
compiler they can freely get and lock down.  But they were bound to
route around GCC in some manner anyway.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Helmut Eller]

On Sat, Feb 07 2015, David Kastrup wrote:

> If you want to argue evolutionary biology, it makes no sense to muddle
> together all niches.  Humans don't need to compete with polar bears and
> penguins.

GCC and LLVM are obviously competitors.

> The GPL and the GNU project is the stronghold of software freedom.  But
> we are not going to do software freedom a favor by raiding and burning
> down ourselves every fair happening outside of the protection of our
> castle walls.  Our concern has to be to keep the state inside of the
> castle walls both secure and welcoming.

Inviting trojan horses into the GNU castle is probably not going to help
GCC.  Well, maybe in some indirect way because then GCC has to improve
to stay competitive.

Helmut

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Sat, Feb 07 2015, David Kastrup wrote:
>
>> If you want to argue evolutionary biology, it makes no sense to muddle
>> together all niches.  Humans don't need to compete with polar bears and
>> penguins.
>
> GCC and LLVM are obviously competitors.
>
>> The GPL and the GNU project is the stronghold of software freedom.  But
>> we are not going to do software freedom a favor by raiding and burning
>> down ourselves every fair happening outside of the protection of our
>> castle walls.  Our concern has to be to keep the state inside of the
>> castle walls both secure and welcoming.
>
> Inviting trojan horses into the GNU castle is probably not going to
> help GCC.

We are not talking about letting the enemies of free software in but
rather those who don't shoot the enemies at sight.

> Well, maybe in some indirect way because then GCC has to improve to
> stay competitive.

Improving GCC is a worthwhile goal anyway.  Making it worse in the hope
that it will make other people suffer more than us is a suicidal
strategy in the long run.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > If we try to close down every cooperation with non-GNU free software, we
  > are sacrificing our goals for the sake of our temples.

I agree.  But is anyone proposing that?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Stephen J. Turnbull]

Richard Stallman writes:

 >   > If we try to close down every cooperation with non-GNU free
 >   > software, we are sacrificing our goals for the sake of our
 >   > temples.
 > 
 > I agree.  But is anyone proposing that?

Did anyone say it was explicitly proposed?

What is feared is that your reflexive opposition to initiatives that
you admit you don't understand ("I must study ... don't rush me")
merely because they involve LLVM *are* having a chilling effect.  And
if you can oppose something as innocuous as adding to ELPA *existing*
software (which is *already widely distributed*) merely because it
involves LLVM, that chilling effect could effectively become a freeze,
deterring *many* potential contributors and alienating users who
(think they) need the features offered by LLVM that the GNU toolchain
doesn't have.

The problem (if there really is one) is that gcc and gdb have fallen
behind (according to the testimony of a few developers).  Why waste
time in spiteful attacks on Emacs users and developers (who either
won't use lldb on principle, or who can easily add Emacs support
locally if they do use it)?  Shouldn't you be concentrating on finding
strategies for GCC and the rest of the core toolchain to recover their
technical and social leadership (not to mention determining if they
really have completely lost it)?  That's the hard problem, and one
that requires your global view of the GNU Project that, say, Stefan
does not have.

On the other hand, Stefan is quite capable of applying the simple
traditional rule of "don't advantage non-GNU software" within Emacs.

In-opposition-loyal-ly y'rs,

Re: Contributing LLVM.org patches to gud.el

[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 feared is that your reflexive opposition to initiatives that
  > you admit you don't understand ("I must study ... don't rush me")
  > merely because they involve LLVM *are* having a chilling effect.

You can't get any _less_ reflexive than saying "I want to study this;
don't rush me."  Anyone who considers that "reflexive" has his eyes
and ears shut.  We might even wonder if he is being reflexive.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Stephen J. Turnbull]

Richard Stallman writes:

 > You can't get any _less_ reflexive than saying "I want to study
 > this; don't rush me."  Anyone who considers that "reflexive" has
 > his eyes and ears shut.  We might even wonder if he is being
 > reflexive.

I've been watching you hold up initiatives in Emacs and other free
software projects while you study the issues for 20 years now.  It's
hardly reflexive to say *now* that your behavior looks reflexive.

And yes, "I want to study this" *can be*, and *often is*, a reflexive
response to an unpleasant turn of events.  That's part of what is
meant by "paralysis by analysis", and by "micromanagement".  Does this
particular case involve hazards that require such study?  Pretty
clearly I'm not the only person who thinks the answer is "no".

A clearly non-reflexive response would be "Yet another case where I
have to decide something that's a rather small matter in itself.
Maybe it's time to think about an alternative decision-making process.
Or better education of the troops, so that they can make these
decisions well enough without me, and I can concentrate on developing
strategies that *effectively* address too-permissive licensing threats
to GNU, and on lobbying that requires someone of my stature in the
movement."

Re: Contributing LLVM.org patches to gud.el

[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 watching you hold up initiatives in Emacs and other free
  > software projects while you study the issues for 20 years now.  It's
  > hardly reflexive to say *now* that your behavior looks reflexive.

I can't argue with your perceptions, even if they are
self-contradictory.

  > And yes, "I want to study this" *can be*, and *often is*, a reflexive
  > response to an unpleasant turn of events.

The decision to think about something consciously always arises from
unconscious processing.  In this case, I said "Hold your horses" to delay
action and provide time for a decision.

I'm now discussing a few questions privately with the GDB developers.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > If we try to close down every cooperation with non-GNU free software, we
>   > are sacrificing our goals for the sake of our temples.
>
> I agree.  But is anyone proposing that?

GCC's approach to plugins took years to do exactly in order not to
interface with software not under the GPL.  A generic dynamic library
loading facility to Emacs has been in discussion and vetoed for decades.
Somewhat amusingly, the only working run-time dynamic library loading
that I know of in Emacs is the loading of image libraries (free ones, of
course) under Windows.  At the current point of time we are seeing about
a year of roadblocks on trying to get Emacs and GCC to communicate about
various issues.  While the more recent batch of blocking LLVM
cooperation (which is non-GNU free software) has started with blocking
LLVM on the grounds that GCC should go first, the subsequent attempts to
integrate GCC first have been blocked on grounds that this would open
too many paths to interoperating with LLVM or proprietary compilers.

So yes: you _are_ very much sacrificing the interoperation of GNU
software on the grounds that it would also enable the interoperation
with software that is either unfree or "too free".  Whether or not this
is "proposed", it is being done.

As long as our only weapon is copyright, we cannot block interoperation
except by blocking all interfacing.  If we want to block interoperation
selectively, the only meaningful way to do that is to start hacking
patent law in a similar manner to how the GPL hacked copyright law:
collecting patents and providing public licenses.  Patents reach beyond
interoperation.  Which is part of what makes software patents a bad idea
in the first place.

At any rate: crippling GNU until we reduce open-ended interoperation to
the degree where it becomes infeasible without touching
copyright-propagating parts is a strategy for obsolescence.

As long as our sole weapon is copyright, we need to focus on using it in
a manner where it hurts us less than our opponents.

Part of doing that is to have feasible strategies, and easy and
effective rules that can be applied by project managers with confidence.
The GNU project is far too large, and interoperation far too important
that it is even feasible to route all the decision-making through the
"Richard oracle" with unknown outcome.  Top-level decisions are a scarce
resource, so the project cannot afford this process frequently.

Partly one gets the impression that you think if you wait long enough,
the problem will go away.  But what rather tends to go away is the
window of opportunity.

We did our part in making the creation of LLVM attractive to a diverse
set of people because we decided that catering to their causes would
have been disruptive to our own goals.  The rise of LLVM or other
compiler technologies was an _expected_ consequence of our actions:
compiler technology is not an inaccessible art, so it was clear that
alternatives to GCC would get developed and maintained eventually.

What happens now is burning down the barn after the mule has bolted.
And it's not like we didn't open the door, beat it and yell for it to go
away.

More by accident than anything else I have been in some "IT planning for
startups" talk on a conference.  The speaker did a lot to explain how
import contingency plans were when things went wrong.  But what he also
said: "the worst mistake a manager can commit is to be unprepared
catering for the eventuality of success".  If you are not prepared for
dealing with success, where is the point in even starting?

So we worked on making GCC a bad choice for proprietary vendors.  What
do they do?  They manage to unite an industry-spanning coalition of
different parties including academia into creating a free software
compiler framework.  Free to the degree that we could just take it, slap
the GPL on it and distribute our own version of it (assuming we were
prepared to dealing with pissing everybody off in the process).

So what's our reaction to our and GCC's role in causing a large-scale
industry cooperation creating a free compiler framework?

Panic.  We are not prepared to deal with people doing on their own terms
what we have fought to happen for decades.  So now we try to fight those
in our midst who want to make use of what we have fought for.

And since LLVM is relicensable as GPL if anybody bothered to, the only
effective means to "fight" LLVM is by necessity effective in fighting
GPLed software in just the same manner.

It seems sort of pointless to be fighting our spoils because they were
given to us in the wrong kind of ceremony.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Stefan Monnier]

> So yes: you _are_ very much sacrificing the interoperation of GNU
> software on the grounds that it would also enable the interoperation
> with software that is either unfree or "too free".  Whether or not this
> is "proposed", it is being done.

Very mush so, indeed.  The recent thread about a GCC plugin that would
export an AST for Emacs's use being a prime example.

All this anti-LLVM shenanigans is actually very harmful to Emacs and GCC
and only benefits non-GNU software.


        Stefan

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > All this anti-LLVM shenanigans is actually very harmful to Emacs and GCC
  > and only benefits non-GNU software.

You're speaking from assumptions, not facts.  I think all three of those
claims are mistaken.

In particular, the only harm to Emacs is that I've been unable to
study the GCC AST issue for a whole month.  Please do not exaggerate.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > All this anti-LLVM shenanigans is actually very harmful to Emacs
>   > and GCC and only benefits non-GNU software.
>
> You're speaking from assumptions, not facts.  I think all three of those
> claims are mistaken.
>
> In particular, the only harm to Emacs is that I've been unable to
> study the GCC AST issue for a whole month.

It's been around a decade before that.  It's not like making Clang/LLVM
irrelevant is still on our table.  That would have been about five years
ago.

In my book, more harm has been done by making volunteers give up in
disgust on doing useful work on Emacs, GCC, and their integration.

At any rate, it stresses my point that we don't have enough Richard to
reasonably cover all of GNU's decision-making needs without some hard
and fast rules.

And to me some hard and fast rules for interoperation seem feasible:
after all, we can hardly "defend" ourselves against software that is
licensed in GPL-compatible ways.  Any measure against such software will
equally well keep GPLed/GNU software at bay.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Stefan Monnier]

> In particular, the only harm to Emacs is that I've been unable to
> study the GCC AST issue for a whole month.  Please do not exaggerate.

You seem not to have even understood that your insistence has compelled
David Engster to stop working on GCC-based code completion support
for CEDET.

So, yes, this is harmful to Emacs.
This currently discussion itself might prove similarly harmful in turning
other people off.

Tho, w.r.t to code-completion support, I guess the end result will
simply be that people will go back to working on Clang-based support
since you oppose GCC-based support: the only point of working on
GCC-based support was to satisfy your anti-LLVM stance.  But if even
that is not good enough, then there's no point trying to satisfy you,
and working on Clang-based completion is a much better course since the
tool is much better suited for the task.


        Stefan "welcoming patches to add Clang-based completion in Emacs"

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 09 Feb 2015 21:40:20 -0500
> Cc: dak@gnu.org, eller.helmut@gmail.com, emacs-devel@gnu.org
> 
> > In particular, the only harm to Emacs is that I've been unable to
> > study the GCC AST issue for a whole month.  Please do not exaggerate.
> 
> You seem not to have even understood that your insistence has compelled
> David Engster to stop working on GCC-based code completion support
> for CEDET.

FWIW, I think David made a mistake when he gave up.  I faced a similar
disheartening intention (for quite different, but still political)
reasons when I worked on bidi support.  I decided to disregard and
proceed, and the result is before your eyes.

There's nothing like working code to convince people.  Free Software
is about freedom of developers as well.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Mon, 09 Feb 2015 21:40:20 -0500
>> Cc: dak@gnu.org, eller.helmut@gmail.com, emacs-devel@gnu.org
>> 
>> > In particular, the only harm to Emacs is that I've been unable to
>> > study the GCC AST issue for a whole month.  Please do not exaggerate.
>> 
>> You seem not to have even understood that your insistence has compelled
>> David Engster to stop working on GCC-based code completion support
>> for CEDET.
>
> FWIW, I think David made a mistake when he gave up.

Running out of motivation is not a choice.  And anyway, Richard
explicitly stated that he wanted lots of time for his resentment over
the discussion to abate before he would even start discussing the issue
with people he trusts.  So it will be a considerable amount of time
before David even has a chance of being informed whether his work will
end up in the wastebin.  That sounds like a solid reason to rather work
on something else to me.

> I faced a similar disheartening intention (for quite different, but
> still political) reasons when I worked on bidi support.  I decided to
> disregard and proceed, and the result is before your eyes.
>
> There's nothing like working code to convince people.

As far as I remember, company-mode had working code for LLVM-based
completion.  And we are currently just seeing a veto on integration of
working initial LLDB support into gud.el.

> Free Software is about freedom of developers as well.

Not at its core.  But it would make for a better fit.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  rms@gnu.org,  eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 10 Feb 2015 09:59:44 +0100
> 
> > FWIW, I think David made a mistake when he gave up.
> 
> Running out of motivation is not a choice.

It's not an objective condition, either.

> And anyway, Richard explicitly stated that he wanted lots of time
> for his resentment over the discussion to abate before he would even
> start discussing the issue with people he trusts.  So it will be a
> considerable amount of time before David even has a chance of being
> informed whether his work will end up in the wastebin.  That sounds
> like a solid reason to rather work on something else to me.

It's clearly a judgment call, not something clear-cut or carved in
stone.  I gave you my assessment of the decision.  I don't blame
anyone, least of all David himself, I just wish he would find
resources to persevere.

> > I faced a similar disheartening intention (for quite different, but
> > still political) reasons when I worked on bidi support.  I decided to
> > disregard and proceed, and the result is before your eyes.
> >
> > There's nothing like working code to convince people.
> 
> As far as I remember, company-mode had working code for LLVM-based
> completion.

So?  It's working code, isn't it?  Anyone can use it, can't they?

> And we are currently just seeing a veto on integration of
> working initial LLDB support into gud.el.

Maybe I need new glasses, but I see no veto.  A request to hold on is
not a veto.

And, FWIW, from my POV supporting LLDB is not an important issue,
certainly nowhere as important as making Emacs more like modern IDEs.
When LLDB gets anywhere near GDB in functionality and usability, let
alone surpasses it, maybe then I might get interested.  For now, it's
a niche debugger, not unlike dbx.  Why should we care so much if LLDB
support will land today, next week, or next year?  We shouldn't burn
so much energy on even discussing it.

> > Free Software is about freedom of developers as well.
> 
> Not at its core.

Yes, at its core: the freedom to change the code requires a developer
who can actually do that.  We the developers are users of that freedom
just like any other user.  Who do you think will be the most frequent
users of an IDE-like Emacs, if not us?  Who needs smart completion,
refactoring, and other niceties, if not us?

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>

>> As far as I remember, company-mode had working code for LLVM-based
>> completion.
>
> So?  It's working code, isn't it?  Anyone can use it, can't they?

The difference between a package being in ELPA and having to be
installed manually significantly changes its adoption and audience.

>> And we are currently just seeing a veto on integration of
>> working initial LLDB support into gud.el.
>
> Maybe I need new glasses, but I see no veto.

Maybe you need new glasses.

> A request to hold on is not a veto.

It's not a _final_ veto.  But it is vetoing inclusion for now.

> And, FWIW, from my POV supporting LLDB is not an important issue,
> certainly nowhere as important as making Emacs more like modern IDEs.

Uh, there is a connection.  Because modern IDEs tend to have useful
program information when debugging instead of (optimized out).

> When LLDB gets anywhere near GDB in functionality and usability, let
> alone surpasses it, maybe then I might get interested.

Seems you missed where people stated that its willingness to talk about
values that can only be deduced by cooperation with the compiler was
making a crucial difference in usability over gdb.

At any rate, you seem to be _totally_ on the other side of Richard on
this one.  You want to start thinking about LLDB when it is getting more
useful than GDB, he wants to stop people from thinking about LLDB when
it is getting more useful than GDB.

> For now, it's a niche debugger, not unlike dbx.  Why should we care so
> much if LLDB support will land today, next week, or next year?  We
> shouldn't burn so much energy on even discussing it.

Well, GNU does not turn on a dime.  So there is nothing wrong with
thinking ahead.

>> > Free Software is about freedom of developers as well.
>> 
>> Not at its core.
>
> Yes, at its core: the freedom to change the code requires a developer
> who can actually do that.

<URL:http://www.gnu.org/gnu/manifesto.html>

You'll find that wherever conflicts of interest between users and
programmers are considered, Richard puts the users' interests first.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org,  eller.helmut@gmail.com,  monnier@iro.umontreal.ca,  rms@gnu.org
> Date: Tue, 10 Feb 2015 17:41:25 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Kastrup <dak@gnu.org>
> 
> >> As far as I remember, company-mode had working code for LLVM-based
> >> completion.
> >
> > So?  It's working code, isn't it?  Anyone can use it, can't they?
> 
> The difference between a package being in ELPA and having to be
> installed manually significantly changes its adoption and audience.

The importance and the functionality of a package also plays a
significant role in its adoption.

> > And, FWIW, from my POV supporting LLDB is not an important issue,
> > certainly nowhere as important as making Emacs more like modern IDEs.
> 
> Uh, there is a connection.  Because modern IDEs tend to have useful
> program information when debugging instead of (optimized out).

Compile with -Og (which should be the default anyway), and you have
that with GCC/GDB as well.

> > When LLDB gets anywhere near GDB in functionality and usability, let
> > alone surpasses it, maybe then I might get interested.
> 
> Seems you missed where people stated that its willingness to talk about
> values that can only be deduced by cooperation with the compiler was
> making a crucial difference in usability over gdb.

I don't think what you say is true.

> At any rate, you seem to be _totally_ on the other side of Richard on
> this one.  You want to start thinking about LLDB when it is getting more
> useful than GDB

Not _when_, _if_.

> >> > Free Software is about freedom of developers as well.
> >> 
> >> Not at its core.
> >
> > Yes, at its core: the freedom to change the code requires a developer
> > who can actually do that.
> 
> <URL:http://www.gnu.org/gnu/manifesto.html>
> 
> You'll find that wherever conflicts of interest between users and
> programmers are considered, Richard puts the users' interests first.

Irrelevant.

Re: Contributing LLVM.org patches to gud.el

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > Uh, there is a connection.  Because modern IDEs tend to have useful
 > > program information when debugging instead of (optimized out).
 > 
 > Compile with -Og (which should be the default anyway), and you have
 > that with GCC/GDB as well.

Er, most programs I compile default to -O3 (I mean upstream does).  So
you can't debug a production build even if you have symbols.  Arrgh!

Re: Contributing LLVM.org patches to gud.el

[Daniel Colascione]

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

On 02/10/2015 07:43 PM, Stephen J. Turnbull wrote:
> Eli Zaretskii writes:
> 
>  > > Uh, there is a connection.  Because modern IDEs tend to have useful
>  > > program information when debugging instead of (optimized out).
>  > 
>  > Compile with -Og (which should be the default anyway), and you have
>  > that with GCC/GDB as well.
> 
> Er, most programs I compile default to -O3 (I mean upstream does).  So
> you can't debug a production build even if you have symbols.  Arrgh

What exactly are the DWARF deficiencies that prevent a debugger from
unwinding caller-saved registers to their original values? The
specification seems more than powerful enough for the task.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Daniel Colascione <dancol@dancol.org> writes:

> On 02/10/2015 07:43 PM, Stephen J. Turnbull wrote:
>> Eli Zaretskii writes:
>> 
>>  > > Uh, there is a connection.  Because modern IDEs tend to have useful
>>  > > program information when debugging instead of (optimized out).
>>  > 
>>  > Compile with -Og (which should be the default anyway), and you have
>>  > that with GCC/GDB as well.
>> 
>> Er, most programs I compile default to -O3 (I mean upstream does).  So
>> you can't debug a production build even if you have symbols.  Arrgh
>
> What exactly are the DWARF deficiencies that prevent a debugger from
> unwinding caller-saved registers to their original values? The
> specification seems more than powerful enough for the task.

The issue mostly are values which are not present explicitly anywhere.
If the compiler can deduce the value/effect of a variable, it does not
need to store it anywhere.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Daniel Colascione]

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

On 02/11/2015 02:37 AM, David Kastrup wrote:
> Daniel Colascione <dancol@dancol.org> writes:
> 
>> On 02/10/2015 07:43 PM, Stephen J. Turnbull wrote:
>>> Eli Zaretskii writes:
>>>
>>>  > > Uh, there is a connection.  Because modern IDEs tend to have useful
>>>  > > program information when debugging instead of (optimized out).
>>>  > 
>>>  > Compile with -Og (which should be the default anyway), and you have
>>>  > that with GCC/GDB as well.
>>>
>>> Er, most programs I compile default to -O3 (I mean upstream does).  So
>>> you can't debug a production build even if you have symbols.  Arrgh
>>
>> What exactly are the DWARF deficiencies that prevent a debugger from
>> unwinding caller-saved registers to their original values? The
>> specification seems more than powerful enough for the task.
> 
> The issue mostly are values which are not present explicitly anywhere.
> If the compiler can deduce the value/effect of a variable, it does not
> need to store it anywhere.

DWARF's virtual machine contains instructions for regenerating these
values from extant values and for building them out of thin air. See
section 2.5 of the DWARF 4 specification. GCC could emit enough
information to rebuild lost values, but does not.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Contributing LLVM.org patches to gud.el

[Stephen J. Turnbull]

 > On 02/11/2015 02:37 AM, David Kastrup wrote:

 > > The issue mostly are values which are not present explicitly
 > > anywhere.  If the compiler can deduce the value/effect of a
 > > variable, it does not need to store it anywhere.

I regularly see this with function arguments, IIRC including across
linkage boundaries.  I don't see how the compiler could deduce such
values or their effects, except for cases like "(char) x < 1000".

Daniel Colascione writes:

 > DWARF's virtual machine contains instructions for regenerating
 > these values from extant values and for building them out of thin
 > air. See section 2.5 of the DWARF 4 specification. GCC could emit
 > enough information to rebuild lost values, but does not.

Eli mentioned DWARF 2.  The manual for GCC 4.8.4 says:

    -g
    Produce debugging information in the operating system's native format
    (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this debugging
    information.

Later there is an option for specifying the version of DWARF, which
cautions that use of DWARF 4 "may require gdb 7 and
-fvar-tracking-assignments".  I'll have to try that.

For those of us who aren't gdb developers, it would be nice if gdb
mentioned that use of DWARF 4 and special gcc options helps in
debugging.

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: David Kastrup <dak@gnu.org>,
>     Eli Zaretskii <eliz@gnu.org>,
>     emacs-devel@gnu.org
> Date: Wed, 11 Feb 2015 22:22:24 +0900
> 
> Daniel Colascione writes:
> 
>  > DWARF's virtual machine contains instructions for regenerating
>  > these values from extant values and for building them out of thin
>  > air. See section 2.5 of the DWARF 4 specification. GCC could emit
>  > enough information to rebuild lost values, but does not.
> 
> Eli mentioned DWARF 2.  The manual for GCC 4.8.4 says:
> 
>     -g
>     Produce debugging information in the operating system's native format
>     (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this debugging
>     information.
> 
> Later there is an option for specifying the version of DWARF, which
> cautions that use of DWARF 4 "may require gdb 7 and
> -fvar-tracking-assignments".  I'll have to try that.

I'm sorry for confusing wording, although this is not entirely my
fault.  The official name of the DWARF Standard is "DWARF Version N",
and the latest is "DWARF Version 4".  But GDB and GCC developers tend
to refer to DWARF Version 2 and newer as "DWARF 2".  Even GDB itself
caught this disease: if I compile a program with an explicit -gdwarf-4
command-line option (this is GCC 4.8.1), GDB still says

  (gdb) info source
  Current source file is tt.c
  Compilation directory is D:\usr\eli\utils
  Located in D:\usr\eli\utils\tt.c
  Contains 16 lines.
  Source language is c.
  Compiled with DWARF 2 debugging format.  <<<<<<<<<<<<<<<<<<<<<<

However, "objdump --dwarf=info" tells the truth:

  Contents of the .debug_info section:

    Compilation Unit @ offset 0x0:
     Length:        0x2bf (32-bit)
     Version:       4    <<<<<<<<<<<<<<<<<<<<<

> For those of us who aren't gdb developers, it would be nice if gdb
> mentioned that use of DWARF 4 and special gcc options helps in
> debugging.

It doesn't have to: GCC defaults to the latest version of DWARF
automatically.  Thus, if your GCC supports DWARF Version 4, it will
always use it, unless you override that with -gdwarf-3 or some such.

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> Date: Wed, 11 Feb 2015 18:07:42 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: dancol@dancol.org, dak@gnu.org, emacs-devel@gnu.org
> 
> > From: "Stephen J. Turnbull" <stephen@xemacs.org>
> > Cc: David Kastrup <dak@gnu.org>,
> >     Eli Zaretskii <eliz@gnu.org>,
> >     emacs-devel@gnu.org
> > Date: Wed, 11 Feb 2015 22:22:24 +0900
> > 
> > Eli mentioned DWARF 2.  The manual for GCC 4.8.4 says:
> > 
> >     -g
> >     Produce debugging information in the operating system's native format
> >     (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this debugging
> >     information.
> > 
> > Later there is an option for specifying the version of DWARF, which
> > cautions that use of DWARF 4 "may require gdb 7 and
> > -fvar-tracking-assignments".  I'll have to try that.

AFAIU, -fvar-tracking-assignments is automatically turned on when
compiling an optimized program.  The GCC manual says:

  -fvar-tracking
      Run variable tracking pass. It computes where variables are
      stored at each position in code. Better debugging information is
      then generated (if the debugging information format supports
      this information).

      It is enabled by default when compiling with optimization (-Os,
      -O, -O2, ...), debugging information (-g) and the debug info
      format supports it.

  -fvar-tracking-assignments
      Annotate assignments to user variables early in the compilation
      and attempt to carry the annotations over throughout the
      compilation all the way to the end, in an attempt to improve
      debug information while optimizing. Use of -gdwarf-4 is
      recommended along with it.

      It can be enabled even if var-tracking is disabled, in which
      case annotations are created and maintained, but discarded at
      the end.

The part about -fvar-tracking-assignments is confusing, but this
discussion seems to clarify that:

  https://gcc.gnu.org/ml/gcc-help/2015-01/msg00152.html
  https://gcc.gnu.org/ml/gcc-help/2015-01/msg00155.html

My take of this is that if you have a recent enough GCC and GDB, you
are already using this feature in optimized programs, and any
variables that are still announced as "<optimized out>" are those
which this feature is not (yet) good enough to fix.

Re: Contributing LLVM.org patches to gud.el

[Daniel Colascione]

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

On 02/12/2015 08:26 AM, Eli Zaretskii wrote:
>> Date: Wed, 11 Feb 2015 18:07:42 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: dancol@dancol.org, dak@gnu.org, emacs-devel@gnu.org
>>
>>> From: "Stephen J. Turnbull" <stephen@xemacs.org>
>>> Cc: David Kastrup <dak@gnu.org>,
>>>     Eli Zaretskii <eliz@gnu.org>,
>>>     emacs-devel@gnu.org
>>> Date: Wed, 11 Feb 2015 22:22:24 +0900
>>>
>>> Eli mentioned DWARF 2.  The manual for GCC 4.8.4 says:
>>>
>>>     -g
>>>     Produce debugging information in the operating system's native format
>>>     (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this debugging
>>>     information.
>>>
>>> Later there is an option for specifying the version of DWARF, which
>>> cautions that use of DWARF 4 "may require gdb 7 and
>>> -fvar-tracking-assignments".  I'll have to try that.
> 
> AFAIU, -fvar-tracking-assignments is automatically turned on when
> compiling an optimized program.

Maybe it's better these days. In some cases, we really can't reconstruct
values. Consider something like this:

  unsigned x = foo();
  unsigned y = x / 2;

If y == 4, we don't know whether x was 8 or 9.

But that's not the case I've seen most. When debugging optimized code,
though, I've run into far more annoying situations. Consider this code:

void
foo(void* context)
{
  struct value* c = context;
  bar(c);
}

Say I'm broken into the program just before the call to bar and I want
to inspect some field of c. I should be able to print c->field, right?
Except GDB tells me that c is <optimized out>, even though context is
right there and contains the same bits!



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> Date: Thu, 12 Feb 2015 09:42:46 -0800
> From: Daniel Colascione <dancol@dancol.org>
> Cc: dak@gnu.org, emacs-devel@gnu.org
> 
> void
> foo(void* context)
> {
>   struct value* c = context;
>   bar(c);
> }
> 
> Say I'm broken into the program just before the call to bar and I want
> to inspect some field of c. I should be able to print c->field, right?
> Except GDB tells me that c is <optimized out>, even though context is
> right there and contains the same bits!

Not sure what you mean by "right there".  IME, in these cases
'context' is also <optimized out>.  Try "info address" on both, and
see what it tells you.

In any case, I'm far from being an expert om DWARF and on recording
variable assignments in debug info.  I really suggest to report such
problems to the GCC and GDB developers, in case there are bugs there.

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> Date: Wed, 11 Feb 2015 02:51:41 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: "Stephen J. Turnbull" <stephen@xemacs.org>, 
>  Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org
> 
> DWARF's virtual machine contains instructions for regenerating these
> values from extant values and for building them out of thin air. See
> section 2.5 of the DWARF 4 specification. GCC could emit enough
> information to rebuild lost values, but does not.

Please consider submitting a bug report to the GCC developers about
that.

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > DWARF's virtual machine contains instructions for regenerating these
  > values from extant values and for building them out of thin air. See
  > section 2.5 of the DWARF 4 specification. GCC could emit enough
  > information to rebuild lost values, but does not.

Thanks for the report.  I sent this to the GCC maintainers to see whether
we can get it improved.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> Date: Tue, 10 Feb 2015 19:47:15 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: emacs-devel@gnu.org
> 
> What exactly are the DWARF deficiencies that prevent a debugger from
> unwinding caller-saved registers to their original values? The
> specification seems more than powerful enough for the task.

In a recent enough GDB, those cases where you see <optimized out> are
not about caller-saved registers.  They are about variables whose
location at the current value of PC is not recorded in DWARF info in a
way that a debugger can use to glean their values.

You can read more about this in the discussion which started here:

  http://cygwin.com/ml/gdb/2014-09/msg00068.html

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 11 Feb 2015 12:43:20 +0900
> 
> Eli Zaretskii writes:
> 
>  > > Uh, there is a connection.  Because modern IDEs tend to have useful
>  > > program information when debugging instead of (optimized out).
>  > 
>  > Compile with -Og (which should be the default anyway), and you have
>  > that with GCC/GDB as well.
> 
> Er, most programs I compile default to -O3 (I mean upstream does).  So
> you can't debug a production build even if you have symbols.  Arrgh!

What do you mean by "cannot debug"?  AFAIR, "-O3 -g3" still gives you
a debuggable binary, albeit with backtrace that many times lies to you
and functions where you cannot put a breakpoint due to excessive
inlining.

Re: Contributing LLVM.org patches to gud.el

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > What do you mean by "cannot debug"?

I mean *I* (at my level of skill) am *unable* to get the information I
need out of gdb when the binary was built with "-O3" (no "-g3" in the
executables I'm talking about, just "-g").

Emacs has always been sensitive to the needs of lower-skilled users,
for which I've always been thankful.  Debates about exactly how to
implement that notwithstanding, it's a common value here.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Eli Zaretskii writes:
>
>  > What do you mean by "cannot debug"?
>
> I mean *I* (at my level of skill) am *unable* to get the information I
> need out of gdb when the binary was built with "-O3" (no "-g3" in the
> executables I'm talking about, just "-g").

-ggdb is an obvious contender when debugging with gdb, though.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Stephen J. Turnbull]

David Kastrup writes:

 > -ggdb is an obvious contender when debugging with gdb, though.

You're missing the point.  I'm talking about debugging an existing
binary.

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Thu, 12 Feb 2015 12:23:13 +0100
> 
> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
> 
> > Eli Zaretskii writes:
> >
> >  > What do you mean by "cannot debug"?
> >
> > I mean *I* (at my level of skill) am *unable* to get the information I
> > need out of gdb when the binary was built with "-O3" (no "-g3" in the
> > executables I'm talking about, just "-g").
> 
> -ggdb is an obvious contender when debugging with gdb, though.

Nowadays, -ggdb is a no-op, at least on platforms where DWARF is the
default debug info.

Re: Contributing LLVM.org patches to gud.el

[Stephen J. Turnbull]

 > Eli Zaretskii <eliz@gnu.org> writes:

 > > When LLDB gets anywhere near GDB in functionality and usability,
 > > let alone surpasses it, maybe then I might get interested.

Your personal preference for GNU software is well-known.  But your
preference doesn't help explain, let alone fight, the increasing
popularity of LLVM that Richard perceives as a potential threat to
software freedom, AIUI because of the legal and technical ease with
which portions of LLVM could be replaced with proprietary software.

BTW, in my usage, the only thing that lldb lacks that gdb has is my
muscle memory (lldb's command set is much more regular, but therefore
*different* and I haven't memorized it yet, partly because muscle-
memory-compatible aliases are provided for the most common commands
like "run", "backtrace", and "break").  I'm not a "power debugger" in
C, so it doesn't surprise me that you find lldb less satisfactory.
But this difference indicates you should be careful to worry about the
"innovator's dilemma", where an inferior product is "cheaper" (in some
sense) and takes over the non-power-user market, and in that way gains
the resources needed to improve rapidly and decisively.

David Kastrup writes:

 > Seems you missed where people stated that its willingness to talk
 > about values that can only be deduced by cooperation with the
 > compiler was making a crucial difference in usability over gdb.

That's not really fair, David, for the same reasons.  I was reporting
personal experience and personal preference.  Note that on Mac
"Yosemite" the default compiler is clang, and gdb may not yet be so
clued in to clang's idioms in DWARF or whatever debugging it emits, by
comparison to its understanding of GCC.  In other words, it's somewhat
unfair to compare clang + gdb to clang + lldb[1], and I suspect that
Richard may consider that "unfairness" to be a mitigating factor,
because lldb would not be likely to infect the GNU world so quickly.

 > At any rate, you seem to be _totally_ on the other side of Richard on
 > this one.  You want to start thinking about LLDB when it is getting more
 > useful than GDB, he wants to stop people from thinking about LLDB when
 > it is getting more useful than GDB.

Touche!  But they're really saying the same thing in different ways.

Eli, again:

 > > For now, it's a niche debugger, not unlike dbx.

Hardly.  True, from one point of view Mac OS X itself is a niche OS.
But from the same point of view, Emacs itself is a niche app.

 > > Why should we care so much if LLDB support will land today, next
 > > week, or next year?  We shouldn't burn so much energy on even
 > > discussing it.

Perhaps not discussing the philosophy on this list.  But there are a
*lot* of people using Emacs who are also using clang (essentially all
Mac developers who use Emacs, for example).  LLVM support is important
to some of us, and it *is* *free* software.  My take is that Stefan is
correct: Just Do It.  Among other things, somebody (David?) said
something like "this kind of decision needs to be made many times by
many maintainers, the rule needs to be clear and simple."  Support for
free software that Emacs users are already committed to should not be
a problem, while Emacs functionality that advertises superior
capabilities of non-GNU software should be avoided.[2]

IMHO, Richard should spend his energy on the hard, important problems,
like whether gcc and gdb need a good ass-kicking to address these
usability issues (from what you write, the issue may not exist for
that combination), or whether gdb should try to compete with lldb even
when the compiler isn't gcc.

 > Well, GNU does not turn on a dime.  So there is nothing wrong with
 > thinking ahead.

It's absolute essential, actually, since Richard's preference is for
core GNU tools to be monolithic so their main functionalities cannot
be easily replaced (or in some cases even accessed) without large
investment.  That, while most competing projects have made agility of
development a core value.

 > >> > Free Software is about freedom of developers as well.
 > >> 
 > >> Not at its core.
 > >
 > > Yes, at its core: the freedom to change the code requires a developer
 > > who can actually do that.
 > 
 > <URL:http://www.gnu.org/gnu/manifesto.html>
 > 
 > You'll find that wherever conflicts of interest between users and
 > programmers are considered, Richard puts the users' interests first.

Gag me!  I find it very sad that free software advocates are making a
distinction between users and developers.


Footnotes: 
[1]  Nor have I compared gcc + gdb to gcc + lldb!

[2]  I think the "deliberate attack" possibility is a red herring.
And I disagree with Richard and Stefan on another issue: as much as I
think the *existence* and *availability* of Excorporate is a good
thing, I think it would be a strategically good idea to remind its
users that GNU is not here to support them in that usage.  I don't see
any advantage to free software in having Emacs distribute it, even as
part of ELPA.  I somehow doubt that the availability of Excorporate
will cause any Outlook users to switch to Gnus, although it might
catch some Thunderbird users.  OTOH, users of gud.el will be able to
switch from lldb to gdb more easily, and I find that more plausible
(especially on a case-by-case basis).

Re: Contributing LLVM.org patches to gud.el

[Nicholas Allegra]

On Tue, Feb 10, 2015 at 11:26 PM, Stephen J. Turnbull
<stephen@xemacs.org> wrote:
> BTW, in my usage, the only thing that lldb lacks that gdb has is my
> muscle memory (lldb's command set is much more regular, but therefore
> *different* and I haven't memorized it yet, partly because muscle-
> memory-compatible aliases are provided for the most common commands
> like "run", "backtrace", and "break").  I'm not a "power debugger" in
> C, so it doesn't surprise me that you find lldb less satisfactory.
> But this difference indicates you should be careful to worry about the
> "innovator's dilemma", where an inferior product is "cheaper" (in some
> sense) and takes over the non-power-user market, and in that way gains
> the resources needed to improve rapidly and decisively.

For the record, as another "power debugger" (mostly for programs I do
not have debugging information for, and often not the source code
either) -

LLDB's command set is more regular, but also far more verbose; their
own GDB to LLDB command map[1] assigns almost every operation a longer
command on the LLDB side.  Its Python API is a set of autogenerated
C++ bindings with a few Python-specific helpers added, which
unsurprisingly therefore feels quite clunky and poorly adapted to
Python; there are also a bunch of obvious missing features in the API,
requiring scripts to resort to the 'evaluate CLI command' function.
It does not have any ability to do basic scripting directly from the
debugger CLI (i.e. if/while commands), requiring you to use Python;
while Python scripts (written against either API) are obviously far
more powerful than raw GDB commands in the context of published,
reusable entities, I often use GDB scripting interactively.  It is, at
least on OS X, highly buggy, and prone to hanging; in my experience
GDB is typically quite buggy as well when asked to do semi-unusual
things, but LLDB is no better.  LLDB does not support hardware
breakpoints on OS X despite this being its flagship platform, and it
only recently gained support for a JIT symbol API.  It does not
support reverse debugging.

I expect LLDB will improve significantly in the coming years, but
currently I believe GDB is still technically superior.  Hopefully it
will keep sufficient pace to remain that way.

[1] http://lldb.llvm.org/lldb-gdb.html

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,
>     emacs-devel@gnu.org
> Date: Wed, 11 Feb 2015 13:26:34 +0900
> 
>  > Eli Zaretskii <eliz@gnu.org> writes:
> 
>  > > When LLDB gets anywhere near GDB in functionality and usability,
>  > > let alone surpasses it, maybe then I might get interested.
> 
>  > > When LLDB gets anywhere near GDB in functionality and usability,
>  > > let alone surpasses it, maybe then I might get interested.
> 
> Your personal preference for GNU software is well-known.  But your
> preference doesn't help explain, let alone fight, the increasing
> popularity of LLVM

I really doubt that people prefer using a debugger that lacks basic
features, like remote debugging, even on GNU/Linux, more so on *BSD.
If they do, perhaps printf debugging is a contender as well?

And what about all the advanced features, like fork-following, JIT
debugging, probe points, reverse execution, record and replay, etc.?

IOW, the above is not just personal preference, it has at least some
basis in GDB features that LLDB lacks.  Until it grows them, it is not
a serious contender, and not just for personal preference reasons.

> But this difference indicates you should be careful to worry about the
> "innovator's dilemma", where an inferior product is "cheaper" (in some
> sense) and takes over the non-power-user market, and in that way gains
> the resources needed to improve rapidly and decisively.

If you mean that GDB development should not rest on its laurels, then
I very much agree.  I don't see any signs that it does, fortunately.

>  > > For now, it's a niche debugger, not unlike dbx.
> 
> Hardly.  True, from one point of view Mac OS X itself is a niche OS.
> But from the same point of view, Emacs itself is a niche app.

We are not talking about replacing Emacs with LLDB, so this analogy,
even if true, doesn't get us anywhere.  We are talking about whether
we should rush to include LLDB support in Emacs.  I say a niche
application of insufficient usability doesn't justify any rush.

>  > > Why should we care so much if LLDB support will land today, next
>  > > week, or next year?  We shouldn't burn so much energy on even
>  > > discussing it.
> 
> Perhaps not discussing the philosophy on this list.  But there are a
> *lot* of people using Emacs who are also using clang (essentially all
> Mac developers who use Emacs, for example).

Are you saying that GDB doesn't support clang on GNU/Linux well
enough, so LLDB is the only practical alternative for those who use
clang?  That's not my impression, and if it were so, I'd expect to
hear requests for LLDB support much earlier.

> LLVM support is important to some of us, and it *is* *free*
> software.

I didn't say we should never include its support.  I just said I see
no reason to consider waiting harmful in this case.  If someone needs
that yesterday, they can apply the patch submitted here, it's a simple
patch to a single Lisp file.

> My take is that Stefan is correct: Just Do It.

My take is that Stefan tries to make a point, and LLDB is just a
vehicle for that point.  _My_ point was that it's a shabby vehicle not
worthy of Stefan's point.  Just read the LLDB's "Status" page and
development list, and you will see what I mean.  We have created a
tempest in a teapot.

> IMHO, Richard should spend his energy on the hard, important problems,
> like whether gcc and gdb need a good ass-kicking to address these
> usability issues (from what you write, the issue may not exist for
> that combination), or whether gdb should try to compete with lldb even
> when the compiler isn't gcc.

AFAIK, Richard does precisely that.  Of course, you cannot expect more
than general guidance and questions from someone who is not intimately
involved in development of these projects.  The rest is up to the
development team.  At least in GDB case, development is to a large
degree driven by industry needs, since several core developers
actually get paid for their work.  That is why GDB sees so many new
features that support advanced CPU and systems development by major
vendors, like SysTaps, MPX, etc.

Re: Contributing LLVM.org patches to gud.el

[Stefan Monnier]

> I really doubt that people prefer using a debugger that lacks basic
> features, like remote debugging, even on GNU/Linux, more so on *BSD.
> If they do, perhaps printf debugging is a contender as well?
> And what about all the advanced features, like fork-following, JIT
> debugging, probe points, reverse execution, record and replay, etc.?

Just as a data point: I have never used any of those features you mention.


        Stefan

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

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

>> I really doubt that people prefer using a debugger that lacks basic
>> features, like remote debugging, even on GNU/Linux, more so on *BSD.
>> If they do, perhaps printf debugging is a contender as well?
>> And what about all the advanced features, like fork-following, JIT
>> debugging, probe points, reverse execution, record and replay, etc.?
>
> Just as a data point: I have never used any of those features you mention.

Reverse execution is actually pretty useful when the place of a segfault
does not really retain a lot of information about its genesis.  Little
surprisingly, it depends on recorded execution.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,  dak@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 11 Feb 2015 11:21:35 -0500
> 
> > I really doubt that people prefer using a debugger that lacks basic
> > features, like remote debugging, even on GNU/Linux, more so on *BSD.
> > If they do, perhaps printf debugging is a contender as well?
> > And what about all the advanced features, like fork-following, JIT
> > debugging, probe points, reverse execution, record and replay, etc.?
> 
> Just as a data point: I have never used any of those features you mention.

You should try.  Reverse execution, in particular, is sometimes very
useful, when you stop the program after the bug already happened.
(Record and replay is just another method of doing the same, with
different merits and demerits.)

Re: Contributing LLVM.org patches to gud.el

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > I really doubt that people prefer using a debugger that lacks basic
 > features, like remote debugging, even on GNU/Linux, more so on
 > *BSD.  If they do, perhaps printf debugging is a contender as well?

Indeed it is.  I use it all the time (in Python programs).

 > And what about all the advanced features, like fork-following, JIT
 > debugging, probe points, reverse execution, record and replay, etc.?

What in the world are you talking about? ;-)  At my level, I could care
less.  Furthermore, those features aren't discoverable unless you are
enough of a specialist to need them.  (I have to browse the gdb help
almost every time I do any debugging, and this is the first I've heard
of any of them.)  That is precisely the point here.

(BTW, a technical point: I wonder how many of them are inspired by the
need to get at information that gcc could provide, but doesn't?)

 > IOW, the above is not just personal preference, it has at least some
 > basis in GDB features that LLDB lacks.  Until it grows them, it is not
 > a serious contender, and not just for personal preference reasons.

One man's feature is another man's YAGNI.  It's just personal
preference.  A difference in terminology about "taste", that's all.

But you seem to missing the point of the "innovator's dilemma," which
is that by deliberately targeting "downmarket", you can acquire the
resources to develop quickly.  IOW, lldb *will* grow those advanced
features.  Furthermore, although academia does not encompass the whole
"upmarket", it is an upmarket, and I suspect they may be just as
demanding as you are, though for different features.

What the LLVM devotees claim is that a better factored design for the
whole toolchain allows extremely rapid development of features that
the front-runner got only with great effort.  Need proof?  "GNU/Linux"
(and Andy T will tell you that Linux is hardly "well-factored" :-).
QED

 > If you mean that GDB development should not rest on its laurels,
 > then I very much agree.  I don't see any signs that it does,
 > fortunately.

No, that's not what I mean.  What I mean is that it may very well be
misdirecting its effort in concentrating on the most demanding use
cases.  I understand the issue of paid developers you refer to below.
But surely they're a small minority of contributors, even if they
likely have disproportionate "power" to direct development resources
(often not limited to their own and their employers').  I'm sure there
are plenty of resources to improve the "user experience" -- if those
volunteers can be convinced to listen to the naive or occasional user.
That's where the "jawbone" comes in.

There's also the fact that apparently the LLVM *project* is better
factored than the GNU Project.  I get the impression that GDB's needs
are not so high on GCC's priority list.

 > We are not talking about replacing Emacs with LLDB, so this analogy,
 > even if true, doesn't get us anywhere.  We are talking about whether
 > we should rush to include LLDB support in Emacs.  I say a niche
 > application of insufficient usability doesn't justify any rush.

Who's *rushing*?  There is *already* a patch, produced by interested
volunteers.  The issue is when will the *foot-dragging* *stop*?

 > Are you saying that GDB doesn't support clang on GNU/Linux well
 > enough, so LLDB is the only practical alternative for those who use
 > clang?

Of course not.  I'm saying exactly what I wrote: lldb satisfies my
needs in some of my use cases better than gdb does.  If that
generalizes to other occasional users of debuggers, gdb may be
suffering from the "innovator's dilemma".

 > I didn't say we should never include its support.  I just said I
 > see no reason to consider waiting harmful in this case.

Waiting isn't harmful.  The reason for waiting is, and the possibility
that the wait may be forever is.

 > If someone needs that yesterday, they can apply the patch submitted
 > here, it's a simple patch to a single Lisp file.

I shall do so, and do the same favor for my downstream.  Apparently
Stefan intends to do the same.

 > Just read the LLDB's "Status" page and development list, and you
 > will see what I mean.  We have created a tempest in a teapot.

There's no "we" about it.  And it's hardly a teapot.

Think about it: Richard is trying to suppress free software
distribution temporarily, in one special -- and especially important
-- channel, because he's considering making that decision permanent.
This is an issue of concern to all free software advocates.  We need
to understand what is happening here, or we're mere fanboys.

There is plenty of half-baked software supported by Emacs, just
because it *can* be supported.  Subject to being free software,
meeting code quality standards, and assignment (all of which appear to
be satisfied, or would be satisfied soon), normally the actual push is
automatic (although particularly marginal features and new full
applications often get farmed out to ELPA).  No?

 > At least in GDB case, development is to a large degree driven by
 > industry needs, since several core developers actually get paid for
 > their work.  That is why GDB sees so many new features that support
 > advanced CPU and systems development by major vendors, like
 > SysTaps, MPX, etc.

Good for GDB.[1]  But that's irrelevant to the question of refusing to
distribute copyleft software which supports free software, and is
already produced.  Especially if you are correct that lldb is no
threat to gdb!


Footnotes: 
[1]  Except that it is a symptom often indicative of the "innovator's
dilemma".

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: dak@gnu.org,
>     emacs-devel@gnu.org
> Date: Thu, 12 Feb 2015 14:41:58 +0900
> 
> Eli Zaretskii writes:
> 
>  > And what about all the advanced features, like fork-following, JIT
>  > debugging, probe points, reverse execution, record and replay, etc.?
> 
> What in the world are you talking about? ;-)  At my level, I could care
> less.

Well, others don't.  And if LLDB never implements those, I don't think
we need to worry about it ever becoming a contender.

> Furthermore, those features aren't discoverable unless you are
> enough of a specialist to need them.  (I have to browse the gdb help
> almost every time I do any debugging, and this is the first I've heard
> of any of them.)  That is precisely the point here.

LLDB doesn't even _have_ a manual.  So much for its discoverability.

> (BTW, a technical point: I wonder how many of them are inspired by the
> need to get at information that gcc could provide, but doesn't?)

None, AFAIK.

>  > IOW, the above is not just personal preference, it has at least some
>  > basis in GDB features that LLDB lacks.  Until it grows them, it is not
>  > a serious contender, and not just for personal preference reasons.
> 
> One man's feature is another man's YAGNI.  It's just personal
> preference.  A difference in terminology about "taste", that's all.

I don't think so.  Modern debuggers are expected to provide a certain
list of features.  E.g., without remote debugging, you cannot
conveniently debug embedded software, which is a large part of the
industry these days.  I guess that's why LLDB developers are working
hard on adding it.

> But you seem to missing the point of the "innovator's dilemma," which
> is that by deliberately targeting "downmarket", you can acquire the
> resources to develop quickly.

I don't think LLDB is targeting some "downmarket", they target the
same population of software developers as GDB.  You and Stefan and me
and all of us here.

> IOW, lldb *will* grow those advanced features.

I'm sure it will.  But if GDB's development continues at its present
pace, GDB will have additional features by that time.  And if GDB
stagnates and LLDB (or some other package) surpasses it, then I'll
agree that supporting a better contender becomes an important goal of
Emacs.

> What the LLVM devotees claim is that a better factored design for the
> whole toolchain allows extremely rapid development of features that
> the front-runner got only with great effort.

I have no doubt that being a later project, developed with newer
technology up front, is an advantage.  For starters, they don't need
to invent the features, they can (and do) just copycat them (ideas,
not code).  Which means they won't need all those years it took GDB to
get to the same point.  But it remains to be seen whether this
advantage is enough to unseat the champion in the observable future.
Personally, I think it takes more than just better factored design;
YMMV.

> I get the impression that GDB's needs are not so high on GCC's
> priority list.

Not sure why you get that impression.  Several GDB developers are
involved with GCC one way or another.  As one data point, the recent
addition to GDB of JIT compilation and injection of code was a product
of cooperation between GCC and GDB developers, as significant changes
were needed on both sides.

> Who's *rushing*?  There is *already* a patch, produced by interested
> volunteers.  The issue is when will the *foot-dragging* *stop*?

I'm saying that in this case there's no reason to be worried about the
foot-dragging.

> Think about it: Richard is trying to suppress free software
> distribution temporarily, in one special -- and especially important
> -- channel, because he's considering making that decision permanent.
> This is an issue of concern to all free software advocates.  We need
> to understand what is happening here, or we're mere fanboys.

There's any number of issues of concern to me at any given moment.
The important question is what to do about each and every concern in
each practical case.  I'm saying that in the case of LLDB support
doing nothing for a while is far from being a catastrophe.

You seem to see some ominous signs in what Richard wrote, but I don't.
Having known Richard for many years, having met him face to face
several times, and yes, having sparred with him on a few occasions, I
see no conclusions here to be drawn that go beyond this specific
issue.  And this specific issue is insignificant, because the need for
urgently incorporating LLDB support in Emacs is insignificant.

I feel quite differently in the issue with IDE functionalities that
need help from a compiler.  There, I wish the decision-making process
could have been much speedier, because we are already losing the IDE
battle.  (Of course, having no one but David Engster working on that
means that even if this roadblock were removed, we'd be unable to
catch up any time soon, maybe never.)

But our job of convincing Richard in the IDE case is not getting any
easier by starting a similar argument about LLDB.  On the contrary: it
is now harder, because Richard now has to invest some of his scarce
time in learning about LLDB.

IOW, we should choose very carefully which LLVM-related issues we want
to raise urgently, and which we don't.  Our cause of advancing Emacs
is certainly not served by supporting LLDB; by contrast, making Emacs
a modern IDE does serve that goal.  We should decide whether we want
to advance Emacs or waste time and energy on every tempest in every
teapot that has "LLVM" label stuck onto it.

Re: Contributing LLVM.org patches to gud.el

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Well, others don't.

Of course.  I don't deny that my personal tastes and needs are
personal.

 > And if LLDB never implements those, I don't think
 > we need to worry about it ever becoming a contender.

*shrug* You can prune that fork, and start worrying.

 > LLDB doesn't even _have_ a manual.  So much for its
 > discoverability.

It hasn't yet occurred to me to look for one.  Not so, GDB.

 > I don't think LLDB is targeting some "downmarket", they target the
 > same population of software developers as GDB.  You and Stefan and me
 > and all of us here.

You are obviously out of my league.  Dunno about where Stefan plays
but he claims not to be missing any of those features you consider
essential in a modern debugger.  I really don't think it's useful to
talk about "one population" here.

 > And if GDB stagnates and LLDB (or some other package) surpasses it,
 > then I'll agree that supporting a better contender becomes an
 > important goal of Emacs.

Hmm.  So David's right about you being in partial opposition to
Richard on these things.

 > You seem to see some ominous signs in what Richard wrote, but I
 > don't.  Having known Richard for many years, having met him face to
 > face several times, and yes, having sparred with him on a few
 > occasions, I see no conclusions here to be drawn that go beyond
 > this specific issue.

Oh, there are no omens here, just the same old same old.  I drew my
conclusions a decade or more ago; I'm just hoping to be proved wrong.
I guess I have to keep hoping.

Re: Contributing LLVM.org patches to gud.el

[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 you seem to missing the point of the "innovator's dilemma," which
  > is that by deliberately targeting "downmarket", you can acquire the
  > resources to develop quickly.  IOW, lldb *will* grow those advanced
  > features.

You seem to be arguing that we should indeed regard LLDB as a threat.
But I will decide based on the discussion with the GDB developers.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[David Engster]

Eli Zaretskii writes:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> You seem not to have even understood that your insistence has compelled
>> David Engster to stop working on GCC-based code completion support
>> for CEDET.
>
> FWIW, I think David made a mistake when he gave up.

I have only given up on using GCC. I have not given up on improving the
C++ parser, but I will do it outside Emacs, using libtooling and
libclang.

>I faced a similar disheartening intention (for quite different, but
>still political) reasons when I worked on bidi support.  I decided to
>disregard and proceed, and the result is before your eyes.

The crucial difference is that I could not have done this on my own, but
that I would have needed lots of help from the GCC project, most
importantly the willingness to actively support tooling based on GCC,
which in the end means opening up the compiler further. I'm pretty sure
that eventually I would have needed changes upstream, either to make my
life easier, or to retrieve information that isn't available in the
AST. Even if RMS finally decides to tolerate an AST export, it is clear
that he won't approve of the general direction that is needed to make
GCC a contender in the tooling area.

-David

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  eller.helmut@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 10 Feb 2015 18:03:27 +0100
> 
> >I faced a similar disheartening intention (for quite different, but
> >still political) reasons when I worked on bidi support.  I decided to
> >disregard and proceed, and the result is before your eyes.
> 
> The crucial difference is that I could not have done this on my own, but
> that I would have needed lots of help from the GCC project, most
> importantly the willingness to actively support tooling based on GCC,
> which in the end means opening up the compiler further.

I think you greatly exaggerate your need for outside help and/or the
obstacles you'd need to face when you would have asked for such help.
Quite a few of GCC developers use Emacs, so finding individuals
motivated to help with this project should not be too hard.

> I'm pretty sure that eventually I would have needed changes
> upstream, either to make my life easier, or to retrieve information
> that isn't available in the AST. Even if RMS finally decides to
> tolerate an AST export, it is clear that he won't approve of the
> general direction that is needed to make GCC a contender in the
> tooling area.

I suggest that you take a look at libcc1.so in GCC 5 and its use by
GDB for injecting code into the debuggee.  It might change your
perspective and your evaluation of the state of affairs, now and in
the future.

Re: Contributing LLVM.org patches to gud.el

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>> eller.helmut@gmail.com, rms@gnu.org, emacs-devel@gnu.org
>
>> Date: Tue, 10 Feb 2015 18:03:27 +0100
>> 
>> >I faced a similar disheartening intention (for quite different, but
>> >still political) reasons when I worked on bidi support.  I decided to
>> >disregard and proceed, and the result is before your eyes.
>> 
>> The crucial difference is that I could not have done this on my own, but
>> that I would have needed lots of help from the GCC project, most
>> importantly the willingness to actively support tooling based on GCC,
>> which in the end means opening up the compiler further.
>
> I think you greatly exaggerate your need for outside help and/or the
> obstacles you'd need to face when you would have asked for such help.

I don't think so. Let me quote one prominent GCC developer who is also
an Emacs user:

"As one of the GCC developers working during the last ten years on
reducing the gap between GCC and Clang, I would suggest that Emacs
developers who are happy with Clang should just use it to improve Emacs
(I'm also an Emacs user!) and those that are unhappy with Clang should
just join the GCC team and help us such that in some years, GCC could be
an alternative. Anything else is just noise." [1]

So it's all "just noise" unless I become a GCC developer. No thanks.

-David

[1] http://lwn.net/Articles/629259, see last comment

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: monnier@iro.umontreal.ca,  eller.helmut@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 10 Feb 2015 18:36:45 +0100
> 
> "As one of the GCC developers working during the last ten years on
> reducing the gap between GCC and Clang, I would suggest that Emacs
> developers who are happy with Clang should just use it to improve Emacs
> (I'm also an Emacs user!) and those that are unhappy with Clang should
> just join the GCC team and help us such that in some years, GCC could be
> an alternative. Anything else is just noise." [1]
> 
> So it's all "just noise" unless I become a GCC developer. No thanks.

Do you want me to show you similar quotes about bidi, from 12 years
ago?  Do you know how many false ideas were uttered when bidi was
in design phase, and I didn't know enough about Emacs display to tell
right from wrong?

Just disregard that, and do what you think is right.  That's what I
did.

Re: Contributing LLVM.org patches to gud.el

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Cc: monnier@iro.umontreal.ca, eller.helmut@gmail.com, rms@gnu.org,
>> emacs-devel@gnu.org
>
>> Date: Tue, 10 Feb 2015 18:36:45 +0100
>> 
>> "As one of the GCC developers working during the last ten years on
>> reducing the gap between GCC and Clang, I would suggest that Emacs
>> developers who are happy with Clang should just use it to improve Emacs
>> (I'm also an Emacs user!) and those that are unhappy with Clang should
>> just join the GCC team and help us such that in some years, GCC could be
>> an alternative. Anything else is just noise." [1]
>> 
>> So it's all "just noise" unless I become a GCC developer. No thanks.
>
> Do you want me to show you similar quotes about bidi, from 12 years
> ago?
> Do you know how many false ideas were uttered when bidi was
> in design phase, and I didn't know enough about Emacs display to tell
> right from wrong?

Again, you make it sound like I'm giving up. I don't. My error was to
think working with GCC would get support from RMS/GNU. Since that isn't
the case, there simply is no reason left to choose it over
libclang/libtooling, which is vastly superior for implementing IDE
tooling features.

> Just disregard that, and do what you think is right.

That's exactly what I'm doing.

-David

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > "As one of the GCC developers working during the last ten years on
  > reducing the gap between GCC and Clang, I would suggest that Emacs
  > developers who are happy with Clang should just use it to improve Emacs

Whoever said that does NOT speak for the GNU Project.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > "As one of the GCC developers working during the last ten years on
>   > reducing the gap between GCC and Clang, I would suggest that Emacs
>   > developers who are happy with Clang should just use it to improve
>   > Emacs
>
> Whoever said that does NOT speak for the GNU Project.

I don't see that at the current point of time, _anybody_ could claim to
speak for the GNU Project but yourself since nobody else has a clue what
it might mean at a given point of time to speak for the GNU project.

At some point of time, there was a call for Free Software speakers to
register with the FSF.  I have not registered because I don't consider
myself qualified to talk about Free Software in a manner consistent with
or favorable to the FSF's focus of the year.  Since answering some
questions honestly at such a talk might be embarrassing to the FSF, it
would not be appropriate to let the FSF recommend me.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[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 don't see that at the current point of time, _anybody_ could claim to
  > speak for the GNU Project but yourself

There are a few specific issues where I have to make a decision, but
that's the exception.  In general our philosophy is clear and
explicitly stated, and it's easy to say where we stand.

Getting back to the point, David reported that someone on a GCC
discussion list sent him a dismissive and unhelpful message.  That
message was mistaken.  He does not need to be a GCC developer
to get features from GCC.

Developers of other GNU packages can ask the GCC maintainers (which is
not the same as asking the discussion list) to help in a joint
project, and I can urge the GCC maintainers to cooperate.

This is what it means for GNU to be a coherent project, not just many
separate projects.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Engster <deng@randomsample.de>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>> eller.helmut@gmail.com, rms@gnu.org, emacs-devel@gnu.org
>> Date: Tue, 10 Feb 2015 18:03:27 +0100
>> 
>> >I faced a similar disheartening intention (for quite different, but
>> >still political) reasons when I worked on bidi support.  I decided to
>> >disregard and proceed, and the result is before your eyes.
>> 
>> The crucial difference is that I could not have done this on my own, but
>> that I would have needed lots of help from the GCC project, most
>> importantly the willingness to actively support tooling based on GCC,
>> which in the end means opening up the compiler further.
>
> I think you greatly exaggerate your need

I see the claim of exaggeration wielded a lot here against those
actually doing the work and/or actually shouldering the consequences of
decisions.

This kind of condescension may even work for making them go away.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: David Engster <deng@randomsample.de>,  emacs-devel@gnu.org,  eller.helmut@gmail.com,  monnier@iro.umontreal.ca,  rms@gnu.org
> Date: Tue, 10 Feb 2015 19:07:43 +0100
> 
> I see the claim of exaggeration wielded a lot here against those
> actually doing the work and/or actually shouldering the consequences of
> decisions.

People tend to exaggerate the difficulties they face.  It's only
natural, especially when the job is large and significant parts of it
are unknown or uncertain.  Been there, done that, have bruises to
prove.  I thought it might help to remind people that difficulties are
not always as grave as our imagination tells us, and share my own
experience in similar situations.  I don't see anything wrong with
that.

Re: Contributing LLVM.org patches to gud.el

[Stefan Monnier]

> I have only given up on using GCC.

Great, thanks.

> I have not given up on improving the C++ parser, but I will do it
> outside Emacs, using libtooling and libclang.

Looking forward to it.


        Stefan

Re: Contributing LLVM.org patches to gud.el

[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 have only given up on using GCC. I have not given up on improving the
  > C++ parser, but I will do it outside Emacs, using libtooling and
  > libclang.

I hope you will reconsider working on this with GCC.  I am sure there
is a workable and acceptable way to do it.  Please don't give up
because someone sent you a discouraging message.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 09 Feb 2015 12:21:13 +0100
> Cc: eller.helmut@gmail.com, emacs-devel@gnu.org
> 
> A generic dynamic library loading facility to Emacs has been in
> discussion and vetoed for decades.  Somewhat amusingly, the only
> working run-time dynamic library loading that I know of in Emacs is
> the loading of image libraries (free ones, of course) under Windows.

This is very inaccurate, and might lead Ricard, who doesn't know the
details, to very wrong conclusions.  So I must put the record
straight: THERE IS NO "RUN-TIME DYNAMIC LIBRARY LOADING" in Emacs on
Windows.

What we do have is _delayed_linking_ of shared libraries against which
Emacs was compiled at build time.  We provide a facility that performs
this delayed linking when the Lisp primitives that invoke functions
from the respective library are first called.  But the interface to
those functions, including their calling sequences and all the
involved data types, are known to the C compiler at the time the
corresponding C source file is compiled as part of building Emacs.

Moreover, use of these libraries from Emacs is possibly only through
specific primitives that were coded in advance and compiled into the
Emacs binary at build time.  Lisp programs cannot invoke any
functionality from these libraries _except_ what the above-mentioned
primitives provide.

IOW, the functionality this provides is exactly identical to Emacs
being statically linked to these libraries, except that the actual
linking is delayed until first use (or indefinitely, if there's no
use at all).

The reason we provide this on Windows is to allow users to install a
pre-compiled binary of Emacs and use it without installing the
optional libraries (such as image libraries or GnuTLS), if the user
doesn't need the extra functionality.  If we didn't provide this
feature, Emacs would refuse to start without all of the libraries
being present (unlike on Posix platforms, where it will run as long as
the functions from those libraries are not called).

By contrast, the "generic dynamic library loading" facility that is
missing, both on Posix platforms and on MS-Windows, is much more
flexible and allows the following features that are not currently
available in Emacs:

  . Two-way conversion between Lisp data types and arbitrary data
    structures, including pointers, in C, C++, and other languages

  . Loading libraries not known to Emacs at build time, for which no
    specialized primitives were coded as part of Emacs itself

  . Unloading of libraries no longer needed

  . Calling any exported library function from Lisp, without any need
    to write a C-level primitive

This is an entirely different level of using dynamic object loading,
and should never be even compared with the delayed linking of shared
libraries we have now.

Re: Contributing LLVM.org patches to gud.el

[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 we do have is _delayed_linking_ of shared libraries against which
  > Emacs was compiled at build time.

I seem to recall I agreed to that feature in a discussion some years ago.

More recently I agreed to a general dynamic linking feature into
Emacs, with the precautions that are used in GCC.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Florian Weimer]

* Richard Stallman:

>   > If we try to close down every cooperation with non-GNU free software, we
>   > are sacrificing our goals for the sake of our temples.
>
> I agree.  But is anyone proposing that?

I find it disappointing how much trouble the system library exception
in its various versions caused for free software distributions.  It
ended up granting freedoms exclusively to proprietary operating
systems vendors.  The FSF even ignores tight integration of GPL code
and priority code on the same media (or within the same installer),
which, according to the letter of the GPL, version 2, should make it
impossible rely on the system library exception. And this is exactly
what is demanded from free software distributions, but proprietary
vendors receive a free pass on this matter.

This makes me feel bitter.  It is totally understandable on a
psychological level (the goals are so similar that one has to fiercely
insistent on the existence of major differences).  But it's still sad
when it happens.

Re: Contributing LLVM.org patches to gud.el

[Stefan Monnier]

> I wonder if there is enough room for more than one competitor.

Of course there is.

> If evolutionary principles apply to software, then GCC might indeed be
> in danger, because currently it does look like LLVM is more "fit",
> produces (much) more "offspring" and generally takes resources away
> from GCC.

Such is life, and there are good technical reasons for that.
Avoiding LLVM support in Emacs won't make any difference in this
respect, other than push Emacs users away.


        Stefan

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > LLVM is not meant to kill GCC

More precisely, Apple intends LLVM and Clang to make GCC cease to be a
signal success and a reason for all sorts of companies to work on a
compiler that always gives users freedom.  That would be a victory for
Apple and a defeat for freedom.

I don't know what LLDB is, or what it might do.  I am going to find
out.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > LLVM is not meant to kill GCC
>
> More precisely, Apple intends LLVM and Clang to make GCC cease to be a
> signal success and a reason for all sorts of companies to work on a
> compiler that always gives users freedom.  That would be a victory for
> Apple and a defeat for freedom.

As far as I can see, Apple does not _control_ LLVM/Clang development
like they do with Darwin.  Instead there is a multi-party coalition of
interested and independent parties working on it.  The continued success
of LLVM/Clang, particularly in the academics, depends on this
constellation to continue to a significant degree.

So I don't see it as a defeat but rather as a win for software freedom
as a governing principle.  The bad side is the possibility of
proprietary off-spins, and that's not just a theoretical consideration
but an actively used one (for GPU programming).  So it is a loss for
copyleft.  I don't really see it as a "victory" for Apple as they had to
cede control to a community in order to have the project take flight.
This is different to their way of treating people interested in working
on Darwin, their free software kernel, like second-class rabble getting
thrown scraps.  But while I would not call it a "victory", it definitely
is a form of success.

As long as the price they feel they have to pay for their success is
actually enabling a free software project based on a prospering
community (even if not copylefted), we are doing something right.
I don't see the point in taking the pressure off them by committing a
complex form of suicide, stopping GNU programs from interacting well in
the hope to stop people from using them in connection with LLVM.

> I don't know what LLDB is, or what it might do.  I am going to find
> out.

Well, judging from this thread being about basic gud.el support for
LLDB, chances are that it is a debugger.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> More precisely, Apple intends LLVM and Clang to make GCC cease to be a
> signal success and a reason for all sorts of companies to work on a
> compiler that always gives users freedom.

This is silly.  Apple couldn't care less whether or not GCC is a success.
What Apple needs is for a copylefted compiler not to be the *only* success.

GCC's existence does not prevent Apple from compiling proprietary GPU code.
The absence of a realistic *alternative* to GCC prevented that, but having 
fixed that problem Apple has no reason to care whether GCC lives or dies.

As David Kastrup notes, the existence of the clang project is victory - it's
Apple conceding in practice that it is no longer realistically possible to
develop some kinds of critically important tools in a proprietary lockup.

As a result of this victory, all sorts of companies are now working on
*two* compilers that always give users freedom.  One is GCC.  The
other is clang (I haven't noticed my freedom being diminished even a
little bit when I set CC=clang). That is a good thing.

Apple is not composed of angels.  Apple does things that you and I
would both regard as scummy.  But to suppose that Apple has any
desire, need, or intention to attack GCC is to attribute an importance
to GCC in Apple's eyes that it has not possessed since the day clang
shipped 1.0.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Richard Stallman <rms@gnu.org>:
>> More precisely, Apple intends LLVM and Clang to make GCC cease to be a
>> signal success and a reason for all sorts of companies to work on a
>> compiler that always gives users freedom.
>
> This is silly.  Apple couldn't care less whether or not GCC is a
> success.  What Apple needs is for a copylefted compiler not to be the
> *only* success.

Apple does not really need that: they did not break a leg when they had
to open their Objective C frontend for GCC.  But it's not like that has
led to an overboarding Objective C Free Software community.  What Apple
was forced to give back did not end up being of much interest to us, and
I think GCC has stopped building ObjC support by default.

> GCC's existence does not prevent Apple from compiling proprietary GPU
> code.  The absence of a realistic *alternative* to GCC prevented that,
> but having fixed that problem Apple has no reason to care whether GCC
> lives or dies.
>
> As David Kastrup notes, the existence of the clang project is victory
> - it's Apple conceding in practice that it is no longer realistically
> possible to develop some kinds of critically important tools in a
> proprietary lockup.

It's not victory: there is no victory without actual winners and losers.
And I don't see a concession of Apple either.  Their support for
Clang/LLVM did not start in a vacuum: those projects were live before
Apple decided to support them.  They decided not to mess with that basic
setup.  That this decision made sense: that is a vindication of free
software.  But that's not a victory over Apple or a concession of them.

> As a result of this victory, all sorts of companies are now working on
> *two* compilers that always give users freedom.  One is GCC.  The
> other is clang (I haven't noticed my freedom being diminished even a
> little bit when I set CC=clang). That is a good thing.

Several companies will not work on more than one compiler, and the
decision which compiler to work on will mainly determined by the ease of
working with and on the compiler.  That, in turn, is determined by
architectural differences, but in the case of GCC, it is now also
determined by shifting policies for the sake of interfering with
interoperability.

I find little surprise in companies preferring a platform where these
considerations are not an issue.  After all, the whole point of those
policies is to hit usability where it hurts.  Otherwise they would be
ineffective.

And in general there is nothing wrong with GCC or Emacs being
unpalatable for purposes at crossroads with free software.  That's the
whole point of the GPL as well.  The problem is that GCC and Emacs
become unpalatable for purposes compatible with free software's goals as
well.

> Apple is not composed of angels.  Apple does things that you and I
> would both regard as scummy.  But to suppose that Apple has any
> desire, need, or intention to attack GCC is to attribute an importance
> to GCC in Apple's eyes that it has not possessed since the day clang
> shipped 1.0.

I'm not sure about Apple's intentions at all.  But I don't think we
should be doing their job of persuading people to move away from GCC and
Emacs because they cannot be relied upon as an interoperable tool.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Perry E. Metzger]

On Sat, 7 Feb 2015 19:15:27 -0500 "Eric S. Raymond" <esr@thyrsus.com>
wrote:
> Richard Stallman <rms@gnu.org>:
> > More precisely, Apple intends LLVM and Clang to make GCC cease to
> > be a signal success and a reason for all sorts of companies to
> > work on a compiler that always gives users freedom.
> 
> This is silly.  Apple couldn't care less whether or not GCC is a
> success. What Apple needs is for a copylefted compiler not to be
> the *only* success.

I should like to correct a partial misperception here.

I don't think Apple's main motivation was to have a proprietary
compiler. On a purely technical level, LLVM makes lots of things
possible that Apple needed that GCC does not allow.

LLVM, for example, interfaces well to IDEs and refactoring tools,
which Apple needed, and now has built into XCode -- though note that
the support on the LLVM side is in the free software LLVM tree and is
in no way proprietary, and free software IDEs can make full use of
those interfaces. For another example, LLVM is modular so it is
possible to use it in producing static analysis tools, which Apple
needed, and are now built -- but again those analysis tools are in the
free software LLVM tree, not in a proprietary Apple tree, and may be
modified and incorporated into free software projects.

LLVM was created in academia, not by Apple, and it was specifically a
response to the fact that academics working on language tool and
compiler research simply couldn't manage to use GCC to get their work
done.  They wanted to do research on things like static analysis
tools, code transformation tools, link-time optimization, JITs, etc.,
and GCC deliberately makes it hard to use its pieces in such projects,
so they needed to build their own.

I myself use LLVM and not GCC for my academic research, which is
because my work is too difficult to do in GCC and very easy to do
under LLVM.

So to reiterate: LLVM was created because of GCC's deliberately
non-modular, non-reusable architecture, and not because GCC
was GPLed. The fact that LLVM is not GPLed and permits proprietary
forks is a side effect of the history (and potentially a very bad one)
but was not what caused LLVM to come about to begin with.

I think the lesson we can all draw is that architectural decisions
made for political strategy reasons are of limited utility.
Eventually, code designed for technical superiority will
become more popular than code with features missing for "strategic
reasons". If you want the more popular code to be free software, and
if you want it to be GPLed software, then you must assure that your
alternative is technically as good as it can be and suits the needs of
its users as well as it can.

As I understand it, the goal of making GCC non-modular was to prevent
the use of GCC to write proprietary front and back ends that do not
link directly to GCC. However, if GCC had been modular, it would have
been the focus of all the academic research, and all the tools built
on top would have been linked against GCC and thus would also have
been GPLed. In addition, Dragon Egg demonstrated that GCC could be
used as the front end to an LLVM compiler in spite of the
strategy. Also in addition, the non-modularity has not prevented the
creation of top quality proprietary front and back ends anyway, since
they can now be based on LLVM, which is arguably technically superior
to GCC at this point anyway and which permits that without much
trouble.

So again, I think if technical merit had been picked over "strategic
considerations", the strategic considerations would have been better
served.


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

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > So to reiterate: LLVM was created because of GCC's deliberately
  > non-modular, non-reusable architecture, and not because GCC
  > was GPLed. The fact that LLVM is not GPLed and permits proprietary
  > forks is a side effect of the history (and potentially a very bad one)
  > but was not what caused LLVM to come about to begin with.

That is true.  However, the issue for us is the effects of LLVM,
not its motivation.

  > So to reiterate: LLVM was created because of GCC's deliberately
  > non-modular, non-reusable architecture,

That is not so.  I made GCC as modular as I could.

  > As I understand it, the goal of making GCC non-modular was to prevent
  > the use of GCC to write proprietary front and back ends that do not
  > link directly to GCC.

I think you have got some misinformation here.

I made GCC as modular as I could.  The RTL level was the main
interface and I documented it with great thoroughness.  I tried
to make all interfaces as clean as possible.

But that was not my highest priority.

There is one thing I tried to discourage, many years later: separating
the front end and the back end into different processes.  You're
supposed to link the back end with the front end.

Designing modules to link together does not mean they are non-modular.

In 1988 it didn't occur to me that anyone would ever think of doing
that.  It would be too slow.  I took for granted that the front end
and back end would link together, and wrote them for that.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Perry E. Metzger]

On Tue, 10 Feb 2015 17:49:48 -0500 Richard Stallman <rms@gnu.org>
wrote:
>   > So to reiterate: LLVM was created because of GCC's deliberately
>   > non-modular, non-reusable architecture, and not because GCC
>   > was GPLed. The fact that LLVM is not GPLed and permits
>   > proprietary forks is a side effect of the history (and
>   > potentially a very bad one) but was not what caused LLVM to
>   > come about to begin with.
> 
> That is true.  However, the issue for us is the effects of LLVM,
> not its motivation.

Perhaps I am mistaken, but it *appears* you have characterized LLVM as
a deliberate attempt to destroy particular works (such as GCC) of the
Free Software Foundation. I was presenting evidence that no such
deliberation existed in the design. Similarly, you characterized LLDB
as a deliberate attempt to undermine GDB, not merely as something with
the possible effect of undermining it. If I'm mistaking what you
said, please do inform me, I would prefer not to be mischaracterizing
your position.

>   > So to reiterate: LLVM was created because of GCC's deliberately
>   > non-modular, non-reusable architecture,
> 
> That is not so.  I made GCC as modular as I could.

But I believe you have asked in the interim that GCC not be made more
modular out of fear of proprietary reuse of the front or back
end. This has the effect of interfering with re-use of the code even
when it is linked directly in to GPLed tools like Emacs. Was that not
the substance of the recent argument about Emacs and completion via
GCC, in which you requested more time to consider the issue?

> There is one thing I tried to discourage, many years later:
> separating the front end and the back end into different
> processes.  You're supposed to link the back end with the front end.

Generally, LLVM also operates as a single executable. It is true
that, for convenience, its intermediate representation may be
presented as text, as a high density binary format ("bitcode"), or as
internal data structures, but the latter is what is generally used to
pass things around since it avoids lots of input and output.

The distinction here, of course, is that LLVM does not *require* that
you link the components together, or indeed, that you use them as
a compiler at all.  It provides a lot of APIs -- indeed, all of LLVMs
components are libraries with a thin wrapper that hooks them
together. For example, LLVM permits you to link the front end Clang
parser directly into your code for various purposes, including to
provide things like AST access for IDEs.

Now, if GCC permitted such access, since GCCs code is GPLed,
presumably resultant software would also be GPLed, but if I am not
mistaken you do not seem very keen on permitting that for fear that
people would then build executables that separated compiler passes.
Thus, I think we can state that LLVM is more modular than GCC, and
not because of technical reasons but because of a strategic political
decision. Am I deeply mistaken here?

> Designing modules to link together does not mean they are
> non-modular.

I am afraid that I'm having trouble seeing what the ultimate
distinction is -- again, LLVM all links together too.

People can do things like building static analysis tools to find bugs
in their C and C++ code using LLVM, but they cannot do that with GCC
even though they would be linking to GCC's code because there was
a fear that excess access would lead to things like proprietary front
and back ends. People can do things like building intelligent IDEs
using LLVM, but cannot do things like linking GCC's code into Emacs
and allowing for building high quality refactoring IDEs out of the
combination because of this fear.

So, yes, GCC is, so far as I can tell, deliberately made more
difficult to use in tools in this manner by policy. If I'm deeply
mistaken, please correct me, but I thought that was the whole
substance of the recent discussion about AST access from GCC in Emacs.

> In 1988 it didn't occur to me that anyone would ever think of doing
> that.  It would be too slow.  I took for granted that the front end
> and back end would link together, and wrote them for that.

It is now 27 years later. People are willing to alter GCC to be as
modular as LLVM is I believe, but I also think you do not want that,
so I'm not sure discussing the initial architecture is entirely
germane. That said, again, if I am misapprehending your intent,
forgive me, and I would be very pleased to know what you actually
intend.


-- 
Perry E. Metzger		perry@piermont.com

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > Perhaps I am mistaken, but it *appears* you have characterized LLVM as
  > a deliberate attempt to destroy particular works (such as GCC) of the
  > Free Software Foundation.

That's what it is for Apple -- though rather than "destroy", I would
say "cause to cease to be important and influential".  Apple would not
care if some people continue to use GCC for something.

What directly affects us is the effects of LLVM, not the intentions.
If the effects are bad, good intentions can't override them.  If the
effects are not bad, there is no problem, regardless of any bad
intentions.

However, it is no coincidence that these bad effects result from
Apple's intentions.  These effects are what Apple is working for.

I ought to distinguish between Apple and the people who started LLVM.
In some of my previous messages, I failed to do this.  I was
influenced by an emotional reaction to the harsh attacks I received in
this list.

I don't think the people who started LLVM had any bad intentions.
I apologize for using words that suggested they did.

I just wish they had made sure Nvidia wouldn't be able to use their
work to make a nonfree compiler.

			      I was presenting evidence that no such
  > deliberation existed in the design.

Why would the program's _design_ have anything to do with any of this?

  > Similarly, you characterized LLDB
  > as a deliberate attempt to undermine GDB,

I said it might be that (for Apple).  I don't know whether it is that.

  > But I believe you have asked in the interim that GCC not be made more
  > modular out of fear of proprietary reuse of the front or back
  > end.

If you are talking about outputting ASTs, that has nothing to do with
how modular GCC is.  This is a different issue.

I want to make the right decision about the ASTs -- which means, think
carefully and calmly about the issue.  Is that a bad thing to do?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Perry E. Metzger]

On Wed, 11 Feb 2015 18:13:30 -0500 Richard Stallman <rms@gnu.org>
wrote:
>   > But I believe you have asked in the interim that GCC not be
>   > made more modular out of fear of proprietary reuse of the front
>   > or back end.
> 
> If you are talking about outputting ASTs, that has nothing to do
> with how modular GCC is.  This is a different issue.

If this is the case, returning to an earlier issue:

It might not per se necessary that Emacs have access to the AST in
textual form. If GCC or part of GCC could be called as a library from
within Emacs to access the AST via an API, that might be sufficient.
I don't yet have an opinion on whether it would be more or less
convenient than having the AST in some other form, but it would
certainly permit Emacs to have arbitrary access to semantic
information about the program being edited.

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

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

"Perry E. Metzger" <perry@piermont.com> writes:

> On Wed, 11 Feb 2015 18:13:30 -0500 Richard Stallman <rms@gnu.org>
> wrote:
>>   > But I believe you have asked in the interim that GCC not be
>>   > made more modular out of fear of proprietary reuse of the front
>>   > or back end.
>> 
>> If you are talking about outputting ASTs, that has nothing to do
>> with how modular GCC is.  This is a different issue.
>
> If this is the case, returning to an earlier issue:
>
> It might not per se necessary that Emacs have access to the AST in
> textual form. If GCC or part of GCC could be called as a library from
> within Emacs to access the AST via an API, that might be sufficient.

I'm reminded of a talk in a "fuzzy logic" conference I was in at one
time.  The resume from the authors was more or less that their novel
compression method achieved something like 20% of the signal theory
theoretical maximum performance, so if they got 10 times the funding,
they should be able to achieve about 200% of the theoretical maximum.

There is a principal basic problem that we cannot overcome with any
trickiness: Emacs and GCC are two separate, independent applications.
_Any_ way in which we are able to combine them will have a point where
Emacs as an application ends and/or a point where GCC ends.  At those
points, we can swap in a different IDE from Emacs, and a different
compiler from GCC, and copyright will not come into play.

The GPL is a license based on copyright and nothing else.  Any
complication we design for combining GCC and Emacs is going to hit the
combination GCC/Emacs just as hard as everyone else.

> I don't yet have an opinion on whether it would be more or less
> convenient than having the AST in some other form, but it would
> certainly permit Emacs to have arbitrary access to semantic
> information about the program being edited.

AST or any other form: the problem will remain identical.  What works
for the separate applications Emacs and GCC will work equally well with
respect to copyright by replacing one of the components.

So it is a waste of time thinking up ways to obfuscate the issue.  The
principal boundary condition of combining GCC and Emacs is that we have
two identifiable entities that are separate with regard to their
copyright.  What works for them, works for other entities with separate
copyright.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Stephen J. Turnbull]

David Kastrup writes:

 > There is a principal basic problem that we cannot overcome with any
 > trickiness: Emacs and GCC are two separate, independent
 > applications.  _Any_ way in which we are able to combine them will
 > have a point where Emacs as an application ends and/or a point
 > where GCC ends.

No trickiness needed, because copyright doesn't work that way, at
least not in the U.S.  Emacs and GCC remain separate, true.

However, linking them in a single process implies a process of (1)
making copies of each and then (2) editing the combination to make
communication possible via function calls (and possibly access to
global data).  This copying and editing legally creates a *new* work
which *as a whole* may be *presumed to be a derivative of GCC (and
Emacs as well), according to the generally accepted "exec boundary"
doctrine.  The internal data structure representing the AST is still
covered by GCC's copyright, and by GCC's license which applies to *the
whole* because of the copying and link-editing.  The same will be true
of IDE-X and GCC.

As usual, an individual user can write code to access the necessary
GCC modules, compile and link, and run the program in the privacy of
their own home, but distributing that program must be done under the
GPL.

This application of the GPL is as solid as any.  It will successfully
prevent GCC code from being abused in a proprietary combination.

Re: Contributing LLVM.org patches to gud.el

[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 might not per se necessary that Emacs have access to the AST in
  > textual form. If GCC or part of GCC could be called as a library from
  > within Emacs to access the AST via an API, that might be sufficient.

I am sure that can be done.

As has been said, GCC does not generate the parse tree for the whole
program, or even a whole function.  I initially thought of doing it
that way, but it used a lot of memory, so I made it generate RTL from
each expression tree and then throw the tree away.  It doesn't make
trees for statements at all.  At least, that's how it worked for C.

So it would first be necessary to make the parser generate and keep
the full trees, instead of generating RTL.

I think the term "AST" means a tree that corresponds precisely to the
syntax.  The GCC tree structure does not correspond precisely to the
syntax; the parser makes some simplifications and expansions itself.
So the tree is not really an AST.  This shouldn't affect completion
though.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Tom]

Perry E. Metzger <perry <at> piermont.com> writes:
> 
> It might not per se necessary that Emacs have access to the AST in
> textual form. If GCC or part of GCC could be called as a library from
> within Emacs to access the AST via an API, that might be sufficient.

I wonder how big is the actual C/C++ parsing code in GCC. If it
can be extracted it could even be linked statically with emacs.
Sure, in this case it would not be always the latest code, it 
should  be updated at every emacs release, but it would still 
provide a far superior AST feature than what currently is available
in emacs.

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: Tom <adatgyujto@gmail.com>
> Date: Fri, 13 Feb 2015 10:11:25 +0000 (UTC)
> 
> I wonder how big is the actual C/C++ parsing code in GCC. If it
> can be extracted it could even be linked statically with emacs.
> Sure, in this case it would not be always the latest code, it 
> should  be updated at every emacs release, but it would still 
> provide a far superior AST feature than what currently is available
> in emacs.

What for?  Now that there's a GCC library, you can simply call its
functions.

Re: Contributing LLVM.org patches to gud.el

[Tom]

Eli Zaretskii <eliz <at> gnu.org> writes:

> 
> What for?  Now that there's a GCC library, you can simply call its
> functions.
> 

I thought the main issue was that GCC did not provide full AST
information, in fear of it might be used by non free programs,
and therefore emacs can't access this information either.

So this is not an issue anymore and emacs has access to the full
AST from GCC? I thought this was not the case and that's why 
I mentioned the possibility of using GCC source code directly
in emacs and therefore having access to the full AST.

Re: Contributing LLVM.org patches to gud.el

[Eli Zaretskii]

> From: Tom <adatgyujto@gmail.com>
> Date: Fri, 13 Feb 2015 10:27:29 +0000 (UTC)
> 
> So this is not an issue anymore and emacs has access to the full
> AST from GCC?

Somebody should have written the code to allow such access.  If such
code was written, then yes.  If not, volunteers are welcome.  I don't
know which is true, but you can easily checkout the GCC development
tree and see for yourself what's in the library.

I do know that GDB uses the library to compile sources and inject the
generated code into an executable being debugged.

Re: Contributing LLVM.org patches to gud.el

[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 have avoided having GCC _write out_ full AST information.  Having
code linked with GCC to look at that info is ok (but, as explained
previously, does require work).

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> I ought to distinguish between Apple and the people who started LLVM.

That's a bit tricky to do since Chris Lattner, essentially LLVM's
project leader, was already employed by Apple (who hired him because of
his work on LLVM) when he offered the patches for integrating Clang for
inclusion into GCC in 2005.

> I don't think the people who started LLVM had any bad intentions.  I
> apologize for using words that suggested they did.
>
> I just wish they had made sure Nvidia wouldn't be able to use their
> work to make a nonfree compiler.

You mean, like offering to contribute the LLVM code to the GNU project?
Without the GNU project being interested in their code, the project
retained the original free license from the university it started at.

Nobody has been shooting us in our foot but ourselves.  And if we want
to avoid repetition or deterioration, it might be a good idea to stop
grasping for scapegoats.

Perhaps the most insidious thing we can blame Apple for is not messing
with the goose laying free eggs.  Apple most definitely is one of the
worst offenders when it comes to curtailing user freedom.  But their
system tooling culture has become much more ambivalent since they moved
to a UNIX-like system base.

>   > But I believe you have asked in the interim that GCC not be made
>   > more modular out of fear of proprietary reuse of the front or back
>   > end.
>
> If you are talking about outputting ASTs, that has nothing to do with
> how modular GCC is.  This is a different issue.
>
> I want to make the right decision about the ASTs -- which means, think
> carefully and calmly about the issue.  Is that a bad thing to do?

It depends on the kind of decision resulting.  Basically, thinking a
year each about the kind of decision that comes up once a month is
indistinguishable from "no" regarding the net result.  That is a bad
thing to do because it does not change anything but still annoys people.
If the decision is not just one of its kind but rather a general
decision applicable to a whole class of followup decisions, it is a good
thing since it stops uncertainty from piling up.

At the current point of time, your dictum is that every matter related
to LLVM needs to be vetted with you and considered individually.  If you
state that you will not make any individual decision without thinking
carefully and calmly and without pressure about it, then this is a
likely recipe for trouble since a growing pile of unsolved problems and
people in want of answers are quite detrimental to being able to decide
calmly and without pressure.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > That's a bit tricky to do since Chris Lattner, essentially LLVM's
  > project leader, was already employed by Apple (who hired him because of
  > his work on LLVM) when he offered the patches for integrating Clang for
  > inclusion into GCC in 2005.

I can still consider him and Apple separately and avoid attributing
Apple's motives to Lattner personally.

Apple may have been willing to cooperate in 2005 but it has certainly
changed its tune since then.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

You said

  > The distinction here, of course, is that LLVM does not *require* that
  > you link the components together, or indeed, that you use them as
  > a compiler at all.

and then you said

  > I am afraid that I'm having trouble seeing what the ultimate
  > distinction is -- again, LLVM all links together too.

However, from what you said above, LLVM doesn't NECESSARILY all link
together.  That is the point.

Anyway, LLVM is just for comparison.  Since it is not copylefted,
how its parts relate to each other does not affect anything.
The issue applies to GCC.

It is good for the parts of GCC to be modular.  And it is fine for
these modules to be able to link with other programs, too.

What I am worried about is for these modules to be used with nonfree
programs by NOT linking them together.  That that would lead
to proprietary use which ultimately is bad for users' freedom.

I prioritize users' freedom above technical merit, and that's why I
wrote GCC.  If not for that, I wouldn't have had to write a C compiler
at all -- I could have used one of the proprietary ones.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
> You said
>
>   > The distinction here, of course, is that LLVM does not *require* that
>   > you link the components together, or indeed, that you use them as
>   > a compiler at all.
>
> and then you said
>
>   > I am afraid that I'm having trouble seeing what the ultimate
>   > distinction is -- again, LLVM all links together too.
>
> However, from what you said above, LLVM doesn't NECESSARILY all link
> together.  That is the point.

Depending on the definition of "linking".  The LLVM project is, in a
way, a collection of compiler utilities, just like we have GNU textutils
and GNU dirutils (which are now combined into something).  The copyright
from cat has no hold over the distribution of tac.  In a similar vein,
the copyright of Bison has no hold over the distribution of Flex, and
yet we do not consider Flex an attack on GNU.

> Anyway, LLVM is just for comparison.  Since it is not copylefted,
> how its parts relate to each other does not affect anything.
> The issue applies to GCC.
>
> It is good for the parts of GCC to be modular.  And it is fine for
> these modules to be able to link with other programs, too.
>
> What I am worried about is for these modules to be used with nonfree
> programs by NOT linking them together.  That that would lead
> to proprietary use which ultimately is bad for users' freedom.
>
> I prioritize users' freedom above technical merit, and that's why I
> wrote GCC.  If not for that, I wouldn't have had to write a C compiler
> at all -- I could have used one of the proprietary ones.

Those compilers were not free.  Prioritizing users' freedom above
technical merit did not force us to rewrite the non-copylefted X Window
System, or to rewrite the non-copylefted Flex (which I believe to be
still used for generating part of GCC).  It did not force us to replace
TeX which Texinfo, the GNU documentation system, uses for generating all
of its printed manuals.

Let me quote from the GNU Manifesto, from the section "Some Easily
Rebutted Objections to GNU's Goals":

    “Competition makes things get done better.”

    The paradigm of competition is a race: by rewarding the winner, we
    encourage everyone to run faster. When capitalism really works this
    way, it does a good job; but its defenders are wrong in assuming it
    always works this way. If the runners forget why the reward is
    offered and become intent on winning, no matter how, they may find
    other strategies—such as, attacking other runners. If the
    runners get into a fist fight, they will all finish late.

    Proprietary and secret software is the moral equivalent of runners
    in a fist fight. Sad to say, the only referee we've got does not
    seem to object to fights; he just regulates them (“For every ten
    yards you run, you can fire one shot”). He really ought to break
    them up, and penalize runners for even trying to fight.

At the current point of time, I see us getting into fist fights with
other free software.  Clang/LLVM do not exist because Apple wants to
damage GCC: the initial Clang code was offered by its author working at
Apple for inclusion into GCC in 2005.  Of course, this would have
included the respective copyright assignments.  This contribution was
rejected.  Not even on philosophical grounds, but rather mostly because
of technical reasons that have by now become irrelevant.

The reason Clang/LLVM thrived even without GCC is because it met
technical needs that GCC was not able to cater for satisfactorily.
These reasons were initially rooted in the history and code base of GCC.
However, in the last decade they have increasingly become political,
focused on avoiding the reuse of GCC for things not planned by its
developers and/or copyright owners.

But flexible reuse of components is the reason for the success of
UNIX-like operating systems including GNU.  It is what enables research
and development and rapid prototyping, and consequently strong roots
into academics.

By confining the use of GNU to those software designs which cannot be
untangled without triggering copyright problems, we are no longer
hacking copyright for the sake of software freedom, but we are hacking
software freedom for the sake of copyright.  We have managed to turn
copyright into a weapon we wield against ourselves.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > > However, from what you said above, LLVM doesn't NECESSARILY all link
  > > together.  That is the point.

  > Depending on the definition of "linking".

The usual definition of linking is that modules are loaded into one
address space and refer to each others functions and variables.
That's the definition I'm using.

  > > I prioritize users' freedom above technical merit, and that's why I
  > > wrote GCC.  If not for that, I wouldn't have had to write a C compiler
  > > at all -- I could have used one of the proprietary ones.

  > Those compilers were not free.  Prioritizing users' freedom above
  > technical merit did not force us to rewrite the non-copylefted X Window
  > System,

That is true.  But we do have a copylefted compiler, and it has aided
users' freedom tremendously by leading many companies to release free
compilers for their hardware.  LLVM has cut off our ability to do that,
and that will be a big loss to users' freedom.

Whatever advantages LLVM may have, they don't compensate for this big
harm.

  > the initial Clang code was offered by its author working at
  > Apple for inclusion into GCC in 2005.  Of course, this would have
  > included the respective copyright assignments.  This contribution was
  > rejected.  Not even on philosophical grounds, but rather mostly because
  > of technical reasons that have by now become irrelevant.

If that is what happened, what it shows is that GCC developers can
make mistakes in anticipating future developments and how to cope with
them.  They aren't perfect, and neither am I.

Someone else described this to me in a different way -- he said that the
copyright assignment discussion petered out.

I don't know which way it really happened, but it doesn't really
matter -- it doesn't affect the issues at stake.  If it were just our
success at stake, you could say we deserve not to succeed because we
made a mistake.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Florian Weimer]

* Eric S. Raymond:

> Richard Stallman <rms@gnu.org>:
>> More precisely, Apple intends LLVM and Clang to make GCC cease to be a
>> signal success and a reason for all sorts of companies to work on a
>> compiler that always gives users freedom.
>
> This is silly.  Apple couldn't care less whether or not GCC is a success.
> What Apple needs is for a copylefted compiler not to be the *only* success.

Access to large parts of the Apple developer ecosystem now requires a
subscription.  Subscription agreements can be worded in ways that put
customers in breach of the agreement if they exercise their rights
under the copyleft licenses, and the vendor is still in full
compliance with the copyleft licenses.  Sure, the customer can
terminate the subscription agreement and then take the source code and
try to rebuild it, but only at the price of leaving the ecosystem.
(I think some of the game consoles actually implemented this model.)

In short, I doubt that Apple really needs a non-copyleft compiler.

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > Access to large parts of the Apple developer ecosystem now requires a
  > subscription.  Subscription agreements can be worded in ways that put
  > customers in breach of the agreement if they exercise their rights
  > under the copyleft licenses, and the vendor is still in full
  > compliance with the copyleft licenses.

Distributing under a contract that doesn't allow the user to exercise
the GPL rights is a violation of the GPL.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Liang Wang]

On Sat, Feb 7, 2015 at 2:40 PM, 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. ]]]
>
>   > LLVM is not meant to kill GCC
>
> More precisely, Apple intends LLVM and Clang to make GCC cease to be a
> signal success and a reason for all sorts of companies to work on a
> compiler that always gives users freedom.  That would be a victory for
> Apple and a defeat for freedom.

At least once, Apple proposed to integrate LLVM as part of GCC.
https://gcc.gnu.org/ml/gcc/2005-11/msg00888.html


>
> I don't know what LLDB is, or what it might do.  I am going to find
> out.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! See stallman.org/skype.html.
>
>

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Liang Wang <netcasper@gmail.com> writes:

> On Sat, Feb 7, 2015 at 2:40 PM, 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. ]]]
>>
>>   > LLVM is not meant to kill GCC
>>
>> More precisely, Apple intends LLVM and Clang to make GCC cease to be a
>> signal success and a reason for all sorts of companies to work on a
>> compiler that always gives users freedom.  That would be a victory for
>> Apple and a defeat for freedom.
>
> At least once, Apple proposed to integrate LLVM as part of GCC.
> https://gcc.gnu.org/ml/gcc/2005-11/msg00888.html

I think they are more or less "meh" about programmers using free
software.  Programmers have to use something, after all, and if somebody
else does the work, so much the better (which explains why they departed
from their entirely homegrown MacOS and jumped on a POSIX platform).

What they are dead set against is _user_ freedom.  They don't mind if
people have great tools to write programs, but they want to be in
control of the software their customers run particularly on devices like
phones.

That's what the GPLv3 is about.  In my opinion, at least the anti-DRM
provisions of the GPLv3 alone would not likely have made much of a
difference regarding whether Apple chooses to adopt or not adopt GCC
since bringing the operation of GCC itself under DRM is unlikely to be
useful to Apple anyway.  I rather think that the implied patent license
is what keeps Apple clean off GPLv3 altogether since its effects extend
beyond the program itself into an area where insane amounts of money can
be made to pass hands for the most ridiculous reasons.

Having this mad tea party table tilted against them might result in a
lot of china crashing in their lap.

At any rate, the GPL always was about "if you use our software, you get
to share it under our conditions or roll your own" and it is entirely
expected that particularly the big players consider "roll your own" a
more predictable choice in business regards.

We won't easily catch the big fish, and our increasing unpredictability
chases away the small ones too.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > > More precisely, Apple intends LLVM and Clang to make GCC cease to be a
  > > signal success and a reason for all sorts of companies to work on a
  > > compiler that always gives users freedom.  That would be a victory for
  > > Apple and a defeat for freedom.

  > At least once, Apple proposed to integrate LLVM as part of GCC.

That appears to have been in 2005, before GPL v3 was published.
GPL v3 is what Apple hates, because of its patent protection.

By replacing most of GCC with non-copylefted code, they would have
gone most of the way towards achieving the same result: to make GCC
cease to be a reason for all sorts of companies to work on a compiler
that always gives users freedom.  Because GCC would have come much
closer to failing to always give users freedom.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > > More precisely, Apple intends LLVM and Clang to make GCC cease to be a
>   > > signal success and a reason for all sorts of companies to work on a
>   > > compiler that always gives users freedom.  That would be a victory for
>   > > Apple and a defeat for freedom.
>
>   > At least once, Apple proposed to integrate LLVM as part of GCC.
>
> That appears to have been in 2005, before GPL v3 was published.
> GPL v3 is what Apple hates, because of its patent protection.

But the current attempts to strike against LLVM by making it harder to
interoperate with Emacs and GCC are _irrelevant_ with regard to patent
protection: the patent protection applies even for mere aggregation.

We are not changing Apple's policies.  What we are now doing is lashing
out against LLVM's users.  But they are not going to have a vote in what
compilers Apple provides/uses/permits anyway.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > > That appears to have been in 2005, before GPL v3 was published.
  > > GPL v3 is what Apple hates, because of its patent protection.

  > But the current attempts to strike against LLVM by making it harder to
  > interoperate with Emacs and GCC are _irrelevant_ with regard to patent
  > protection: the patent protection applies even for mere aggregation.

You've taken pieces from two different puzzles and observed that they
don't fit together.  It's true, but no surprise.

  > We are not changing Apple's policies.

That is true.  I don't see any way we can change Apple's policies.

  >   What we are now doing is lashing
  > out against LLVM's users.

What I said is that this calls for a thoughtful decision,
not a reflexive snap decision.  You're putting an emotional
charge on it that has nothing to do with me.  It comes from you.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > > That appears to have been in 2005, before GPL v3 was published.
>   > > GPL v3 is what Apple hates, because of its patent protection.
>
>   > But the current attempts to strike against LLVM by making it
>   > harder to interoperate with Emacs and GCC are _irrelevant_ with
>   > regard to patent protection: the patent protection applies even
>   > for mere aggregation.
>
> You've taken pieces from two different puzzles and observed that they
> don't fit together.  It's true, but no surprise.

An effective defense should countermand the damage from an attack.  So
if the defense does not fit the attack, it may not be worth its price.

>   > We are not changing Apple's policies.
>
> That is true.  I don't see any way we can change Apple's policies.
>
>   >   What we are now doing is lashing
>   > out against LLVM's users.
>
> What I said is that this calls for a thoughtful decision,
> not a reflexive snap decision.

    It is a profoundly erroneous truism, repeated by all copy-books and
    by eminent people when they are making speeches, that we should
    cultivate the habit of thinking of what we are doing. The precise
    opposite is the case. Civilisation advances by extending the number
    of important operations which we can perform without thinking about
    them. Operations of thought are like cavalry charges in a battle:
    they are strictly limited in number, they require fresh horses, and
    must only be made at decisive moments.

    An Introduction to Mathematics, 1911

What I am trying to say here is that we need to come to a state where a
project manager can in the overwhelming majority of cases reliably make
a reflexive snap decision in concordance with GNU's goals and
agreed-upon rules.  Nobody wants to be considered unfit to do the job he
is tasked to do.

> You're putting an emotional charge on it that has nothing to do with
> me.  It comes from you.

Well, I'm not engaged in free software because of the financial bottom
line.  So I may indeed be guilty of being emotionally invested.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[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 I am trying to say here is that we need to come to a state where a
  > project manager can in the overwhelming majority of cases reliably make
  > a reflexive snap decision in concordance with GNU's goals and
  > agreed-upon rules.  Nobody wants to be considered unfit to do the job he
  > is tasked to do.

It's very simple.  Anything that relates to LLVM is a strategic issue,
so maintainers should talk with me privately about what to do.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Robin Templeton]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > > More precisely, Apple intends LLVM and Clang to make GCC cease to be a
>   > > signal success and a reason for all sorts of companies to work on a
>   > > compiler that always gives users freedom.  That would be a victory for
>   > > Apple and a defeat for freedom.
>
>   > At least once, Apple proposed to integrate LLVM as part of GCC.
>
> That appears to have been in 2005, before GPL v3 was published.
> GPL v3 is what Apple hates, because of its patent protection.
>
> By replacing most of GCC with non-copylefted code, they would have
> gone most of the way towards achieving the same result: to make GCC
> cease to be a reason for all sorts of companies to work on a compiler
> that always gives users freedom.  Because GCC would have come much
> closer to failing to always give users freedom.

That would not have happened under the original proposal, which included
assigning the LLVM copyright to the FSF:

"If people are seriously in favor of LLVM being a long-term part of GCC,
I personally believe that the LLVM community would agree to assign the
copyright of LLVM itself to the FSF and we can work through these
details."

-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!

Re: Contributing LLVM.org patches to gud.el

[Perry E. Metzger]

On Mon, 09 Feb 2015 11:15:20 -0500 Robin Templeton <robin@terpri.org>
wrote:
> Richard Stallman <rms@gnu.org> writes:
> > By replacing most of GCC with non-copylefted code, they would have
> > gone most of the way towards achieving the same result: to make
> > GCC cease to be a reason for all sorts of companies to work on a
> > compiler that always gives users freedom.  Because GCC would have
> > come much closer to failing to always give users freedom.
> 
> That would not have happened under the original proposal, which
> included assigning the LLVM copyright to the FSF:
> 
> "If people are seriously in favor of LLVM being a long-term part of
> GCC, I personally believe that the LLVM community would agree to
> assign the copyright of LLVM itself to the FSF and we can work
> through these details."

Indeed. I think it is important that people understand that the
motivation of the academics (not Apple) who started the LLVM project
was to make it easier to work on language processing tools, JITs and
the like. Their goal was not to make proprietary software, it was to
get their work done. I concur that at one time the LLVM crowd
largely would have welcomed merging their work into GCC. That time
has, of course, passed.

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

Re: Contributing LLVM.org patches to gud.el

[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 wrote this

  > > By replacing most of GCC with non-copylefted code, they would have
  > > gone most of the way towards achieving the same result: to make GCC
  > > cease to be a reason for all sorts of companies to work on a compiler
  > > that always gives users freedom.  Because GCC would have come much
  > > closer to failing to always give users freedom.

when I saw your message.  At that time all I could see was what was in
your message.  At the same time I sent another message to get a copy
of https://gcc.gnu.org/ml/gcc/2005-11/msg00888.html.  That arrived
subsequently.

Because my mail is sent in batches, I am generally responding to messages
from a day before.

  > "If people are seriously in favor of LLVM being a long-term part of GCC,
  > I personally believe that the LLVM community would agree to assign the
  > copyright of LLVM itself to the FSF and we can work through these
  > details."

I am stunned to see that we had this offer.
Now, based on hindsight, I wish we had accepted it.

If I had seen it back then, I would not have had the benefit of
hindsight, but it would clearly have been a real possibility.  Nothing
would have ruled it out.

I wish I had known about the offer.

Oh well.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Helmut Eller]

On Mon, Feb 09 2015, Richard Stallman wrote:

> If I had seen it back then, I would not have had the benefit of
> hindsight, but it would clearly have been a real possibility.  Nothing
> would have ruled it out.

Has somebody asked Chris Lattner, who seems to the leader on the LLVM
project, if they are willing to change the license now to simplify
coexistence with the GCC project?  His answer would be more interesting
than speculations about Apple's intentions.

Helmut

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Mon, Feb 09 2015, Richard Stallman wrote:
>
>> If I had seen it back then, I would not have had the benefit of
>> hindsight, but it would clearly have been a real possibility.  Nothing
>> would have ruled it out.
>
> Has somebody asked Chris Lattner, who seems to the leader on the LLVM
> project, if they are willing to change the license now to simplify
> coexistence with the GCC project?

Sorry, but that's rubbish.  LLVM is licensed under the UI/NCSAOSL
license which is compatible with all versions of the GPL.  Everybody has
the freedom to take the code and incorporate it into a GPL-licensed
work.  You can take whatever LLVM code you want and integrate it into
GCC while licensing your changes under any GPL version.

There is absolutely nothing the LLVM team could do more other than
assigning all of their copyrights to the FSF in order to hand over
licensing and development control.  And seeing how GCC fares with that
regarding extensibility, I would not exactly blame them when they are
not interested in that.  But I'd be surprised if such a ridiculous idea
had even crossed their mind.

At any rate, I seem to remember that somebody else mentioned in this
thread Apple having offered to contribute their Clang/Dragonegg work to
GCC proper and getting rejected.  So it seems that this option even was
on the table at one point of time in history.

> His answer would be more interesting than speculations about Apple's
> intentions.

If you are interested in seeing how people react to ridiculous requests,
maybe.

This is at the current point of time entirely our problem.  If we wanted
to start a GPLed fork or variant of LLVM, we would be free to do so.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Helmut Eller]

On Tue, Feb 10 2015, David Kastrup wrote:

> There is absolutely nothing the LLVM team could do more other than
> assigning all of their copyrights to the FSF in order to hand over
> licensing and development control.

They could use multiple licenses like some other projects do, or they
could say that they prefer to help NVIDIA than to help the FSF.  But
this is just speculation as neither me nor you are in charge of LLVM.

Helmut

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Tue, Feb 10 2015, David Kastrup wrote:
>
>> There is absolutely nothing the LLVM team could do more other than
>> assigning all of their copyrights to the FSF in order to hand over
>> licensing and development control.
>
> They could use multiple licenses like some other projects do,

That's nonsense.  They are using a GPL compatible license already.
There is no point in making a "dual-license" release when one license
already implies all the rights of the other anyway.

> or they could say that they prefer to help NVIDIA than to help the
> FSF.  But this is just speculation as neither me nor you are in charge
> of LLVM.

It is not speculation but nonsense.  LLVM is already released under GPL
compatible terms.  They _are_ already giving us permission for all we
could ask of them.  You can make a GPL-only release of LLVM today if you
want to.  This "they could say that they prefer to help NVIDIA than to
help the FSF" is a load of bollocks.

What else do you want?  Tell them to dissolve their own community and
commit ritual suicide?  Those interested in LLVM will still be able to
take the code and continue developing it.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Helmut Eller]

On Tue, Feb 10 2015, David Kastrup wrote:

> It is not speculation but nonsense.  LLVM is already released under GPL
> compatible terms.  They _are_ already giving us permission for all we
> could ask of them.

They are also giving NVIDIA permission to do whatever it likes to do
with it.

> You can make a GPL-only release of LLVM today if you
> want to.  This "they could say that they prefer to help NVIDIA than to
> help the FSF" is a load of bollocks.

A hypothetical GNU LLVM project that is distinct from the original
project would have a hard time to attract people.

> What else do you want?

I, as an individual, don't care.  But the FSF does care very much about
the distinction between the licenses.  If the FSF stops caring about the
distinction then it can just declare defeat and stop promoting the GPL.

> Tell them to dissolve their own community and
> commit ritual suicide?

Changing the license would hardly be suicide.  Apple could still be the
main contributor and they managed to survive even when they had to use
GCC.  It would piss off NVIDIA but it might attract some other
individuals who don't like the idea that NVIDIA profits from their
contributions.  Either way, you don't make those decisions.

Helmut

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Tue, Feb 10 2015, David Kastrup wrote:
>
>> It is not speculation but nonsense.  LLVM is already released under
>> GPL compatible terms.  They _are_ already giving us permission for
>> all we could ask of them.
>
> They are also giving NVIDIA permission to do whatever it likes to do
> with it.
>
>> You can make a GPL-only release of LLVM today if you
>> want to.  This "they could say that they prefer to help NVIDIA than to
>> help the FSF" is a load of bollocks.
>
> A hypothetical GNU LLVM project that is distinct from the original
> project would have a hard time to attract people.

And whose fault is that?  Why would people be interested in a fork whose
primary purpose would be to make the compiler less modular and stop it
from interoperating with modules they might want to write?

Because non-modularity is exactly what GCC is supposed to provide in
order not to create module boundaries where the reach of the GPL ends.

The current LLVM licensing, community, and architecture does not provide
that temptation.

>> What else do you want?
>
> I, as an individual, don't care.  But the FSF does care very much
> about the distinction between the licenses.  If the FSF stops caring
> about the distinction then it can just declare defeat and stop
> promoting the GPL.

The LLVM is licensed GPL-compatibly.

>> Tell them to dissolve their own community and commit ritual suicide?
>
> Changing the license would hardly be suicide.

It would most definitely cause a fork.  And since the community focuses
on modularity and our compilers must not provide modularity, it would
indeed require taking out the majority of developers to cause enough of
a break of continuity for the GNU project to step up.

At any rate, Chris Lattner _had_ offered integrating LLVM into GCC in
2005.  He did all of the integration work and offered completed
patches.  These patches were rejected.  Partly because bootstrapping
from C++ was undesired (GCC now bootstraps from C++), partly because the
modularity was undesired in GCC.

Modularity is the main point of LLVM.  Chopping it away in order to slap
on a GPL that actually stings is pretty much the same as ritual suicide.
I doubt we'll persuade the whole developer community to do that.

> Apple could still be the main contributor and they managed to survive
> even when they had to use GCC.  It would piss off NVIDIA but it might
> attract some other individuals who don't like the idea that NVIDIA
> profits from their contributions.  Either way, you don't make those
> decisions.

For better or worse, a lot of decisions _have_ been made, _by_ the GNU
project.  These decisions had consequences with companies and
individuals seeking their own solutions for problems that the GNU
project considered too dangerous to approach.  The current situation is
not the outcome of a coordinated attack against the GNU project but
rather the most obvious and natural consequence of our own actions, and
it's time that we started to deal with the consequences of our actions
in a graceful and mature and most particularly not self-destructive
manner.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Yann Hodique]

>>>>> "Helmut" == Helmut Eller <eller.helmut@gmail.com> writes:

>> Tell them to dissolve their own community and
>> commit ritual suicide?

> Changing the license would hardly be suicide.  Apple could still be the
> main contributor and they managed to survive even when they had to use
> GCC.  It would piss off NVIDIA but it might attract some other
> individuals who don't like the idea that NVIDIA profits from their
> contributions.  Either way, you don't make those decisions.

I find that claim (that a license change would annoy the NVIDIAs of the
world) very odd.

After all, the core of the entire issue, and this whole discussion, is
that the FSF did object to *technical possibilities* in order to counter
those same people, effectively deeming the GPL alone insufficient to
reach that goal. So now we cannot possibly be suggesting that slapping
a GPL sticker on LLVM could solve the "issue", can we?

I mean, one (at least...) of the following has to be true:
- the modularity of LLVM (GPL or not) allows access to the internals of
  a compilation phase in a textual form, making it easy for people to
  pipe a non-free component where they fancy
- the GPL is enough to push non-free components away (or is the best we
  can do anyway), and we've been wasting time and opportunities
  protecting something that doesn't exist

Bottom line, we cannot say that a GPL compiler (GCC) made modular would
have been a problem, but that a modular compiler (LLVM) made GPL would
be a solution. In the end, they'd be both modular and GPL, right?

Thanks,

Yann.

-- 
Speak the truth.  That is always much easier,
and is often the most powerful argument.

  -- Bene Gesserit Axiom

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Yann Hodique <yann.hodique@gmail.com> writes:

>>>>>> "Helmut" == Helmut Eller <eller.helmut@gmail.com> writes:
>
>>> Tell them to dissolve their own community and
>>> commit ritual suicide?
>
>> Changing the license would hardly be suicide.  Apple could still be the
>> main contributor and they managed to survive even when they had to use
>> GCC.  It would piss off NVIDIA but it might attract some other
>> individuals who don't like the idea that NVIDIA profits from their
>> contributions.  Either way, you don't make those decisions.
>
> I find that claim (that a license change would annoy the NVIDIAs of the
> world) very odd.
>
> After all, the core of the entire issue, and this whole discussion, is
> that the FSF did object to *technical possibilities* in order to counter
> those same people, effectively deeming the GPL alone insufficient to
> reach that goal. So now we cannot possibly be suggesting that slapping
> a GPL sticker on LLVM could solve the "issue", can we?
>
> I mean, one (at least...) of the following has to be true:
> - the modularity of LLVM (GPL or not) allows access to the internals of
>   a compilation phase in a textual form, making it easy for people to
>   pipe a non-free component where they fancy
> - the GPL is enough to push non-free components away (or is the best we
>   can do anyway), and we've been wasting time and opportunities
>   protecting something that doesn't exist

There can perfectly well be a truth in the middle.  Closing GCC down
regarding modularity may have provided _extra_ leverage over the
coercive nature of the GPL, leverage that is _now_ eroded through LLVM's
existence and licensing.  So the exact details were a _temporary_
strategy (also known as tactics) catered to the current situation.  We
don't have the same leverage any more but that does not mean that there
is none left over those who are still to some degree invested in
using GCC.

If tactics are supposed to provide a net advantage, one needs to monitor
the situation closely and adapt the tactics accordingly and swiftly.  It
turns out that our managerial structures are not really set up to
facilitate swift and flexible response, so it's not clear to me that
playing with tactics where the success depends on timely reaction to
third parties is a good match for GNU.

> Bottom line, we cannot say that a GPL compiler (GCC) made modular
> would have been a problem, but that a modular compiler (LLVM) made GPL
> would be a solution. In the end, they'd be both modular and GPL,
> right?

The state "in the end" does not mean that we should not try deriving
best benefits from the situation where they are still non-equivalent.

      -1                -2
 lim x   = 0  and  lim x   = 0
x->oo             x->oo

But still

  inf
   /
  |    -1    -2
  |  (x   - x  ) dx  =>  inf
  | 
 /  
 1  

So there is nothing wrong to make the best of the difference while it is
there.  As long as one keeps an eye on it.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > > There is absolutely nothing the LLVM team could do more other than
  > > assigning all of their copyrights to the FSF in order to hand over
  > > licensing and development control.

David is right.  The license of LLVM is free.  We can use that code
if we want to.

The problem that LLVM causes for the GNU Project is that, when used,
it replaces GCC with a non-copylefted program.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > > There is absolutely nothing the LLVM team could do more other than
>   > > assigning all of their copyrights to the FSF in order to hand over
>   > > licensing and development control.
>
> David is right.  The license of LLVM is free.  We can use that code
> if we want to.
>
> The problem that LLVM causes for the GNU Project is that, when used,
> it replaces GCC with a non-copylefted program.

Which means that proprietary forks become possible.  However, I think we
would do well to view the consequences of that danger in detail.  While
GNU and GCC provide us with a stronghold entirely under our control,
reigns are not restricted to a stronghold.

I think we would be better off distinguishing between LLVM as an ally
neither under our control nor protection, and parties like Nvidia who
forge proprietary variants and tools from LLVM.

It would be comparatively easy to make a campaign "don't buy from the
unfreeloaders", for example, that highlights the consequences of tieing
yourself to those who "unfreeload", namely create proprietary tools from
non-copylefted free software.

The damage they cause to their users is real and tangible, and yet
instead of making a campaign from pointing that out, we consider LLVM
the source of badness.

Here is how the damage is real and tangible as one example: I had bought
one used Thinkpad T61 with some Intel or AMD graphics card, making sure
I got no Nvidia, for my work.  When its fan broke down, another user of
GNU LilyPond provided me with the same laptop model, but with an Nvidia
card inside.

What are the consequences?  The drivers are now no longer free (either
that, or of rather low quality because Nvidia provides neither work nor
specs).  Since this laptop is in its "second life" (the GNU/Linux system
requirements are quite lower than "up-to-date" Windows would demand, so
the hardware remains perfectly usable), continuing support from Nvidia
is at best lacklustre.

Half of the time I hibernate the computer, it won't wake up again.  I
always have to put it to sleep instead if I want to continue to work.
That means that the batteries have to be loaded whenever I stop working
for longer, detracting from its battery life.  Even when put to sleep,
in about 1 case out of 20 it will not wake up.  Previously, I used the
space-efficient i586 runtime while running on an amd64 kernel.  That
way, I was able to compile and test 64bit executable (using special gcc
options) even while most of my system remained 32bit.

The Nvidia graphics drivers were unable to deal with that setup, meaning
that I can no longer use that setup for my computer.  And it is
impossible for the kernel developers to fix this breakage.

If you see in comparison that just recently Linus Torvalds refrained
from removing EISA bus support from current Linux kernels because there
was a user piping up who still needed them, it is clear that the
non-free driver policy renders your hardware deficient from the start
and it seriously devalues its resale value when continued support and
free operating system compatibility become important.

So we really, really, really should make sure to spread the message that
the hardware from vendors creating unfree and partly secret toolchains
and drivers is crippling its users from the start, and is destroying the
resale value of used hardware because of planned or tolerated early
obsolescence.

The more we point this out, the more it will actually show itself to
make a difference in resale price of hardware, and ultimately in sales
price of hardware.

I think it is much more important, relevant and effective for us to
fight the non-free misuse of LLVM for subverting user freedom than
fighting LLVM itself.

One feature of the GPL is that it saves us from making the case for Free
Software: it replaces proselytizing with a reward: for staying within
the GPL universe, you get to use the GPL universe.

With LLVM, we have to turn to proselytizing again.  But I don't see that
it makes sense to proselytize against non-copylefted free software since
that is not our actual enemy: what the GNU project and the GPL fight is
non-free software, not non-copylefted software.  Instead we need to
proselytize against non-free software and its bad effects, and point
them out again and again.

If people get sensitized against the damage non-free software is causing
them again and again, _this_ might cause a community eventually to
consider transferring to a copylefted software scheme.  But us vilifying
them will not in any manner incite them to join our ranks on the side of
free software that is protected by copyleft.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Stefan Monnier]

> I think it is much more important, relevant and effective for us to
> fight the non-free misuse of LLVM for subverting user freedom than
> fighting LLVM itself.

Indeed.  It's even a great way to advertize the GPL, by pointing out
that those abuses would not have been possible if LLVM had been GPL'd.


        Stefan "OpenWRT wouldn't exist if it weren't for the GPL"

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > Indeed.  It's even a great way to advertize the GPL, by pointing out
  > that those abuses would not have been possible if LLVM had been GPL'd.

That is an interesting idea.  I passed it on.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Florian Weimer]

* Richard Stallman:

> By replacing most of GCC with non-copylefted code, they would have
> gone most of the way towards achieving the same result: to make GCC
> cease to be a reason for all sorts of companies to work on a
> compiler that always gives users freedom.

I'm pretty sure more work is still done on GCC under NDA than on LLVM,
and GCC's copyleft license may even play a role in that.

What does user freedom matter if they never even get to use the code?

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Florian Weimer <fw@deneb.enyo.de> writes:

> * Richard Stallman:
>
>> By replacing most of GCC with non-copylefted code, they would have
>> gone most of the way towards achieving the same result: to make GCC
>> cease to be a reason for all sorts of companies to work on a
>> compiler that always gives users freedom.
>
> I'm pretty sure more work is still done on GCC under NDA than on LLVM,
> and GCC's copyleft license may even play a role in that.
>
> What does user freedom matter if they never even get to use the code?

If they don't get to use the code, they don't pay for it and don't
support it.  They are not worse off for it.

The problem with proprietary code is that its users pay a price without
getting control over their own property.  Code under NDA does not do
that.  It's still not pretty when GNU code ends up in such
circumstances, but the damage is confined as proliferation and
dissemination have to be very limited before the GPL starts rearing its
pretty tail.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[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'm pretty sure more work is still done on GCC under NDA than on LLVM,

I doubt that anyone is in a position to know.  But the two are not
comparable anyway.

A version of GCC made under NDA can't be redistributed by the company
that commissioned it.  The GNU GPL requires that.

By contrast, LLVM is not copyefted, the company that commissioned a
modified version under NDA can distribute proprietary binaries.

  > What does user freedom matter if they never even get to use the code?

What does release of the code matter, if it would deny users their freedom?

The basic idea of the free software movement is that users should have
freedom for all the software they use.  A proprietary program is worse
than no program.  A proprietary program is an injustice.

We use copyleft to insist: either release your modified version as
source in the same way, or keep it private, but do not distribute it
in a way that would separate people from their freedom.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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 cannot see how it differs from us supporting MS Windows and MacOSX in
>   > Emacs.  The metric we employed here was not to install support for any
>   > functionality restricted to the use of those operating systems.
>
> These are not similar cases.  Neither Windows nor MacOS was intended
> to push major GNU packages out of use.

Basing MacOS9 (?) off a Mach/BSD kernel could have been that but what
started out as a semi-open strategy for Darwin was eventually suffocated
by the Apple culture with its preference of locking things down and
keeping them secret.

Still it was much more going into the "push out of use" direction than
this here is.  Microsoft also had a serious push against free operating
systems with its SFU (Services for Unix, Interix), a seriously outdated
GNU userland interacting closer with the Windows NT kernel than either
Cygwin or Mingw32.

> What I see here appears possibly to be exactly that.  Whether that is
> the case is what I want to find out.

I don't see that, but of course you'll be doing your own assessment.

However, this _is_ actually related to the recent LLVM/GCC/AST
discussions we had here in that it again concerns throwing a spanner
into interoperability.

Emacs _is_ glue for tieing applications together into one editing
surface.  And gud.el is designed for interoperability and tieing into a
variety of different debuggers.  This has been one of its design goals
for decades, and it does support various other debuggers different from
gdb, including proprietary ones (at least the SVR4+ family of debuggers
was proprietary for a long time, and in spite of the existence of
OpenSolaris, most variants of them probably still are).

Supporting another debugger is what gud.el has been _designed_ to
support, and Emacs has been designed to interact with lots of
applications.

That's one of its principal strengths.  Trying to mess with that takes
away one of the fundamental attractions of Emacs, namely being
universally useful.

This universal usefulness has a lot of aspects: large platform support
(also helped by GCC targets and autoconf), lots of ports, generic
interfaces and so on.  It has been one of the historic pillarstones of
the GNU projects: one of the fundamental attractions of the GNU userland
was that you could get it to run on more platforms than many other
solutions, to the degree where your chances to compile something
under/with both Cygwin and GNU/Linux was better than under/with both
Solaris and Xenix (for example).

What recent decisions and decision finding processes lead to amounts to
throwing away the GNU system's capability of serving as a skeleton key,
a solution one uses because it will work better across different tasks,
platforms and philosophies than its competition because many people have
been able to work on it according to their own interests.

The freedom of choosing what you want your free tools to work with may
not have been philosophically anchored in the GNU project's principles,
but it has been one driving aspect of freedom that has made people
appreciate the freedom of being able to take their tools wherever they
go.  For many, it is one of the things they have become passionate
about, and it was an essential part of what GNU meant particularly when
we had no free kernel to rely on.

Excising the general usefulness of GNU _now_, and that is the trend
which recent attempts of decision-finding (whether or not they can be
considered finished) were focused with, is something that will come at a
cost that I don't see the GNU project able to carry.  In my opinion, it
would cut too close to the heart of the project and its history.

In the light of that, it is sad that we don't appear to have workable
strategies in place for making decisions about interoperability.  Any
such case where the decision-finding is opaque to people interested to
working on parts of GNU, and where it drags on for an indeterminate
amount of time, is putting enthusiasm terminally to rest that would have
better spent on improving GNU.

We cannot afford to continue without a predictable strategy towards
interoperability and easy, reliable and speedy decision-finding
processes based on such a strategy.

This is particularly important for as widely useful and portable
applications like Emacs and GCC.

-- 
David Kastrup

Re: Contributing LLVM.org patches to gud.el

[Stephen J. Turnbull]

Richard Stallman writes:

 > These are not similar cases.  Neither Windows nor MacOS was
 > intended to push major GNU packages out of use.  What I see here
 > appears possibly to be exactly that.

And so what if it is?  You need to be bigger than to play tit-for-tat
on penny vs. dollar terms.[1]  If you want to fight LLVM, you need to
offer comparable value to your users.  You need to offer them a
strategy for software freedom that can win, that's what they want.

The rule David mentioned ("don't advantage non-GNU software over GNU
software") is strategically plausible.  It's your own rule.  It's easy
to explain and to follow.  On the other hand, refusing patches to
gud.el on the basis "we're under attack" is arbitrary: software
freedom has been under attack for at least 40 years, maybe more.
Nothing important has changed.  The same strategies as ever are
appropriate here.

More-disappointed-than-usual-ly y'rs,
The Loyal Opposition


Footnotes: 
[1]  If there's somebody out there with the resources to push a major
GNU package out of use, they need a *lot* of resources just to
overcome the natural inertia of installed base.  The little you can do
to hurt them is so small even an tax accountant wouldn't notice it.

The single exception is to take a page out of your own book and offer
the world GPLed software with the same features that non-GPLed code
offers.  But you've ruled that out.

Re: Contributing LLVM.org patches to gud.el

[Stefan Monnier]

>> The LLVM source repository includes a patch adding basic lldb support
>> to gud.el.
> It looks like there is a systematic effort to attack GNU packages.
> The GNU Project needs to respond strategically, which means not by
> having each GNU package cooperate with each attack.  For now, please
> do NOT install this change.

Don't be ridiculous Richard.  This is a very barebones support, much
below what we have for GDB.  If you want to block this, then we should
remove all Mac OS X support code as well (for starters).


        Stefan

Re: Contributing LLVM.org patches to gud.el

[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. ]]]

  > Don't be ridiculous Richard.  This is a very barebones support, much
  > below what we have for GDB.

This question is a small part of a big issue which is more or less bad.
I want to find out what it is, and think about it.  Please do not ask
me to rush to a conclusion without finding out what is happening.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Contributing LLVM.org patches to gud.el

[Stefan Monnier]

> This question is a small part of a big issue which is more or less bad.
> I want to find out what it is, and think about it.  Please do not ask
> me to rush to a conclusion without finding out what is happening.

Take your time.  But whatever you find out is irrelevant to whether or
not the Emacs maintainer will accept LLVM support into gud.el, at least
as long as I'm the maintainer.


        Stefan

Re: Contributing LLVM.org patches to gud.el

[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 don't know what I will find about LLDB.  I don't know what
conclusions I will reach about it.  So I can't say anything concrete
about it now.

Installing that change would be favorable for Emacs, probably just a
little.  It would probably be bad for GDB, but I have no idea how
much.  Refusing to installing it would be a statement with some
significance, but I don't know how much.  I can't tell whether
it is good or bad to install that change.

Despite this uncertainty, I can say something general about what we
should do.  We should do what is best for the GNU system's goal of
giving the users freedom.  This means considering what is good for
Emacs and what is good for GDB, to make a decision.  Then the whole
GNU Project should do what is best.  That is the responsibility of
each GNU package maintainer.

If GNU packages do not support each other, it will be easier
for many of them to fail.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.