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
- From: Roland McGrath <roland at redhat dot com>
- To: Mark Kettenis <kettenis at chello dot nl>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 15 May 2003 15:06:23 -0700
- Subject: Re: [branch patch] dwarf-frame.c support for .eh_frame_hdr
> 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