Re: [branch patch] dwarf-frame.c support for .eh_frame_hdr

[Elena Zannoni <ezannoni@redhat.com>]

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