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

[Roland McGrath <roland@redhat.com>]

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

Yeah, it was ok.  Since you need to provide several things for it to work
in all cases (the bfd for byteorder, dwarf_frame_* for relative calculation)
using that struct seems about as good as anything.

> 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().

I have no opinion on that.  The style of the messages I added was pretty
much copied from dwarf2read.c and/or dwarf2cfi.c.  I can update the code I
added following whatever model of similar error reporting you point me at.

> 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)?

Not really.  It was as easy to write it that way as anything else.
bfd_bread is already going through stdio (or even BFD_IN_MEMORY), so the
buffering of the reads is not really an issue (in copying the whole section
you are just copying from one memory buffer to another).  I may have had it
in the back of my head that I wouldn't know the size until I decoded the
header and FDE count, but the section bounds do already suffice and just
reading the whole section in one chunk would be fine.  I can rewrite it
that way if people prefer it.

> 	   * 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.

Yes, I hadn't really intended this patch to go in without further vetting.
I included it in the posting because it lets you do the test I demonstrated
to exercise the new dwarf-frame.c code.  I included it with the posting of
the corelow.c patch that makes it really relevant, which also deserves more
comments in its code.  I haven't yet gotten any feedback on that patch, and
hadn't bothered to polish it up before it becoming clear the code itself
would be taken in the form I wrote it.


Thanks,
Roland