New function for gdb-ui.el?

New function for gdb-ui.el?

[Nick Roberts]

Is it a good idea to add the function below to gdb-ui.el now/ever?

Nick
  

(defun gdb-mouse-until (event)
  "Execute source lines by dragging the overlay arrow (fringe) with the mouse."
  (interactive "e")
  (let ((startpos (posn-point (event-start event)))
	(endline (line-number-at-pos (posn-point (event-end event)))))
    (if (equal startpos (marker-position gud-overlay-arrow-position))
	(gud-call
	 (concat "until " buffer-file-name ":" (number-to-string endline))))))

(define-key gud-minor-mode-map [left-fringe drag-mouse-1]
    'gdb-mouse-until)

Re: New function for gdb-ui.el?

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 23 Oct 2005 22:14:46 +1300
> 
> Is it a good idea to add the function below to gdb-ui.el now/ever?

FWIW, I think it's a good idea.

Perhaps it would also be a good idea to run `until' by simply clicking
in the fringe.

Re: New function for gdb-ui.el?

[Nick Roberts]

 > > Is it a good idea to add the function below to gdb-ui.el now/ever?
 > 
 > FWIW, I think it's a good idea.
 > 
 > Perhaps it would also be a good idea to run `until' by simply clicking
 > in the fringe.

At the moment gud-until is on the tool-bar (execution continues to point) but
clicking with mouse-1 in the fringe sets/clears a breakpoint.  In the display
margin, mouse-3 toggles an existing breakpoint.  I would like to do that in
the fringe too, but currently I dont think you can give bitmaps properties
in Emacs (I use text properties for the breakpoint icons in the margin).

In the implementation that I gave, I required the drag to start from the
overlay because I thought it was a potentially dangerous feature but I could
relax that I guess and just look at where the drag finishes.

Nick

Re: New function for gdb-ui.el?

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > > Is it a good idea to add the function below to gdb-ui.el now/ever?
>  > 
>  > FWIW, I think it's a good idea.
>  > 
>  > Perhaps it would also be a good idea to run `until' by simply clicking
>  > in the fringe.
>
> At the moment gud-until is on the tool-bar (execution continues to point) but
> clicking with mouse-1 in the fringe sets/clears a breakpoint.  In the display
> margin, mouse-3 toggles an existing breakpoint.  I would like to do that in
> the fringe too, but currently I dont think you can give bitmaps properties
> in Emacs (I use text properties for the breakpoint icons in the margin).

Can't you put the property on the "invisible" character that you add
to show the bitmap?

> In the implementation that I gave, I required the drag to start from the
> overlay because I thought it was a potentially dangerous feature but I could
> relax that I guess and just look at where the drag finishes.

I think it is a good design to require that you start the drag with the
current overlay arrow -- of course, you can refine it by also defining
a drag-mouse-1 event which does mouse tracking and moves the overlay arrow
as you drag the mouse...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: New function for gdb-ui.el?

[Nick Roberts]

 > > At the moment gud-until is on the tool-bar (execution continues to point)
 > > but clicking with mouse-1 in the fringe sets/clears a breakpoint.  In the
 > > display margin, mouse-3 toggles an existing breakpoint.  I would like to
 > > do that in the fringe too, but currently I dont think you can give
 > > bitmaps properties in Emacs (I use text properties for the breakpoint
 > > icons in the margin).
 > 
 > Can't you put the property on the "invisible" character that you add
 > to show the bitmap?

I don't think there is an "invisible" character in the fringe.  I discussed
this briefly with you at the start of the year (Fringe/margin issues).  
(posn-string posn) always returns nil in the fringe.

 > > In the implementation that I gave, I required the drag to start from the
 > > overlay because I thought it was a potentially dangerous feature but I
 > > could relax that I guess and just look at where the drag finishes.
 > 
 > I think it is a good design to require that you start the drag with the
 > current overlay arrow -- of course, you can refine it by also defining
 > a drag-mouse-1 event which does mouse tracking and moves the overlay arrow
 > as you drag the mouse...

It would also help if the buffer scrolled when you drag past the mode line
while in the fringe, just as it does in the text area.

Nick

Re: New function for gdb-ui.el?

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > > At the moment gud-until is on the tool-bar (execution continues to point)
>  > > but clicking with mouse-1 in the fringe sets/clears a breakpoint.  In the
>  > > display margin, mouse-3 toggles an existing breakpoint.  I would like to
>  > > do that in the fringe too, but currently I dont think you can give
>  > > bitmaps properties in Emacs (I use text properties for the breakpoint
>  > > icons in the margin).
>  > 
>  > Can't you put the property on the "invisible" character that you add
>  > to show the bitmap?
>
> I don't think there is an "invisible" character in the fringe.  I discussed
> this briefly with you at the start of the year (Fringe/margin issues).  
> (posn-string posn) always returns nil in the fringe.
>

See the patch below which uses the invisible character in the buffer...


> It would also help if the buffer scrolled when you drag past the mode line
> while in the fringe, just as it does in the text area.

Sure!  But if people agree that a mouse-2 click in the left fringe is the
way to do this, it is not necessary...


*** gdb-ui.el	24 Oct 2005 11:18:01 +0200	1.98
--- gdb-ui.el	24 Oct 2005 13:40:24 +0200	
***************
*** 350,359 ****
    (define-key gud-minor-mode-map [left-fringe mouse-1]
      'gdb-mouse-set-clear-breakpoint)
    (define-key gud-minor-mode-map [left-margin mouse-3]
!     'gdb-mouse-toggle-breakpoint)
! ;  Currently only works in margin.
! ;  (define-key gud-minor-mode-map [left-fringe mouse-3]
! ;    'gdb-mouse-toggle-breakpoint)
  
    (setq comint-input-sender 'gdb-send)
    ;;
--- 350,358 ----
    (define-key gud-minor-mode-map [left-fringe mouse-1]
      'gdb-mouse-set-clear-breakpoint)
    (define-key gud-minor-mode-map [left-margin mouse-3]
!     'gdb-mouse-toggle-breakpoint-margin)
!   (define-key gud-minor-mode-map [left-fringe mouse-3]
!     'gdb-mouse-toggle-breakpoint-fringe)
  
    (setq comint-input-sender 'gdb-send)
    ;;
***************
*** 1400,1407 ****
  		(gud-remove nil)
  	      (gud-break nil)))))))
  
! (defun gdb-mouse-toggle-breakpoint (event)
!   "Enable/disable breakpoint in left fringe/margin with mouse click."
    (interactive "e")
    (mouse-minibuffer-check event)
    (let ((posn (event-end event)))
--- 1399,1406 ----
  		(gud-remove nil)
  	      (gud-break nil)))))))
  
! (defun gdb-mouse-toggle-breakpoint-margin (event)
!   "Enable/disable breakpoint in left margin with mouse click."
    (interactive "e")
    (mouse-minibuffer-check event)
    (let ((posn (event-end event)))
***************
*** 1419,1425 ****
  				 0 'gdb-enabled (car (posn-string posn)))
  				"disable "
  			      "enable ")
! 			    bptno "\n")) 'ignore))))))))
  
  (defun gdb-breakpoints-buffer-name ()
    (with-current-buffer gud-comint-buffer
--- 1418,1450 ----
  				 0 'gdb-enabled (car (posn-string posn)))
  				"disable "
  			      "enable ")
! 			    bptno "\n"))
! 		  'ignore))))))))
! 
! (defun gdb-mouse-toggle-breakpoint-fringe (event)
!   "Enable/disable breakpoint in left fringe with mouse click."
!   (interactive "e")
!   (mouse-minibuffer-check event)
!   (let* ((posn (event-end event))
! 	 (pos (posn-point posn))
! 	 obj)
!     (when (numberp pos)
!       (with-selected-window (posn-window posn)
! 	(save-excursion
! 	  (set-buffer (window-buffer (selected-window)))
! 	  (goto-char pos)
! 	  (dolist (overlay (overlays-in pos pos))
! 	    (when (overlay-get overlay 'put-break)
! 	      (setq obj (overlay-get overlay 'before-string))))
! 	  (when (stringp obj)
! 	    (gdb-enqueue-input
! 	     (list
! 	      (concat
! 	       (if (get-text-property 0 'gdb-enabled obj)
! 		   "disable "
! 		 "enable ")
! 	       (get-text-property 0 'gdb-bptno obj) "\n")
! 	      'ignore))))))))
  
  (defun gdb-breakpoints-buffer-name ()
    (with-current-buffer gud-comint-buffer
***************
*** 2456,2462 ****
  	(error (setq gdb-find-file-unhook t)))))
  
  ;;from put-image
! (defun gdb-put-string (putstring pos &optional dprop)
    "Put string PUTSTRING in front of POS in the current buffer.
  PUTSTRING is displayed by putting an overlay into the current buffer with a
  `before-string' string that has a `display' property whose value is
--- 2481,2487 ----
  	(error (setq gdb-find-file-unhook t)))))
  
  ;;from put-image
! (defun gdb-put-string (putstring pos &optional dprop &rest sprops)
    "Put string PUTSTRING in front of POS in the current buffer.
  PUTSTRING is displayed by putting an overlay into the current buffer with a
  `before-string' string that has a `display' property whose value is
***************
*** 2467,2473 ****
      (let ((overlay (make-overlay pos pos buffer))
  	  (prop (or dprop
  		    (list (list 'margin 'left-margin) putstring))))
!       (put-text-property 0 (length string) 'display prop string)
        (overlay-put overlay 'put-break t)
        (overlay-put overlay 'before-string string))))
  
--- 2492,2500 ----
      (let ((overlay (make-overlay pos pos buffer))
  	  (prop (or dprop
  		    (list (list 'margin 'left-margin) putstring))))
!       (put-text-property 0 1 'display prop string)
!       (if sprops
! 	  (add-text-properties 0 1 sprops string))
        (overlay-put overlay 'put-break t)
        (overlay-put overlay 'before-string string))))
  
***************
*** 2490,2510 ****
      (add-text-properties
       0 1 '(help-echo "mouse-1: set/clear bkpt, mouse-3: enable/disable bkpt")
       putstring)
!     (if enabled (add-text-properties
! 		 0 1 `(gdb-bptno ,bptno gdb-enabled t) putstring)
        (add-text-properties
         0 1 `(gdb-bptno ,bptno gdb-enabled nil) putstring))
      (gdb-remove-breakpoint-icons start end)
      (if (display-images-p)
  	(if (>= (or left-fringe-width
! 		   (if source-window (car (window-fringes source-window)))
! 		   gdb-buffer-fringe-width) 8)
  	    (gdb-put-string
  	     nil (1+ start)
  	     `(left-fringe breakpoint
  			   ,(if enabled
  				'breakpoint-enabled
! 			      'breakpoint-disabled)))
  	  (when (< left-margin-width 2)
  	    (save-current-buffer
  	      (setq left-margin-width 2)
--- 2517,2540 ----
      (add-text-properties
       0 1 '(help-echo "mouse-1: set/clear bkpt, mouse-3: enable/disable bkpt")
       putstring)
!     (if enabled
! 	(add-text-properties
! 	 0 1 `(gdb-bptno ,bptno gdb-enabled t) putstring)
        (add-text-properties
         0 1 `(gdb-bptno ,bptno gdb-enabled nil) putstring))
      (gdb-remove-breakpoint-icons start end)
      (if (display-images-p)
  	(if (>= (or left-fringe-width
! 		    (if source-window (car (window-fringes source-window)))
! 		    gdb-buffer-fringe-width) 8)
  	    (gdb-put-string
  	     nil (1+ start)
  	     `(left-fringe breakpoint
  			   ,(if enabled
  				'breakpoint-enabled
! 			      'breakpoint-disabled))
! 	     'gdb-bptno bptno
! 	     'gdb-enabled enabled)
  	  (when (< left-margin-width 2)
  	    (save-current-buffer
  	      (setq left-margin-width 2)



-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: New function for gdb-ui.el?

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

>> I don't think there is an "invisible" character in the fringe.  I discussed
>> this briefly with you at the start of the year (Fringe/margin issues).  
>> (posn-string posn) always returns nil in the fringe.
>
> See the patch below which uses the invisible character in the buffer...

I installed my patch, so now mouse-3 on a fringe breakpoint bitmap
enables/disables the breakpoint...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: New function for gdb-ui.el?

[Nick Roberts]

 > >> I don't think there is an "invisible" character in the fringe.  I
 > >> discussed this briefly with you at the start of the year (Fringe/margin
 > >> issues).  (posn-string posn) always returns nil in the fringe.
 > >
 > > See the patch below which uses the invisible character in the buffer...
 > 
 > I installed my patch, so now mouse-3 on a fringe breakpoint bitmap
 > enables/disables the breakpoint...

Thanks.  I wasn't ignoring it, but trying to understand it.  It certainly
works!

Nick

Re: New function for gdb-ui.el?

[Nick Roberts]

 > I installed my patch, so now mouse-3 on a fringe breakpoint bitmap
 > enables/disables the breakpoint...

I tried to follow this to add a help-echo (and a hand pointer) to the icon in
the fringe (to copy whats already implemented for the margin).  This change in
gdb-put-string didn't work for the help-echo:

(if sprops
    (add-text-properties
     0 1
     (append
      '(help-echo "mouse-1: clear bkpt, mouse-3: enable/disable bkpt")
      sprops) string))

Is it possible?

Nick

Re: New function for gdb-ui.el?

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > I installed my patch, so now mouse-3 on a fringe breakpoint bitmap
>  > enables/disables the breakpoint...
>
> I tried to follow this to add a help-echo (and a hand pointer) to the icon in
> the fringe (to copy whats already implemented for the margin).  This change in
> gdb-put-string didn't work for the help-echo:
>
> (if sprops
>     (add-text-properties
>      0 1
>      (append
>       '(help-echo "mouse-1: clear bkpt, mouse-3: enable/disable bkpt")
>       sprops) string))
>
> Is it possible?

Currently, no.

Problem is that the redisplay engine does not check whether mouse is
over a fringe bitmap, and consequently, it does not try to find the
origin of that bitmap (the overlay string), so it doesn't know where
to find the help-echo string either.  It would be a good thing to
fix this, but it is not trivial.

In any case, I would put the help-echo property into the arglist to the
place where you call gdb-put-string so you avoid the append here.

Like this:
	    (gdb-put-string
             ...
	     'gdb-bptno bptno
	     'gdb-enabled enabled
             'help-echo "...")

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: New function for gdb-ui.el?

[Frank Schmitt]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Nick Roberts <nickrob@snap.net.nz>
>> Date: Sun, 23 Oct 2005 22:14:46 +1300
>> 
>> Is it a good idea to add the function below to gdb-ui.el now/ever?
>
> FWIW, I think it's a good idea.
>
> Perhaps it would also be a good idea to run `until' by simply clicking
> in the fringe.

Yes, I would like this.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: New function for gdb-ui.el?

[Nick Roberts]

 > > Perhaps it would also be a good idea to run `until' by simply clicking
 > > in the fringe.
 > 
 > Yes, I would like this.

It could go on mouse-2 which has some kind of goto idiom.  Do you think it
should it be restricted to the buffer with the overlay arrow or work on any
file which is part of the source code of the GDB session.

Nick

Re: New function for gdb-ui.el?

[Frank Schmitt]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > > Perhaps it would also be a good idea to run `until' by simply clicking
>  > > in the fringe.
>  > 
>  > Yes, I would like this.
>
> It could go on mouse-2 which has some kind of goto idiom.  Do you think it
> should it be restricted to the buffer with the overlay arrow or work on any
> file which is part of the source code of the GDB session.

I'd restrict it to the former.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: New function for gdb-ui.el?

[Richard M. Stallman]

    > It could go on mouse-2 which has some kind of goto idiom.  Do you think it
    > should it be restricted to the buffer with the overlay arrow or work on any
    > file which is part of the source code of the GDB session.

    I'd restrict it to the former.

To move to another file usually means moving to another frame, and
that's not the job of `until'.   This command should refuse
to move to another frame.

But there is an exception: when a function in one file is inlined in
another.  In that case, shouldn't this command work?

Re: New function for gdb-ui.el?

[Nick Roberts]

 >     > It could go on mouse-2 which has some kind of goto idiom.  Do you
 >     > think it should it be restricted to the buffer with the overlay arrow
 >     > or work on any file which is part of the source code of the GDB
 >     > session.
 > 
 >     I'd restrict it to the former.
 > 
 > To move to another file usually means moving to another frame, and
 > that's not the job of `until'.   This command should refuse
 > to move to another frame.

Yes, you're right.  I hadn't tried it and just used the fact that it takes
the same kind of argument as break.

 > But there is an exception: when a function in one file is inlined in
 > another.  In that case, shouldn't this command work?

If I try it, it doesn't seem to work.  Even if it, I'm not sure how we would
make use of it.

Nick

Re: New function for gdb-ui.el?

[Richard M. Stallman]

     > To move to another file usually means moving to another frame, and
     > that's not the job of `until'.   This command should refuse
     > to move to another frame.

    Yes, you're right.

Actually, now I am not sure what I said is true.  Maybe `until' just
sets a temporary breakpoint and continues.  If so, it would actually
"work" even if you specify a line in a different function.

     > But there is an exception: when a function in one file is inlined in
     > another.  In that case, shouldn't this command work?

    If I try it, it doesn't seem to work.  Even if it, I'm not sure how we would
    make use of it.

If it doesn't work, maybe that is a flaw in GDB.  It OUGHT to be
possible to proceed to a specific line in the code another function
that was inlined into this function.

Would you like to raise that is with bug-gdb and cc me?

Re: New function for gdb-ui.el?

[Nick Roberts]

 >      > To move to another file usually means moving to another frame, and
 >      > that's not the job of `until'.   This command should refuse
 >      > to move to another frame.
 > 
 >     Yes, you're right.
 > 
 > Actually, now I am not sure what I said is true.  Maybe `until' just
 > sets a temporary breakpoint and continues.  If so, it would actually
 > "work" even if you specify a line in a different function.

The manual says:

GDB> Continue running your program until either the specified location
GDB> is reached, or the current stack frame returns.

(actually, it should say *selected* stack frame returns)

As Eli says, there is now another command called "advance".  I think this has
the behaviour you are talking about:

GDB> ...the target location doesn't have to be in the same frame as the
GDB> current one.

 >      > But there is an exception: when a function in one file is inlined in
 >      > another.  In that case, shouldn't this command work?
 > 
 >     If I try it, it doesn't seem to work.  Even if it, I'm not sure how we
 >     would make use of it.
 > 
 > If it doesn't work, maybe that is a flaw in GDB.  It OUGHT to be
 > possible to proceed to a specific line in the code another function
 > that was inlined into this function.
 > 
 > Would you like to raise that is with bug-gdb and cc me?

The problem is that the documentation just talks about being able to skip over
recursive functions and doesn't mention inline functions.  So I'm not sure
that they would see it as a bug.

Nick

Re: New function for gdb-ui.el?

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Wed, 26 Oct 2005 12:00:51 +1300
> Cc: ich@frank-schmitt.net, emacs-devel@gnu.org
> 
>  > Actually, now I am not sure what I said is true.  Maybe `until' just
>  > sets a temporary breakpoint and continues.  If so, it would actually
>  > "work" even if you specify a line in a different function.
> 
> The manual says:
> 
> GDB> Continue running your program until either the specified location
> GDB> is reached, or the current stack frame returns.
> 
> (actually, it should say *selected* stack frame returns)

I don't think ``selected'' is more accurate or more clear in this
context than ``current''.

The latest version of the manual has this clarification:

  The specified location is actually reached only if it is in the
  current frame.

>  >      > But there is an exception: when a function in one file is inlined in
>  >      > another.  In that case, shouldn't this command work?
>  > 
>  >     If I try it, it doesn't seem to work.  Even if it, I'm not sure how we
>  >     would make use of it.
>  > 
>  > If it doesn't work, maybe that is a flaw in GDB.  It OUGHT to be
>  > possible to proceed to a specific line in the code another function
>  > that was inlined into this function.
>  > 
>  > Would you like to raise that is with bug-gdb and cc me?
> 
> The problem is that the documentation just talks about being able to skip over
> recursive functions and doesn't mention inline functions.  So I'm not sure
> that they would see it as a bug.

I'd suggest to craft a simple test case with inlined function and ask
the question on the GDB mailing list.  I'd expect `until' to stop in
an inlined function; the fact that the manual doesn't say anything
about this might just be a documentation bug.

Re: New function for gdb-ui.el?

[Nick Roberts]

 > > The manual says:
 > > 
 > > GDB> Continue running your program until either the specified location
 > > GDB> is reached, or the current stack frame returns.
 > > 
 > > (actually, it should say *selected* stack frame returns)
 > 
 > I don't think ``selected'' is more accurate or more clear in this
 > context than ``current''.

My understanding is that "current frame" refers to the innermost frame where
execution has stopped.  The "selected frame" refers to the frame that GDB is
looking at and can be changed with the "up" and "down" commands.  If I stop
in a frame, I can use "up" to go up a frame and then "until" to advance along
that "selected frame" even though execution had stopped in the frame below.

Unfortunately "current frame" has some ambiguity and the GDB manual seems to
mix its meaning.

 > The latest version of the manual has this clarification:
 > 
 >   The specified location is actually reached only if it is in the
 >   current frame.

I think it should say:

     The specified location is actually reached only if it is in the
     same frame.

 > >  >      > But there is an exception: when a function in one file is
 > >  >      > inlined in another.  In that case, shouldn't this command work?
 > >  > 
 > >  >     If I try it, it doesn't seem to work.  Even if it, I'm not sure how we
 > >  >     would make use of it.
 > >  > 
 > >  > If it doesn't work, maybe that is a flaw in GDB.  It OUGHT to be
 > >  > possible to proceed to a specific line in the code another function
 > >  > that was inlined into this function.
 > >  > 
 > >  > Would you like to raise that is with bug-gdb and cc me?
 > > 
 > > The problem is that the documentation just talks about being able to skip
 > > over recursive functions and doesn't mention inline functions.  So I'm
 > > not sure that they would see it as a bug.
 > 
 > I'd suggest to craft a simple test case with inlined function and ask
 > the question on the GDB mailing list.  I'd expect `until' to stop in
 > an inlined function; the fact that the manual doesn't say anything
 > about this might just be a documentation bug.

I don't think I understand the issues.  I thought if I used the keyword inline
e.g "inline int mysquare (int x)", I would get an inline function.  Perhaps
thats not the case because I can set a breakpoint, stop there and see mysquare
in the stack.

If I use -O2 or -O3 (gcc 3.4.4) then I can't stop there (because its inlined?).
So how can "until" possibly proceed to there?

Nick

gcc and inline [was: Re: New function for gdb-ui.el?]

[Tomas Zerolo]

[-- Attachment #1.1: Type: text/plain, Size: 648 bytes --]

On Wed, Oct 26, 2005 at 09:58:41PM +1300, Nick Roberts wrote:

[...]

> I don't think I understand the issues.  I thought if I used the keyword inline
> e.g "inline int mysquare (int x)", I would get an inline function.  Perhaps
> thats not the case because I can set a breakpoint, stop there and see mysquare
> in the stack.

No, it's just a hint to the compiler. It may think it knows better than
you. You may ask the compiler to warn you when it ignores the hint (with
-Winline).

If you want to *force* inline, you may try a monstrosity like
__inline__ __attribute__((always_inline)) (if I remember correctly).

HTH
-- tomás

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: gcc and inline [was: Re: New function for gdb-ui.el?]

[Eli Zaretskii]

> Date: Wed, 26 Oct 2005 17:02:59 +0200
> From: tomas@tuxteam.de (Tomas Zerolo)
> Cc: ich@frank-schmitt.net, Eli Zaretskii <eliz@gnu.org>, rms@gnu.org,
> 	emacs-devel@gnu.org
> 
> No, it's just a hint to the compiler.

Yes, but GCC is generally known for honoring that hint.

Re: gcc and inline [was: Re: New function for gdb-ui.el?]

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 26 Oct 2005 17:02:59 +0200
>> From: tomas@tuxteam.de (Tomas Zerolo)
>> Cc: ich@frank-schmitt.net, Eli Zaretskii <eliz@gnu.org>, rms@gnu.org,
>> 	emacs-devel@gnu.org
>> 
>> No, it's just a hint to the compiler.
>
> Yes, but GCC is generally known for honoring that hint.

Only if it thinks it is worthwhile, and the thresholds have changed over
time.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc and inline [was: Re: New function for gdb-ui.el?]

[Tomas Zerolo]

[-- Attachment #1.1: Type: text/plain, Size: 915 bytes --]

On Wed, Oct 26, 2005 at 09:32:39PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 26 Oct 2005 17:02:59 +0200
> > From: tomas@tuxteam.de (Tomas Zerolo)
> > Cc: ich@frank-schmitt.net, Eli Zaretskii <eliz@gnu.org>, rms@gnu.org,
> > 	emacs-devel@gnu.org
> > 
> > No, it's just a hint to the compiler.
> 
> Yes, but GCC is generally known for honoring that hint.

As Andreas said, GCC seems to be getting lazier lately. (Actually, my
knowledge bits were based on a recent experience. -Winline told me, to
my surprise, that some short function wasn't being inlined. But (after
digging and finding this __inline__ __attribute__ thing) forcing the
compiler to do it confirmed the compiler's guess: it wasn't worth the
while (the whole thing was faster by about 1 percent, which I consider
to be noise).

This behaviour was consistent across several gcc versions (2.95 through
3.some).

Regards
-- tomás

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: gcc and inline [was: Re: New function for gdb-ui.el?]

[Eli Zaretskii]

> Date: Thu, 27 Oct 2005 06:22:43 +0200
> From: tomas@tuxteam.de (Tomas Zerolo)
> Cc: nickrob@snap.net.nz, Tomas Zerolo <tomas@tuxteam.de>, ich@frank-schmitt.net,
> 	emacs-devel@gnu.org
> 
> > > No, it's just a hint to the compiler.
> > 
> > Yes, but GCC is generally known for honoring that hint.
> 
> As Andreas said, GCC seems to be getting lazier lately. (Actually, my
> knowledge bits were based on a recent experience. -Winline told me, to
> my surprise, that some short function wasn't being inlined. But (after
> digging and finding this __inline__ __attribute__ thing) forcing the
> compiler to do it confirmed the compiler's guess: it wasn't worth the
> while (the whole thing was faster by about 1 percent, which I consider
> to be noise).

All I can say is that my experience with GCC, including the latest
versions, is very different.

Re: gcc and inline [was: Re: New function for gdb-ui.el?]

[Richard M. Stallman]

If you think that GCC is making bad decisions about what to inline,
please send specific bug reports to bug-gcc@gnu.org.

Re: gcc and inline [was: Re: New function for gdb-ui.el?]

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: tomas@tuxteam.de, nickrob@snap.net.nz, tomas@tuxteam.de,
> 	ich@frank-schmitt.net, emacs-devel@gnu.org
> Date: Thu, 27 Oct 2005 23:47:12 -0400
> 
> If you think that GCC is making bad decisions about what to inline,
> please send specific bug reports to bug-gcc@gnu.org.

The behavior I'm familiar with does not constitute a bug, IMO.  In my
experience, GCC follows the inline hints very closely, and that's what
I'd expect.

Re: gcc and inline [was: Re: New function for gdb-ui.el?]

[Tomas Zerolo]

[-- Attachment #1.1: Type: text/plain, Size: 732 bytes --]

On Fri, Oct 28, 2005 at 10:29:13AM +0200, Eli Zaretskii wrote:
[...]
> > If you think that GCC is making bad decisions about what to inline,
> > please send specific bug reports to bug-gcc@gnu.org.
> 
> The behavior I'm familiar with does not constitute a bug, IMO.  In my
> experience, GCC follows the inline hints very closely, and that's what
> I'd expect.

And my point was that it sometimes doesn't inline where I'd expect it
to -- but its decisions in those cases seem to be better than my
guesses, as far as I have checked. So to me it isn't a bug either
(although my observations seem to differ from those made by Eli ;-)

I'd be willing to make available an example -- if anyone cares.

Regards
-- tomás

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: gcc and inline [was: Re: New function for gdb-ui.el?]

[Miles Bader]

2005/10/28, Tomas Zerolo <tomas@tuxteam.de>:
> And my point was that it sometimes doesn't inline where I'd expect it
> to -- but its decisions in those cases seem to be better than my
> guesses, as far as I have checked. So to me it isn't a bug either

I wouldn't worry about it either, unless something in emacs actually
breaks ... gcc's inlining behavior does change from time to time, but
the maintainers are well aware of the issues, and they've got _much_
more picky users of inline constantly breathing down their necks (like
kernel hackers).

-miles
--
Do not taunt Happy Fun Ball.

Re: New function for gdb-ui.el?

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Wed, 26 Oct 2005 21:58:41 +1300
> Cc: rms@gnu.org, ich@frank-schmitt.net, emacs-devel@gnu.org
> 
>  > > The manual says:
>  > > 
>  > > GDB> Continue running your program until either the specified location
>  > > GDB> is reached, or the current stack frame returns.
>  > > 
>  > > (actually, it should say *selected* stack frame returns)
>  > 
>  > I don't think ``selected'' is more accurate or more clear in this
>  > context than ``current''.
> 
> My understanding is that "current frame" refers to the innermost frame where
> execution has stopped.  The "selected frame" refers to the frame that GDB is
> looking at and can be changed with the "up" and "down" commands.  If I stop
> in a frame, I can use "up" to go up a frame and then "until" to advance along
> that "selected frame" even though execution had stopped in the frame below.
> 
> Unfortunately "current frame" has some ambiguity and the GDB manual seems to
> mix its meaning.
> 
>  > The latest version of the manual has this clarification:
>  > 
>  >   The specified location is actually reached only if it is in the
>  >   current frame.
> 
> I think it should say:
> 
>      The specified location is actually reached only if it is in the
>      same frame.

Thanks for pointing this out, I will try to make the terminology in
the GDB manual more clear and consistent.

>  > I'd suggest to craft a simple test case with inlined function and ask
>  > the question on the GDB mailing list.  I'd expect `until' to stop in
>  > an inlined function; the fact that the manual doesn't say anything
>  > about this might just be a documentation bug.
> 
> I don't think I understand the issues.  I thought if I used the keyword inline
> e.g "inline int mysquare (int x)", I would get an inline function.  Perhaps
> thats not the case because I can set a breakpoint, stop there and see mysquare
> in the stack.
> 
> If I use -O2 or -O3 (gcc 3.4.4) then I can't stop there (because its inlined?).
> So how can "until" possibly proceed to there?

Not enough details to answer (and I think we should continue this on
gdb@sources.redhat.com, anyway).  You didn't say on what platform you
tested this, and you didn't show the test program nor the GCC command
used to compile it.  (The debug info format used by the compiler is of
interest.)

In general, I think GDB should be able to stop inside inlined code,
given enough information from the compiler.  So if it doesn't, it's a
bug of some kind.

Re: New function for gdb-ui.el?

[Richard M. Stallman]

    I don't think I understand the issues.  I thought if I used the keyword inline
    e.g "inline int mysquare (int x)", I would get an inline function.  Perhaps
    thats not the case because I can set a breakpoint, stop there and see mysquare
    in the stack.

If you can do that, then it wasn't inlined.  At least, that call to
mysquare was not inlined.  (I don't remember any more whether GCC can
decide to inline some calls to a function and not inline other calls.)

    If I use -O2 or -O3 (gcc 3.4.4) then I can't stop there (because its inlined?).

Probably so.

Note that inlining can occur even with -O0.  I always compile Emacs
with -O0 -fno-inline to make sure nothing will be inlined.

    So how can "until" possibly proceed to there?

You may think think there's no there, there, but there is.  There is
code in the calling function that corresponds to mysquare.  GDB knows
where it is, as you'll see if you step thru that calling function.
(This may be easier to see if the inlined function contains several
function calls to unknown functions instead of just arithmetic.)

If you are in a function foo and you ask to go until a line in mysquare,
GDB should see if foo has any code that identifies itself as coming
from that line in mysquare, and it should put the temp breakpoint there.

If foo contains two inlined calls to mysquare, GDB should put a
temp breakpoint in each of them, so that the program will stop at
whichever one it reaches.

Re: New function for gdb-ui.el?

[David Hansen]

On Wed, 26 Oct 2005 21:58:41 +1300 Nick Roberts wrote:

> I don't think I understand the issues.  I thought if I used the
> keyword inline e.g "inline int mysquare (int x)", I would get
> an inline function.  Perhaps thats not the case because I can
> set a breakpoint, stop there and see mysquare in the stack.

Just curious:  How can gcc inline a non static function?

David

Re: New function for gdb-ui.el?

[Miles Bader]

David Hansen <david.hansen@gmx.net> writes:
> Just curious:  How can gcc inline a non static function?

The same way it inlines a static function....

[but it can't elide the non-inlined instance of the function, as it can
when the function is static.]

-miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: New function for gdb-ui.el?

[Nick Roberts]

 > > I don't think I understand the issues.  I thought if I used the
 > > keyword inline e.g "inline int mysquare (int x)", I would get
 > > an inline function.  Perhaps thats not the case because I can
 > > set a breakpoint, stop there and see mysquare in the stack.
 > 
 > Just curious:  How can gcc inline a non static function?

I guess it takes the machine code for mysquare and copies it into the
machine code of the executable at locations where it is called.

What problems can you see?

Nick

Re: New function for gdb-ui.el?

[David Hansen]

On Sat, 29 Oct 2005 10:14:54 +1300 Nick Roberts wrote:

>  > > I don't think I understand the issues.  I thought if I used the
>  > > keyword inline e.g "inline int mysquare (int x)", I would get
>  > > an inline function.  Perhaps thats not the case because I can
>  > > set a breakpoint, stop there and see mysquare in the stack.
>  > 
>  > Just curious:  How can gcc inline a non static function?
>
> I guess it takes the machine code for mysquare and copies it into the
> machine code of the executable at locations where it is called.
>
> What problems can you see?

A confused linker...

David 

Re: New function for gdb-ui.el?

[Nick Roberts]

 > >  > Just curious:  How can gcc inline a non static function?
 > >
 > > I guess it takes the machine code for mysquare and copies it into the
 > > machine code of the executable at locations where it is called.
 > >
 > > What problems can you see?
 > 
 > A confused linker...

I don't know what you're talking about and your cryptic posts don't help.

Nick

Re: New function for gdb-ui.el?

[Miles Bader]

2005/10/30, Nick Roberts <nickrob@snap.net.nz>:
>  > A confused linker...
>
> I don't know what you're talking about and your cryptic posts don't help.

He was just pointing out (cryptically) that the compiler doesn't do
inlining by copying machine code, and that doing so wouldn't work very
well... (though I sort of assumed you weren't being literal when you
said that)

[It "copies" the compiler's internal representation for the inlined
function at some point during compilation (exactly what and where
varies even between gcc releases), and then continues with
optimization, etc. -- a _very_ important attribute of inlined
functions is that the inlined function's code is optimized in the
context of the call-site.]

-miles
--
Do not taunt Happy Fun Ball.

Re: New function for gdb-ui.el?

[Nick Roberts]

Miles Bader writes:
 > 2005/10/30, Nick Roberts <nickrob@snap.net.nz>:
 > >  > A confused linker...
 > >
 > > I don't know what you're talking about and your cryptic posts don't help.
 > 
 > He was just pointing out (cryptically) that the compiler doesn't do
 > inlining by copying machine code, and that doing so wouldn't work very
 > well... (though I sort of assumed you weren't being literal when you
 > said that)

He seemed to be saying that the function needs to be static but that
does not seem to be the case; rather calls need to be made in the same file
that the function is defined, to be inlined.

Reading the gcc manual, it says that no inlining, even when specified with the
inline keyword in the code, takes place without optimisation. This was
contrary to my expection.

In the manual, I have stated that the command that I have defined
(gdb-mouse-until) only works within the same frame.  If that is not the case,
and someone can correct me in plain English, I will gladly change this.

Nick

Re: New function for gdb-ui.el?

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> Date: Tue, 25 Oct 2005 16:27:06 -0400
> Cc: ich@frank-schmitt.net, emacs-devel@gnu.org
> 
>      > To move to another file usually means moving to another frame, and
>      > that's not the job of `until'.   This command should refuse
>      > to move to another frame.
> 
>     Yes, you're right.
> 
> Actually, now I am not sure what I said is true.  Maybe `until' just
> sets a temporary breakpoint and continues.  If so, it would actually
> "work" even if you specify a line in a different function.

If you give `until' an argument, it does set a temporary breakpoint,
but when it breaks, GDB checks that it is in the same frame as where
the `until' command was given, and if it isn't, it doesn't stop the
program.

Re: New function for gdb-ui.el?

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> Date: Mon, 24 Oct 2005 12:27:41 -0400
> Cc: emacs-devel@gnu.org
> 
>     > It could go on mouse-2 which has some kind of goto idiom.  Do you think it
>     > should it be restricted to the buffer with the overlay arrow or work on any
>     > file which is part of the source code of the GDB session.
> 
>     I'd restrict it to the former.
> 
> To move to another file usually means moving to another frame, and
> that's not the job of `until'.   This command should refuse
> to move to another frame.

If by ``this command'' you mean the gdb-ui.el command (as opposed to
the GDB command invoked by gdb-ui.el), then I disagree, for the
reasons explained below.

> But there is an exception: when a function in one file is inlined in
> another.

That's not the only exception; there's also the case of another file
being #include'd in the current frame's source file.  And then there's
the case of a macro defined on another file.  And what about code that
jmp's to another function without building a new stack frame?

In general, I don't think it's gdb-ui's job to enforce such
restrictions on the user, even if these situations are rare.  GDB
already deals with them, so gdb-ui shouldn't bother, since it will
never know enough to DTRT.

Also note that latest versions of GDB have the `advance' command,
which works like `until', but does stop in frames that are inner to
the one where the `advance' command was invoked.  Thus, if the other
source file's function is called by the code in the current frame,
`advance' _will_ stop there.

Re: New function for gdb-ui.el?

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

> Is it a good idea to add the function below to gdb-ui.el now/ever?


If it works, it's a brilliant idea IMO.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk