* question about breakpoints @ 2000-12-04 13:01 Tom Tromey 2000-12-04 13:49 ` Fernando Nasser 2000-12-04 15:43 ` Fernando Nasser 0 siblings, 2 replies; 12+ messages in thread From: Tom Tromey @ 2000-12-04 13:01 UTC (permalink / raw) To: Insight List Today I've done a bit of work on making my session saving code also save breakpoints and watchpoints. I'd really like to access the `exp_string' and `addr_string' fields of gdb's `struct breakpoint'. Currently the Tcl interface gives me no way to do that. What is the preferred fix here? One idea would be to introduce a new Tcl command, like `gdb_get_breakpoint_info_x" (x == "extended", a MS-esque naming choice). Another idea might be to update gdb_get_breakpoint_info (and all callers -- you can see why I might be reluctant to do this). Maybe there is another choice I'm missing? I'm a bit concerned about the ad hoc nature of the gdb-specific Tcl commands implemented in C. There are a lot of these, but we need more, and there doesn't seem to be any coherent guidelines governing how they should act. It leaves me questioning the long-term viability of this approach. I know the long term plan is to use MI and have gdbtk be a separate process. That's fine. But even then we need some API to gdb. Changing APIs during this transition is going to be very hard if there is a lot of ad hoc code to update, especially when you consider that this will have to be done on top of solving the other problems inherent in the two-process approach. Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: question about breakpoints 2000-12-04 13:01 question about breakpoints Tom Tromey @ 2000-12-04 13:49 ` Fernando Nasser 2000-12-04 14:51 ` Tom Tromey 2000-12-04 15:43 ` Fernando Nasser 1 sibling, 1 reply; 12+ messages in thread From: Fernando Nasser @ 2000-12-04 13:49 UTC (permalink / raw) To: tromey; +Cc: Insight List Tom, You are right that the interface commands were created ad hoc. They were created over time as needed. This was unavoidable as there were no good previous knowledge of what was needed. This will be cleared with time. As part of the "libgdb" project I have studied how all the GUIs accessed GDB data and one of the results of this study was the current set of MI commands. This study was revised by several other people at the time, and it is supposed to be able to supply a functional GUI with the necessary data. With regards to the API, it was one of the things I did as part of my PhD work some years ago. However, GDB folks have decided that we will discuss the API publicly in the GDB list when time is right. One of the things that will be taken into account is what the different interfaces to GDB will be using. This includes Insight, other GUIs, the CLI (when properly separated) as well as the planned script languages (GUILE and others). For now let's just add what we need but using common sense. Try to mimic the MI as much as possible to facilitate things in the future. Your proposed extension to gdb_get_breakpoint_info is a good idea. I guess you won't have time to change all the callers, so you can create and use a gdbtk_get_breakpoint_info and use it. We get rid of the old gdb_get_breakpoint_info during the planned cleanup. However, I would ask you not to use an array. If you return a list of pairs you'll be providing exactly (or close to) what will be automatically provided by the tcl-out code in the future. In gdb/breakpoints.c you'll find the keys used for each field in the ui_out code. Thanks. Regards, Fernando Tom Tromey wrote: > > Today I've done a bit of work on making my session saving code also > save breakpoints and watchpoints. > > I'd really like to access the `exp_string' and `addr_string' fields of > gdb's `struct breakpoint'. Currently the Tcl interface gives me no > way to do that. > > What is the preferred fix here? One idea would be to introduce a new > Tcl command, like `gdb_get_breakpoint_info_x" (x == "extended", a > MS-esque naming choice). Another idea might be to update > gdb_get_breakpoint_info (and all callers -- you can see why I might be > reluctant to do this). > > Maybe there is another choice I'm missing? > > I'm a bit concerned about the ad hoc nature of the gdb-specific Tcl > commands implemented in C. There are a lot of these, but we need > more, and there doesn't seem to be any coherent guidelines governing > how they should act. It leaves me questioning the long-term viability > of this approach. > > I know the long term plan is to use MI and have gdbtk be a separate > process. That's fine. But even then we need some API to gdb. > Changing APIs during this transition is going to be very hard if there > is a lot of ad hoc code to update, especially when you consider that > this will have to be done on top of solving the other problems > inherent in the two-process approach. > > Tom -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: question about breakpoints 2000-12-04 13:49 ` Fernando Nasser @ 2000-12-04 14:51 ` Tom Tromey 0 siblings, 0 replies; 12+ messages in thread From: Tom Tromey @ 2000-12-04 14:51 UTC (permalink / raw) To: Fernando Nasser; +Cc: Insight List Fernando> However, I would ask you not to use an array. If you return Fernando> a list of pairs you'll be providing exactly (or close to) Fernando> what will be automatically provided by the tcl-out code in Fernando> the future. In gdb/breakpoints.c you'll find the keys used Fernando> for each field in the ui_out code. I assume you are referring to the function print_one_breakpoint. I looked and it also doesn't print the fields I want. Overall I think your plan sounds good though. Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: question about breakpoints 2000-12-04 13:01 question about breakpoints Tom Tromey 2000-12-04 13:49 ` Fernando Nasser @ 2000-12-04 15:43 ` Fernando Nasser 2000-12-04 16:17 ` Tom Tromey 1 sibling, 1 reply; 12+ messages in thread From: Fernando Nasser @ 2000-12-04 15:43 UTC (permalink / raw) To: tromey; +Cc: Insight List Tom Tromey wrote: > > I'd really like to access the `exp_string' and `addr_string' fields of > gdb's `struct breakpoint'. Currently the Tcl interface gives me no > way to do that. > Sorry Tom, I missed the fact that these two are not ever printed. In this case a new function would be in order. I also missed the fact that before the CLI is converted, we cannot add info to this commands without having them printed as well (something not difficult to fix but that we haven't added because it would eventually become unnecessary). I thought you were going to save/reinsert breakpoints based on the symbolic information rather than in the addresses. That has a better chance of surviving between debugger invocation. In that case you could be able to reconstruct a "linespec" from the print_one_breakpoint info (i.e., our gdb_get_breakpoint_info). Regards, Fernando -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: question about breakpoints 2000-12-04 15:43 ` Fernando Nasser @ 2000-12-04 16:17 ` Tom Tromey 2000-12-05 5:54 ` Keith Seitz 0 siblings, 1 reply; 12+ messages in thread From: Tom Tromey @ 2000-12-04 16:17 UTC (permalink / raw) To: Fernando Nasser; +Cc: Insight List Fernando> Sorry Tom, I missed the fact that these two are not ever Fernando> printed. In this case a new function would be in order. I think converting the existing function and then adding new output to it is the best approach. Fernando> I thought you were going to save/reinsert breakpoints based Fernando> on the symbolic information rather than in the addresses. Yes. My understanding is that `addr_string' and `exp_string' are the original strings used by the user to set the breakpoint or expression (resp). I say this because that is what the comments in breakpoint.h imply. Am I wrong? Fernando> In that case you could be able to reconstruct a "linespec" Fernando> from the print_one_breakpoint info (i.e., our Fernando> gdb_get_breakpoint_info). I don't think so. If the user types "b function" there is no way to differentiate that from "b file:line". In both situations we get all that information from gdb_get_breakpoint_info. Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: question about breakpoints 2000-12-04 16:17 ` Tom Tromey @ 2000-12-05 5:54 ` Keith Seitz 2000-12-05 7:06 ` Fernando Nasser 2000-12-05 9:31 ` Tom Tromey 0 siblings, 2 replies; 12+ messages in thread From: Keith Seitz @ 2000-12-05 5:54 UTC (permalink / raw) To: tromey; +Cc: Fernando Nasser, Insight List Tom Tromey wrote: > > Fernando> Sorry Tom, I missed the fact that these two are not ever > Fernando> printed. In this case a new function would be in order. > > I think converting the existing function and then adding new output to > it is the best approach. > I'm with Tom on this one. This is one of those really, really old functions from the original gdbtk which has survived into this "new" version. Its intent is to provide all the information there is about a breakpoint. I believe that this function should be extended to include the information about the breakpoint, since this is the function's purpose. Of course, there is an argument here to be made that we should restructure gdbtk commands to look more like tcl commands, i.e., "breakpoint set", "breakpoint enable", "breakpoint disable", "breakpoint info", etc. Just a thought. :-) > Fernando> I thought you were going to save/reinsert breakpoints based > Fernando> on the symbolic information rather than in the addresses. > > Yes. My understanding is that `addr_string' and `exp_string' are the > original strings used by the user to set the breakpoint or expression > (resp). I say this because that is what the comments in breakpoint.h > imply. Am I wrong? I believe that this is correct. This is exactly what you would want. (At least, that is the way I remember it, too. I seem to recall that this bit me once or twice while trying to do something.) My $0.02. Keith ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: question about breakpoints 2000-12-05 5:54 ` Keith Seitz @ 2000-12-05 7:06 ` Fernando Nasser 2000-12-05 9:43 ` Tom Tromey 2000-12-05 9:31 ` Tom Tromey 1 sibling, 1 reply; 12+ messages in thread From: Fernando Nasser @ 2000-12-05 7:06 UTC (permalink / raw) To: Keith Seitz; +Cc: tromey, Insight List Keith Seitz wrote: > > Tom Tromey wrote: > > > > Fernando> Sorry Tom, I missed the fact that these two are not ever > > Fernando> printed. In this case a new function would be in order. > > > > I think converting the existing function and then adding new output to > > it is the best approach. > > > > I'm with Tom on this one. This is one of those really, really old > functions from the original gdbtk which has survived into this "new" > version. Its intent is to provide all the information there is about a > breakpoint. > > I believe that this function should be extended to include the > information about the breakpoint, since this is the function's purpose. > Unfortunately this will make my life more difficult afterwards. The corresponding MI call has the contents frozen because of the CLI. I had a function to add extra fields but I was asked to try to avoid adding it. So I would prefer a separate function for these fields. Furthermore, the first set (in the current command) is user oriented info, while the second one would be for some non-visible internal hack. I don't think we should mix these much (MI has parameters of the "-X" kind -- we could add one to the command if necessary, but not alter the current result). And I disagree with the way this is supposed to work (see below). > Of course, there is an argument here to be made that we should > restructure gdbtk commands to look more like tcl commands, i.e., > "breakpoint set", "breakpoint enable", "breakpoint disable", "breakpoint > info", etc. Just a thought. :-) > > > Fernando> I thought you were going to save/reinsert breakpoints based > > Fernando> on the symbolic information rather than in the addresses. > > > > Yes. My understanding is that `addr_string' and `exp_string' are the > > original strings used by the user to set the breakpoint or expression > > (resp). I say this because that is what the comments in breakpoint.h > > imply. Am I wrong? > > I believe that this is correct. This is exactly what you would want. (At > least, that is the way I remember it, too. I seem to recall that this > bit me once or twice while trying to do something.) > I haven't looked at what `addr_string' and `exp_string' are. The names seem to be badly chosen. But I don't think you (or whoever adds saved breaks) should necessarily use the same specification as the user (who would have most probably clicked on the source window, but not necessarily). The debugger must use some smart algorithm to maximize the chances that the breakpoint is still meaningful. This means using all the information available, which is already in the current command. This was discussed before with several engineers who were writing a GUI for GDB and they deemed the current output as sufficient for their implementation. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: question about breakpoints 2000-12-05 7:06 ` Fernando Nasser @ 2000-12-05 9:43 ` Tom Tromey 2000-12-05 10:06 ` Fernando Nasser 0 siblings, 1 reply; 12+ messages in thread From: Tom Tromey @ 2000-12-05 9:43 UTC (permalink / raw) To: Fernando Nasser; +Cc: Keith Seitz, Insight List Fernando> Unfortunately this will make my life more difficult Fernando> afterwards. The corresponding MI call has the contents Fernando> frozen because of the CLI. If you really can't add new fields as time goes on then it sure seems brittle, doesn't it? I took a brief look through the mi docs and I don't see where it says that programs can rely on the fields remaining fixed. Fernando> But I don't think you (or whoever adds saved breaks) should Fernando> necessarily use the same specification as the user (who Fernando> would have most probably clicked on the source window, but Fernando> not necessarily). The debugger must use some smart Fernando> algorithm to maximize the chances that the breakpoint is Fernando> still meaningful. This means using all the information Fernando> available, which is already in the current command. There is no way to ensure that the breakpoint will always be useful. As a user I would expect that if I type `b function' in the console, then when I reload the session I get a breakpoint on the function and not at some random "useful" place. In other words, it is easier to predict, and therefore use, tools that are dumb than tools that try to be smart. I agree that for breakpoints set via the GUI it might make sense to apply some heuristic in some situations. For instance if you use the GUI to set a breakpoint on the first executable line of a function you might choose to have the session interpret that as a breakpoint on the function and not on a particular line. As another example of why we need more information, consider the language used to set a breakpoint condition. This is stored in struct breakpoint, but isn't printed out. But I think we need this information to correctly restore breakpoint conditions. Finally, the information returned by the current gdb_get_breakpoint_info command apparently can't be used to set the breakpoint. As a first try I made the code restore breakpoints using "b file:line". gdb claims to never have heard of the file specified. I wonder if the file name is being munged somehow before return? Fernando> This was discussed before with several engineers who were Fernando> writing a GUI for GDB and they deemed the current output as Fernando> sufficient for their implementation. Do you have a pointer to this discussion? Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: question about breakpoints 2000-12-05 9:43 ` Tom Tromey @ 2000-12-05 10:06 ` Fernando Nasser 2000-12-05 12:17 ` Tom Tromey 0 siblings, 1 reply; 12+ messages in thread From: Fernando Nasser @ 2000-12-05 10:06 UTC (permalink / raw) To: tromey; +Cc: Keith Seitz, Insight List Tom Tromey wrote: > > Fernando> Unfortunately this will make my life more difficult > Fernando> afterwards. The corresponding MI call has the contents > Fernando> frozen because of the CLI. > > If you really can't add new fields as time goes on then it sure seems > brittle, doesn't it? I took a brief look through the mi docs and I > don't see where it says that programs can rely on the fields remaining > fixed. > I will, after the CLI is changed to use it. It currently shares the output generation code. The programs that use the MI must only rely that the fields they use will be kept, they don't care about things that are added. But while the CLI uses the same code to print output, the contents and order are fixed. This is relaxed whenever a CLI command is fixed. This is on the works, but will still take some time. > Fernando> But I don't think you (or whoever adds saved breaks) should > Fernando> necessarily use the same specification as the user (who > Fernando> would have most probably clicked on the source window, but > Fernando> not necessarily). The debugger must use some smart > Fernando> algorithm to maximize the chances that the breakpoint is > Fernando> still meaningful. This means using all the information > Fernando> available, which is already in the current command. > > There is no way to ensure that the breakpoint will always be useful. > No, and nobody said that. > As a user I would expect that if I type `b function' in the console, > then when I reload the session I get a breakpoint on the function and > not at some random "useful" place. > "b function" seems to be one that this code will always guess right. > In other words, it is easier to predict, and therefore use, tools > that are dumb than tools that try to be smart. > Trying to keep breakpoints between debugger invocations is, by definition, trying to be smart. And, BTW, this is not even in our TODO list and we have several higher prioroty items to tackle. I would suggest discussing this at a later time as it seems to be a rather polemic topic. I have seem such discussion before and this will be a long thread. Unfortunately this was before this list was created so we don't have the archives and I also believe several of the discussions were on physical meetings. -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: question about breakpoints 2000-12-05 10:06 ` Fernando Nasser @ 2000-12-05 12:17 ` Tom Tromey 0 siblings, 0 replies; 12+ messages in thread From: Tom Tromey @ 2000-12-05 12:17 UTC (permalink / raw) To: Fernando Nasser; +Cc: Keith Seitz, Insight List Fernando> And, BTW, this is not even in our TODO list and we have Fernando> several higher prioroty items to tackle. It should be on the to-do list. The to-do list should also be checked in. Fernando> I would suggest discussing this at a later time as it seems Fernando> to be a rather polemic topic. Ok, I'll skip it. Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: question about breakpoints 2000-12-05 5:54 ` Keith Seitz 2000-12-05 7:06 ` Fernando Nasser @ 2000-12-05 9:31 ` Tom Tromey 2000-12-05 9:40 ` Fernando Nasser 1 sibling, 1 reply; 12+ messages in thread From: Tom Tromey @ 2000-12-05 9:31 UTC (permalink / raw) To: Keith Seitz; +Cc: Fernando Nasser, Insight List Keith> Of course, there is an argument here to be made that we should Keith> restructure gdbtk commands to look more like tcl commands, Keith> i.e., "breakpoint set", "breakpoint enable", "breakpoint Keith> disable", "breakpoint info", etc. Just a thought. :-) This would be nice. Consider if you are setting a breakpoint right now from Tcl. I don't think there is an easy way to find the number of the breakpoint you just created (eg if you want to immediately disable it). In the session loading code I assume it is the highest numbered breakpoint. This is ugly though. A real `breakpoint' command could just return this info without much fuss. Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: question about breakpoints 2000-12-05 9:31 ` Tom Tromey @ 2000-12-05 9:40 ` Fernando Nasser 0 siblings, 0 replies; 12+ messages in thread From: Fernando Nasser @ 2000-12-05 9:40 UTC (permalink / raw) To: tromey; +Cc: Keith Seitz, Insight List Tom Tromey wrote: > > Keith> Of course, there is an argument here to be made that we should > Keith> restructure gdbtk commands to look more like tcl commands, > Keith> i.e., "breakpoint set", "breakpoint enable", "breakpoint > Keith> disable", "breakpoint info", etc. Just a thought. :-) > > This would be nice. Consider if you are setting a breakpoint right > now from Tcl. I don't think there is an easy way to find the number > of the breakpoint you just created (eg if you want to immediately > disable it). In the session loading code I assume it is the highest > numbered breakpoint. This is ugly though. A real `breakpoint' > command could just return this info without much fuss. > Well, some of us have a devious plan to have a Tcl script language to gdb (although others want GUILE, other Perl, others something else). These script languages will be calling "libgdb" functions. But this is subject for another list and it is not the proper time either. There is some ground work to be done before that is possible. -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2000-12-05 12:17 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-12-04 13:01 question about breakpoints Tom Tromey 2000-12-04 13:49 ` Fernando Nasser 2000-12-04 14:51 ` Tom Tromey 2000-12-04 15:43 ` Fernando Nasser 2000-12-04 16:17 ` Tom Tromey 2000-12-05 5:54 ` Keith Seitz 2000-12-05 7:06 ` Fernando Nasser 2000-12-05 9:43 ` Tom Tromey 2000-12-05 10:06 ` Fernando Nasser 2000-12-05 12:17 ` Tom Tromey 2000-12-05 9:31 ` Tom Tromey 2000-12-05 9:40 ` Fernando Nasser
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).