From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20372 invoked by alias); 15 May 2003 22:06:27 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20317 invoked from network); 15 May 2003 22:06:26 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.213.212) by sources.redhat.com with SMTP; 15 May 2003 22:06:26 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 1D038354C; Thu, 15 May 2003 15:06:25 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h4FM6Nu11992; Thu, 15 May 2003 15:06:23 -0700 Date: Thu, 15 May 2003 22:06:00 -0000 Message-Id: <200305152206.h4FM6Nu11992@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [branch patch] dwarf-frame.c support for .eh_frame_hdr In-Reply-To: Mark Kettenis's message of Thursday, 15 May 2003 23:49:16 +0200 <200305152149.h4FLnGHK000471@elgar.kettenis.dyndns.org> X-Windows: the joke that kills. X-SW-Source: 2003-05/txt/msg00262.txt.bz2 > 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