This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug python/17936] New: clear_objfiles event is called twice for executable + separate debug file
- From: "dje at google dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Fri, 06 Feb 2015 18:32:22 +0000
- Subject: [Bug python/17936] New: clear_objfiles event is called twice for executable + separate debug file
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17936
Bug ID: 17936
Summary: clear_objfiles event is called twice for executable +
separate debug file
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: python
Assignee: unassigned at sourceware dot org
Reporter: dje at google dot com
When the separate debug file for the main executable is loaded SYMFILE_MAINLINE
is still set and so clear_symtab_users is called which will in turn trigger a
clear_objfiles python event.
Then, later, when resuming processing of the "real" objfile a second call to
clear_symtab_users is done triggering a second clear_objfiles python event.
Python scripts shouldn't have to cope with this internal quirk of how gdb loads
separate debug files.
Plus, I wonder if internal users of observer_attach_new_objfile are, or can be,
tripped up by this.
OTOH, the solution may be slightly non-trivial. I think we want
clear_symtab_users to be called early, and not after the separate debug file
is loaded (e.g., we can't just turn off SYMFILE_MAINLINE when loading the
separate debug file).
Also, I noticed that new_symfile_objfile will have, temporarily, set
symfile_objfile to the separate debug file. This gets fixed when processing
of the "real" objfile resumes, after having completed processing of the
separate
debug file. Still, this feels like a bug waiting to happen.
--
You are receiving this mail because:
You are on the CC list for the bug.