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] |