This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Daniel, On Wed, May 19, 2004 at 11:41:55AM -0400, Daniel Jacobowitz wrote: > On Wed, May 19, 2004 at 08:36:15AM -0700, Joel Brobecker wrote: > > So let's go for that route. How about: > > 1. I add the language-specific hook the way I designed it > > in my last patch. > > 2. Use that hook in main_name() when the debug info didn't provide > > the name of the main procedure. > > 3. Modify start_command to use main_name() instead of the language > > hook. > > > > Would that work for you? > > That sounds good to me. I was implementing this approach, with symtab.c caching the name_of_main so that we would compute it only once per executable loaded, but then just realized something that made me very uneasy. Basically, because of the caching, we've transformed name_of_main into a random value, because it depends on the value of the current language at a certain random point in time. And that value will not be changed again until the user reloads his executable again (via exec-file). That could lead to situations where the wrong value for name_of_main is computed. Consider the following example: The user has an Ada program. Like every program, it has some bits and pieces that are not Ada. It could be a multi-language application but also an Ada program linked to the libc. Anyway, he inserts a breakpoint inside some non-Ada routine, does a "run", then a backtrace => we set "name_of_main" in symtab.c using the non-ada language vector => name_of_main will likely be wrong. At this point, GDB will unwind up to the wrong frame (one frame too high in case of Ada programs), but even more problematic is the fact that the "start" command will stop at the wrong place. And forcing the language to Ada won't help. We could get rid of the caching mechanism, and recompute name_of_main everytime (unless found in the debug info), but I think that would be very costly, especially with graphical front-ends that have a tendency of asking for the callstack at every stop... We could try to make it a little smarter, by recomputing the name_of_main if the value we previously computed was for a different language. I think that we will still end up recomputing it fairly often as callstacks involving more than one language can be fairly common. Or another better approach, is to store an array of name_of_main, one per language, and then get main_name() to return the correct one based on the language given to it. That way, we only compute it once per language (will usually be once or twice per session, three times at most, I would anticipate). Unfortunately, this raises the same sort of issues, because there will be times when we call main_name() with the idea of getting the main program name from the user's point of view, and we will simply not know which language to select for that. Or the last approach would be to leave main_name() alone, and make the "start" command independent of that mechanism (my initial approach). Computing the main name lazily and caching sounds like a perfect receipe for incorrect behavior. So I think we have two possible alternatives at this stage: . Recompute name_of_main every time (big performance penalty I think) . Dissociate the "start" command infrastructure from the name_of_main() infrastructure, and keep my initial approach. I know you would like to avoid having several mechanisms computing the name of main, but I think this is our best alternative in this case. What do you think? I am attaching a patch to symtab.c just to illustrate what I was trying to do. -- Joel
Attachment:
symtab.c.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |