This is the mail archive of the gdb-patches@sourceware.org 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] |
Hello, As I said before, the goal of this exercise is to avoid having to play with the current language in order to do parsing operations in a language that may not be the current language. The approach I'm taking to this is that functions that require a language-specific operation to be done should either: - know which language should be used (for instance, an Ada exception catchpoint location should be parsed using the Ada language) - Or: Be passed the language to use as a parameter. This is by far the most common case. At the end of the exercise, the only functions that shoudl be using the current_language are the function that implement GDB commands. I've started working on this, and although it's far from being done, the changes are touching a lot of files. I'm doing the transition piece-meal, by starting from the expression-parsing routines, and will work my way up until current_language is only used in "command" functions. More precisely, the algorithm used is: - Modify the profile of some routines to add a language as a param. - Modify the body of these routines to use that language instead of the current_language - Update the callers of this routine as follow: 1. If the caller implements a GDB command, then we know that the user means that we should be using the current language to evaluate his command. If the function is only called by "command" functions, then I may elect to use "current_language". Adding an extra language parameter to that function would be cleaner, but on the other hand wouldn't change anything. Not adding it reduces the size of the patch. 2. Otherwise, If we have the language handy, then use that language (eg: if the language is a parameter, or if we're given a breakpoint as a parameter, for instance) 3. If the language is not handily available *yet*, then use a temporary function called "curr_language ()" that returns the current_language. In essence, this is like updating the call to use current_language except that I'm marking this specific instance so that I can easily find again later which uses of current_language I have introduced but still need to be removed. Note that, when I post the final patches for review, curr_language will be removed, and replaced with plain old current_language. This is only used by me as a helper. At each iteration, I look for some instances of "curr_language", choose a routine that I want to adjust, and then apply the algorithm above. I'm done when there are no longer any curr_language calls :). Although the changes are rather mechanical, they are fairly extensive and touch a lot of files. I would really apprieciate some feedback on the patches attached to this email. This is only a preview of the entire work which I hope to complete soon. The patches do: - 01-parse_expr.diff: Update the parse_expression routines, update the callers. - 02-breakpoint.c.diff: Transition breakpoint.c. Update all the callers of the functions that were adjusted. - 03-parse_and_eval_address.diff: Update parse_and_eval_address. Update all callers. I have a bunch of other functions in eval.c that I can transition as separate patches, so the patches should be reasonably small. I might bunch them together and that would make one large patch instead of a collection of small ones, but that would be slightly simpler for me, because it reduces the number of patches (which may be large by the time I'm done). So? Does this look OK for everyone? Thanks, -- Joel
Attachment:
01-parse_expr.diff
Description: Text document
Attachment:
02-breakpoint.c.diff
Description: Text document
Attachment:
03-parse_and_eval_address.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |