* New function for gdb-ui.el? @ 2005-10-23 9:14 Nick Roberts 2005-10-23 11:56 ` Eli Zaretskii 2005-10-23 21:26 ` Kim F. Storm 0 siblings, 2 replies; 40+ messages in thread From: Nick Roberts @ 2005-10-23 9:14 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-23 9:14 New function for gdb-ui.el? Nick Roberts @ 2005-10-23 11:56 ` Eli Zaretskii 2005-10-23 20:25 ` Nick Roberts 2005-10-23 20:43 ` Frank Schmitt 2005-10-23 21:26 ` Kim F. Storm 1 sibling, 2 replies; 40+ messages in thread From: Eli Zaretskii @ 2005-10-23 11:56 UTC (permalink / raw) Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-23 11:56 ` Eli Zaretskii @ 2005-10-23 20:25 ` Nick Roberts 2005-10-23 21:53 ` Kim F. Storm 2005-10-23 20:43 ` Frank Schmitt 1 sibling, 1 reply; 40+ messages in thread From: Nick Roberts @ 2005-10-23 20:25 UTC (permalink / raw) Cc: emacs-devel > > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-23 20:25 ` Nick Roberts @ 2005-10-23 21:53 ` Kim F. Storm 2005-10-24 6:33 ` Nick Roberts 0 siblings, 1 reply; 40+ messages in thread From: Kim F. Storm @ 2005-10-23 21:53 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-23 21:53 ` Kim F. Storm @ 2005-10-24 6:33 ` Nick Roberts 2005-10-24 11:46 ` Kim F. Storm 0 siblings, 1 reply; 40+ messages in thread From: Nick Roberts @ 2005-10-24 6:33 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel > > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-24 6:33 ` Nick Roberts @ 2005-10-24 11:46 ` Kim F. Storm 2005-10-24 22:07 ` Kim F. Storm 0 siblings, 1 reply; 40+ messages in thread From: Kim F. Storm @ 2005-10-24 11:46 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-24 11:46 ` Kim F. Storm @ 2005-10-24 22:07 ` Kim F. Storm 2005-10-24 22:29 ` Nick Roberts 2005-10-25 1:27 ` Nick Roberts 0 siblings, 2 replies; 40+ messages in thread From: Kim F. Storm @ 2005-10-24 22:07 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-24 22:07 ` Kim F. Storm @ 2005-10-24 22:29 ` Nick Roberts 2005-10-25 1:27 ` Nick Roberts 1 sibling, 0 replies; 40+ messages in thread From: Nick Roberts @ 2005-10-24 22:29 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel > >> 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-24 22:07 ` Kim F. Storm 2005-10-24 22:29 ` Nick Roberts @ 2005-10-25 1:27 ` Nick Roberts 2005-10-25 9:12 ` Kim F. Storm 1 sibling, 1 reply; 40+ messages in thread From: Nick Roberts @ 2005-10-25 1:27 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-25 1:27 ` Nick Roberts @ 2005-10-25 9:12 ` Kim F. Storm 0 siblings, 0 replies; 40+ messages in thread From: Kim F. Storm @ 2005-10-25 9:12 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-23 11:56 ` Eli Zaretskii 2005-10-23 20:25 ` Nick Roberts @ 2005-10-23 20:43 ` Frank Schmitt 2005-10-24 6:57 ` Nick Roberts 1 sibling, 1 reply; 40+ messages in thread From: Frank Schmitt @ 2005-10-23 20:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-23 20:43 ` Frank Schmitt @ 2005-10-24 6:57 ` Nick Roberts 2005-10-24 7:35 ` Frank Schmitt 0 siblings, 1 reply; 40+ messages in thread From: Nick Roberts @ 2005-10-24 6:57 UTC (permalink / raw) Cc: emacs-devel > > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-24 6:57 ` Nick Roberts @ 2005-10-24 7:35 ` Frank Schmitt 2005-10-24 16:27 ` Richard M. Stallman 0 siblings, 1 reply; 40+ messages in thread From: Frank Schmitt @ 2005-10-24 7:35 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-24 7:35 ` Frank Schmitt @ 2005-10-24 16:27 ` Richard M. Stallman 2005-10-24 20:26 ` Nick Roberts 2005-10-25 8:14 ` Eli Zaretskii 0 siblings, 2 replies; 40+ messages in thread From: Richard M. Stallman @ 2005-10-24 16:27 UTC (permalink / raw) Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-24 16:27 ` Richard M. Stallman @ 2005-10-24 20:26 ` Nick Roberts 2005-10-25 20:27 ` Richard M. Stallman 2005-10-25 8:14 ` Eli Zaretskii 1 sibling, 1 reply; 40+ messages in thread From: Nick Roberts @ 2005-10-24 20:26 UTC (permalink / raw) Cc: Frank Schmitt, emacs-devel > > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-24 20:26 ` Nick Roberts @ 2005-10-25 20:27 ` Richard M. Stallman 2005-10-25 23:00 ` Nick Roberts 2005-10-26 6:43 ` Eli Zaretskii 0 siblings, 2 replies; 40+ messages in thread From: Richard M. Stallman @ 2005-10-25 20:27 UTC (permalink / raw) Cc: ich, emacs-devel > 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? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-25 20:27 ` Richard M. Stallman @ 2005-10-25 23:00 ` Nick Roberts 2005-10-26 6:49 ` Eli Zaretskii 2005-10-26 6:43 ` Eli Zaretskii 1 sibling, 1 reply; 40+ messages in thread From: Nick Roberts @ 2005-10-25 23:00 UTC (permalink / raw) Cc: ich, emacs-devel > > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-25 23:00 ` Nick Roberts @ 2005-10-26 6:49 ` Eli Zaretskii 2005-10-26 8:58 ` Nick Roberts 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2005-10-26 6:49 UTC (permalink / raw) Cc: emacs-devel, rms, ich > 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-26 6:49 ` Eli Zaretskii @ 2005-10-26 8:58 ` Nick Roberts 2005-10-26 15:02 ` gcc and inline [was: Re: New function for gdb-ui.el?] Tomas Zerolo ` (3 more replies) 0 siblings, 4 replies; 40+ messages in thread From: Nick Roberts @ 2005-10-26 8:58 UTC (permalink / raw) Cc: emacs-devel, rms, ich > > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* gcc and inline [was: Re: New function for gdb-ui.el?] 2005-10-26 8:58 ` Nick Roberts @ 2005-10-26 15:02 ` Tomas Zerolo 2005-10-26 19:32 ` Eli Zaretskii 2005-10-26 19:31 ` New function for gdb-ui.el? Eli Zaretskii ` (2 subsequent siblings) 3 siblings, 1 reply; 40+ messages in thread From: Tomas Zerolo @ 2005-10-26 15:02 UTC (permalink / raw) Cc: ich, Eli Zaretskii, rms, emacs-devel [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: gcc and inline [was: Re: New function for gdb-ui.el?] 2005-10-26 15:02 ` gcc and inline [was: Re: New function for gdb-ui.el?] Tomas Zerolo @ 2005-10-26 19:32 ` Eli Zaretskii 2005-10-26 20:20 ` Andreas Schwab 2005-10-27 4:22 ` Tomas Zerolo 0 siblings, 2 replies; 40+ messages in thread From: Eli Zaretskii @ 2005-10-26 19:32 UTC (permalink / raw) Cc: nickrob, ich, emacs-devel > 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: gcc and inline [was: Re: New function for gdb-ui.el?] 2005-10-26 19:32 ` Eli Zaretskii @ 2005-10-26 20:20 ` Andreas Schwab 2005-10-27 4:22 ` Tomas Zerolo 1 sibling, 0 replies; 40+ messages in thread From: Andreas Schwab @ 2005-10-26 20:20 UTC (permalink / raw) Cc: nickrob, Tomas Zerolo, ich, emacs-devel 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." ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: gcc and inline [was: Re: New function for gdb-ui.el?] 2005-10-26 19:32 ` Eli Zaretskii 2005-10-26 20:20 ` Andreas Schwab @ 2005-10-27 4:22 ` Tomas Zerolo 2005-10-27 5:01 ` Eli Zaretskii 1 sibling, 1 reply; 40+ messages in thread From: Tomas Zerolo @ 2005-10-27 4:22 UTC (permalink / raw) Cc: nickrob, Tomas Zerolo, ich, emacs-devel [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: gcc and inline [was: Re: New function for gdb-ui.el?] 2005-10-27 4:22 ` Tomas Zerolo @ 2005-10-27 5:01 ` Eli Zaretskii 2005-10-28 3:47 ` Richard M. Stallman 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2005-10-27 5:01 UTC (permalink / raw) Cc: nickrob, tomas, ich, emacs-devel > 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: gcc and inline [was: Re: New function for gdb-ui.el?] 2005-10-27 5:01 ` Eli Zaretskii @ 2005-10-28 3:47 ` Richard M. Stallman 2005-10-28 8:29 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: Richard M. Stallman @ 2005-10-28 3:47 UTC (permalink / raw) Cc: nickrob, tomas, ich, emacs-devel If you think that GCC is making bad decisions about what to inline, please send specific bug reports to bug-gcc@gnu.org. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: gcc and inline [was: Re: New function for gdb-ui.el?] 2005-10-28 3:47 ` Richard M. Stallman @ 2005-10-28 8:29 ` Eli Zaretskii 2005-10-28 8:34 ` Tomas Zerolo 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2005-10-28 8:29 UTC (permalink / raw) Cc: nickrob, tomas, ich, emacs-devel > 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: gcc and inline [was: Re: New function for gdb-ui.el?] 2005-10-28 8:29 ` Eli Zaretskii @ 2005-10-28 8:34 ` Tomas Zerolo 2005-10-28 11:19 ` Miles Bader 0 siblings, 1 reply; 40+ messages in thread From: Tomas Zerolo @ 2005-10-28 8:34 UTC (permalink / raw) Cc: nickrob, tomas, emacs-devel, rms, ich [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: gcc and inline [was: Re: New function for gdb-ui.el?] 2005-10-28 8:34 ` Tomas Zerolo @ 2005-10-28 11:19 ` Miles Bader 0 siblings, 0 replies; 40+ messages in thread From: Miles Bader @ 2005-10-28 11:19 UTC (permalink / raw) Cc: ich, Eli Zaretskii, nickrob, rms, emacs-devel 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-26 8:58 ` Nick Roberts 2005-10-26 15:02 ` gcc and inline [was: Re: New function for gdb-ui.el?] Tomas Zerolo @ 2005-10-26 19:31 ` Eli Zaretskii 2005-10-27 1:30 ` Richard M. Stallman 2005-10-28 10:54 ` David Hansen 3 siblings, 0 replies; 40+ messages in thread From: Eli Zaretskii @ 2005-10-26 19:31 UTC (permalink / raw) Cc: ich, emacs-devel > 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-26 8:58 ` Nick Roberts 2005-10-26 15:02 ` gcc and inline [was: Re: New function for gdb-ui.el?] Tomas Zerolo 2005-10-26 19:31 ` New function for gdb-ui.el? Eli Zaretskii @ 2005-10-27 1:30 ` Richard M. Stallman 2005-10-28 10:54 ` David Hansen 3 siblings, 0 replies; 40+ messages in thread From: Richard M. Stallman @ 2005-10-27 1:30 UTC (permalink / raw) Cc: eliz, ich, emacs-devel 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-26 8:58 ` Nick Roberts ` (2 preceding siblings ...) 2005-10-27 1:30 ` Richard M. Stallman @ 2005-10-28 10:54 ` David Hansen 2005-10-28 12:22 ` Miles Bader 2005-10-28 21:14 ` Nick Roberts 3 siblings, 2 replies; 40+ messages in thread From: David Hansen @ 2005-10-28 10:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-28 10:54 ` David Hansen @ 2005-10-28 12:22 ` Miles Bader 2005-10-28 21:14 ` Nick Roberts 1 sibling, 0 replies; 40+ messages in thread From: Miles Bader @ 2005-10-28 12:22 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-28 10:54 ` David Hansen 2005-10-28 12:22 ` Miles Bader @ 2005-10-28 21:14 ` Nick Roberts 2005-10-29 13:02 ` David Hansen 1 sibling, 1 reply; 40+ messages in thread From: Nick Roberts @ 2005-10-28 21:14 UTC (permalink / raw) Cc: emacs-devel > > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-28 21:14 ` Nick Roberts @ 2005-10-29 13:02 ` David Hansen 2005-10-29 20:37 ` Nick Roberts 0 siblings, 1 reply; 40+ messages in thread From: David Hansen @ 2005-10-29 13:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-29 13:02 ` David Hansen @ 2005-10-29 20:37 ` Nick Roberts 2005-10-30 0:11 ` Miles Bader 0 siblings, 1 reply; 40+ messages in thread From: Nick Roberts @ 2005-10-29 20:37 UTC (permalink / raw) Cc: emacs-devel > > > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-29 20:37 ` Nick Roberts @ 2005-10-30 0:11 ` Miles Bader 2005-10-30 22:33 ` Nick Roberts 0 siblings, 1 reply; 40+ messages in thread From: Miles Bader @ 2005-10-30 0:11 UTC (permalink / raw) Cc: David Hansen, emacs-devel 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-30 0:11 ` Miles Bader @ 2005-10-30 22:33 ` Nick Roberts 0 siblings, 0 replies; 40+ messages in thread From: Nick Roberts @ 2005-10-30 22:33 UTC (permalink / raw) Cc: David Hansen, emacs-devel 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-25 20:27 ` Richard M. Stallman 2005-10-25 23:00 ` Nick Roberts @ 2005-10-26 6:43 ` Eli Zaretskii 1 sibling, 0 replies; 40+ messages in thread From: Eli Zaretskii @ 2005-10-26 6:43 UTC (permalink / raw) Cc: nickrob, ich, emacs-devel > 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-24 16:27 ` Richard M. Stallman 2005-10-24 20:26 ` Nick Roberts @ 2005-10-25 8:14 ` Eli Zaretskii 1 sibling, 0 replies; 40+ messages in thread From: Eli Zaretskii @ 2005-10-25 8:14 UTC (permalink / raw) Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: New function for gdb-ui.el? 2005-10-23 9:14 New function for gdb-ui.el? Nick Roberts 2005-10-23 11:56 ` Eli Zaretskii @ 2005-10-23 21:26 ` Kim F. Storm 1 sibling, 0 replies; 40+ messages in thread From: Kim F. Storm @ 2005-10-23 21:26 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2005-10-30 22:33 UTC | newest] Thread overview: 40+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-10-23 9:14 New function for gdb-ui.el? Nick Roberts 2005-10-23 11:56 ` Eli Zaretskii 2005-10-23 20:25 ` Nick Roberts 2005-10-23 21:53 ` Kim F. Storm 2005-10-24 6:33 ` Nick Roberts 2005-10-24 11:46 ` Kim F. Storm 2005-10-24 22:07 ` Kim F. Storm 2005-10-24 22:29 ` Nick Roberts 2005-10-25 1:27 ` Nick Roberts 2005-10-25 9:12 ` Kim F. Storm 2005-10-23 20:43 ` Frank Schmitt 2005-10-24 6:57 ` Nick Roberts 2005-10-24 7:35 ` Frank Schmitt 2005-10-24 16:27 ` Richard M. Stallman 2005-10-24 20:26 ` Nick Roberts 2005-10-25 20:27 ` Richard M. Stallman 2005-10-25 23:00 ` Nick Roberts 2005-10-26 6:49 ` Eli Zaretskii 2005-10-26 8:58 ` Nick Roberts 2005-10-26 15:02 ` gcc and inline [was: Re: New function for gdb-ui.el?] Tomas Zerolo 2005-10-26 19:32 ` Eli Zaretskii 2005-10-26 20:20 ` Andreas Schwab 2005-10-27 4:22 ` Tomas Zerolo 2005-10-27 5:01 ` Eli Zaretskii 2005-10-28 3:47 ` Richard M. Stallman 2005-10-28 8:29 ` Eli Zaretskii 2005-10-28 8:34 ` Tomas Zerolo 2005-10-28 11:19 ` Miles Bader 2005-10-26 19:31 ` New function for gdb-ui.el? Eli Zaretskii 2005-10-27 1:30 ` Richard M. Stallman 2005-10-28 10:54 ` David Hansen 2005-10-28 12:22 ` Miles Bader 2005-10-28 21:14 ` Nick Roberts 2005-10-29 13:02 ` David Hansen 2005-10-29 20:37 ` Nick Roberts 2005-10-30 0:11 ` Miles Bader 2005-10-30 22:33 ` Nick Roberts 2005-10-26 6:43 ` Eli Zaretskii 2005-10-25 8:14 ` Eli Zaretskii 2005-10-23 21:26 ` Kim F. Storm
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.