tui/2546: TUI shoudn't reread changed source files

tui/2546: TUI shoudn't reread changed source files

[balacobaco]

>Number:         2546
>Category:       tui
>Synopsis:       TUI shoudn't reread changed source files
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 03 22:38:02 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     balacobaco@imap.cc
>Release:        GNU gdb 6.8-debian
>Organization:
>Environment:
Linux goof 2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686 GNU/Linux

>Description:
When using TUI do debug programs, and the source is changed by some other programs, the debugging session should be able to continue normally. It very common for me to find a bug and alter it right away on my source code. Keeping files unsaved isn't good practice overall, right? And the problem is annoyer when the changes are simple (like typos) or just cosmestic (formatting expressions, lines, ...) or doesn't have to do with one specific problem I pursue on that debugging session.

I think that gdbtui should either reload both executable and source text, or keep the source in memory. But more problems will arise with multi-file program, I think. Maybe the date of the files when the program was compiled should exist and be verified from gdb?

Ps: if I would be to save some state from a gdbtui session (like comand history) would be a nice thing to do together with solving this problem.
>How-To-Repeat:
To reproduce the behavior I refer: load a program on a new GDBTUI session. Step to some source line. Alter the source code on that (or others) line. Run the program so that the altered lines goes out of screen at some point, before you reach them again. Now you are debugging a program seeing the source of another program.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: