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] |
> Could you try one more thing for me? Sure! > As you noticed, the only two functions that dwarf_decode_lines calls > to actually record the information it gets are > buildsym.c:start_subfile (via dwarf2_start_subfile) and > buildsym.c:record_line. Could you change dwarf_decode_lines to take > two function pointers (with an accompanying closure pointer) for those > two functions? I guess this is an instance of the 'builder' pattern, > so maybe name it something appropriately suggestive. Let > dwarf_decode_lines continue to call dwarf2_start_subfile directly, > just passing the builder func and closure along with filename and > dirname. > > Then, instead of duplicating dwarf_decode_lines, have the existing > call in read_file_scope and the new call you've added just pass > different function/closures to it. I was just wondering, before trying that, if we couldn't maybe do it in a little simpler way, but non-generic way. Using the approach you suggest (which I like): We need to define a couple of wrapper functions around start_subfile and record_line because their profile will not match the profile of our callbacks. We'll need 3 callbacks per case (3 for psymtabs, 3 for symtabs). We'll also have to use void* pointers if we want to make the context generic, which I would prefer to avoid. It's great for heavily reused code, but is this worth it for this function. What we could do instead, is: . Add a new parameter: struct partial_symtab *pst . If this pst is NULL, then scan for symtabs as before . If pst is non NULL, then scan for partial symtabs, and do not call the 2 buildsym.c functions. Just for illustration purposes, I tweaked my previous patch. Attached is a new patch that shows what it would become. I did this because even if we end up not choosing this solution, it's still a good intermediate version on which to implement your suggestion. I verified that the performance impact on GDB was still pretty small. If you like it, then I'll review, clean it up and properly submit it for review. Otherwise, I'll send a new version including your suggestion. Thanks, -- Joel
Attachment:
dw2-includes.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |