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]

Re: RFC: fix bug when debugging prelink'd library


>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Tom> This fixes the problem by changing dwarf2_per_cu_objfile to return the
Tom> debuginfo objfile.  This appears to be correct for all callers except
Tom> one, which I also updated.

Jan> As I find the API difficult to figure out which variant of `struct
Jan> objfile *' there is I tried to unify it - choosing the variant (A)
Jan> described at:
Jan> 	[patch 12/15] PIE: Support loading PIEs from core files
Jan> 	http://sourceware.org/ml/gdb-patches/2009-11/msg00179.html

I agree that one of these approaches is good for generic code in gdb.
(Actually -- I would much prefer a different design, where there is no
ambiguity possible.  But that seems like a big refactoring without a big
user-visible benefit.)

Jan> In such case I miss at least some fat comment at
Jan> dwarf2_per_cu_objfile stating it returns non-primary objfile
Jan> variant.

I will do that.

Jan> dwarf2_per_cu_objfile result is in most cases used only for
Jan> get_objfile_arch (should not matter) and
Jan> 	CORE_ADDR base_offset = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile));
Jan> so there could be rather function dwarf2_per_cu_base_offset.

Actually, I think I will do this.  It does mean we need 3 new accessors,
which is ugly.  OTOH, I found that we use the objfile's name in
locexpr_describe_location_piece, and there I think we also want the
master objfile.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]