emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New function for gdb-ui.el?


From: Eli Zaretskii
Subject: Re: New function for gdb-ui.el?
Date: Tue, 25 Oct 2005 10:14:19 +0200

> From: "Richard M. Stallman" <address@hidden>
> Date: Mon, 24 Oct 2005 12:27:41 -0400
> Cc: address@hidden
> 
>     > 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]