Thread: [Cgdb-devel] cgdb and assembly
Brought to you by:
bobbybrasko,
crouchingturbo
From: Bob R. <bo...@br...> - 2003-07-30 01:55:50
|
Hi, I have been thinking about the best way to add assembly to cgdb. As of now, cgdb uses the line and file as the unique mapping to what should be display to the user. This will probably change. I am not sure how it should be implemented, but I think I have a clear idea of what it should do. IMO, there should be a colon command, that lets the user change the way the current window displays to the user their program. Here are some: 1. Allow the window to show only the source code ( the default )=20 2. Allow the window to show only assembly 3. Allow the window to show mixed. This should be modular so that the user can open a window, make it follow the source, open another window, make it follow assembly, and open another window and make it be mixed. All of these things should work at the same time. What does everyone think? It seems like it will be a pretty hard task. Bob Rossi |
From: Peter K. <pe...@ko...> - 2003-07-30 11:43:27
|
I'm not sure that its all entirely necessary, although I definitely like the idea of the multiple source view windows. So, first of all, I think that we should have Source and Mixed Assembly. I personally think that's the most useful view. When you're in Mixed, next implicitly means 'nexti' (next instruction). I'll have to think about the multiple source views problem. I'm thinking some sort of event system, however I'm not sure that would be the best thing to bundle into libtgdb which we eventually hope to be used by other parties. The idea would be that tgdb would output different types of events like 'view source' events or 'terminal output'. cgdb would be responsible for catching these events, and distributing them to the right places. Seems a tad overly complicated, but it might be a step in the right direction. Another idea would be to register a series of callback functions. So when you create a source view, you register with tgdb and get called whenever there is a source view update. The problem with this, (and with the event based approach) is how do you handle source file changes. Do you wipe out all the windows? Do you refresh all the windows with the new source file? - Peter On Tue, Jul 29, 2003 at 09:55:42PM -0400, Bob Rossi wrote: > Hi, >=20 > I have been thinking about the best way to add assembly to cgdb. > As of now, cgdb uses the line and file as the unique mapping to what > should be display to the user. This will probably change. I am not sure > how it should be implemented, but I think I have a clear idea of what it > should do. >=20 > IMO, there should be a colon command, that lets the user change the way > the current window displays to the user their program. Here are some: > 1. Allow the window to show only the source code ( the default )=20 > 2. Allow the window to show only assembly > 3. Allow the window to show mixed. >=20 > This should be modular so that the user can open a window, make it follow > the source, open another window, make it follow assembly, and open > another window and make it be mixed. All of these things should work at > the same time. >=20 > What does everyone think? It seems like it will be a pretty hard task. >=20 > Bob Rossi --=20 Peter D. Kovacs <pe...@ko...> |
From: Mike M. <mmu...@cs...> - 2003-07-30 14:19:02
|
On Wed, 30 Jul 2003, Peter Kovacs wrote: :I'm not sure that its all entirely necessary, although I definitely like :the idea of the multiple source view windows. The point is generality. If we have the ability to set a window to any mode (source, asm, mixed), then the user has the most freedom. He could have a source window and an asm window going at the same time, or he could use one window with the mixed view, or do other combinations that we're not even considering right now. The way we're looking at it is why impose limitations? :So, first of all, I think that we should have Source and Mixed Assembly. :I personally think that's the most useful view. When you're in Mixed, :next implicitly means 'nexti' (next instruction). That's an interesting point. Since we don't really have 'next' shortcuts anymore, I don't think it's applicable though. We don't really want to intercept the user's typed commands to gdb, that is too nasty. It does raise the issue of whether we should reintroduce the shortcuts, maybe through :commands. :I'll have to think about the multiple source views problem. I'm :thinking some sort of event system, however I'm not sure that would be :the best thing to bundle into libtgdb which we eventually hope to be :used by other parties. The idea would be that tgdb would output :different types of events like 'view source' events or 'terminal :output'. cgdb would be responsible for catching these events, and :distributing them to the right places. Seems a tad overly complicated, :but it might be a step in the right direction. : :Another idea would be to register a series of callback functions. So :when you create a source view, you register with tgdb and get called :whenever there is a source view update. The problem with this, (and :with the event based approach) is how do you handle source file changes. :Do you wipe out all the windows? Do you refresh all the windows with :the new source file? Bob & I were thinking of using a callback system for this, I believe. The event system is tough because the main loop for a UI is always going to be a select() loop. To have an event-driven system means we'd have to somehow get the UI out of the select loop so that we can call event-handling functions. It seems simpler to just use callbacks. : :- Peter Mike |