This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [branch patch] dwarf-frame.c support for .eh_frame_hdr
Mark Kettenis writes:
> Date: Mon, 12 May 2003 02:46:54 -0700
> From: Roland McGrath <roland@redhat.com>
>
> 2003-05-12 Roland McGrath <roland@redhat.com>
>
> * dwarf2read.c (dwarf_eh_frame_hdr_offset, dwarf_eh_frame_hdr_size,
> dwarf_eh_frame_hdr_section): New variables.
> (dwarf2_locate_sections): Match a section whose name starts with
> "eh_frame_hdr", and set those.
> (dwarf2_has_info): Clear dwarf_eh_frame_hdr_offset here.
> * dwarf-frame.c (decode_eh_frame_hdr): New function.
> (dwarf2_build_frame_info): Call it when dwarf_eh_frame_hdr_offset
> is set but dwarf_eh_frame_offset is not.
>
> Having to build a "dummy" `struct comp_unit' probably indicates that I
> should change read_encoded_value()'s signature. Well, I'll worry
> about that later.
>
> The error messages in dwarf-frame.c should probably be harmonized
> before we check merge this into mailine. I wonder whether we should
> complaint() instead of error().
>
> Is there a particular reason why you don't read in the .eh_frame_hdr
> section as a whole as the other parts of GDB's "symbol reader" do (and
> which I just blindly copied when I wrote the guts of dwarf-frame.c)?
>
> * symfile.c (symfile_bfd_open): Try bfd_check_format with bfd_core
> if bfd_object fails.
>
> I think a more elaborate comment on why core files might have
> "symbols" is appropriate.
>
Did we settle on this being the solution though? I think the
/proc/PID/auxv approach is a bit cleaner. Not to say that there aren't
things here that are probably necessary anyway, but the debate is
still ongoing.
elena
> Mark