From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11400 invoked by alias); 29 Jan 2008 18:38:02 -0000 Received: (qmail 11390 invoked by uid 22791); 29 Jan 2008 18:38:02 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.29.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 18:37:36 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id m0TIbXMr094690 for ; Tue, 29 Jan 2008 18:37:33 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m0TIbXE22302204 for ; Tue, 29 Jan 2008 19:37:33 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m0TIbW7e014283 for ; Tue, 29 Jan 2008 19:37:33 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m0TIbWsI014278; Tue, 29 Jan 2008 19:37:32 +0100 Message-Id: <200801291837.m0TIbWsI014278@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 29 Jan 2008 19:37:32 +0100 Subject: Re: [rfc] Make DWARF-2 "address size" explicit To: drow@false.org (Daniel Jacobowitz) Date: Tue, 29 Jan 2008 19:00:00 -0000 From: "Ulrich Weigand" Cc: jimb@codesourcery.com, gdb-patches@sourceware.org In-Reply-To: <20080128210757.GA19391@caradoc.them.org> from "Daniel Jacobowitz" at Jan 28, 2008 04:07:57 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00709.txt.bz2 Dan Jacobowitz wrote: > On Mon, Jan 28, 2008 at 09:52:32PM +0100, Ulrich Weigand wrote: > > When comparing all this with what GDB currently does, there is > > one obvious error: GDB does not take the FDE encoding into > > account *at all* when accessing the operand of DW_CFA_set_loc > > in the .eh_frame section. It looks like this was already noticed > > by Dan some time ago, but the associated patch: > > > > http://www.cygwin.com/ml/gdb-patches/2006-10/msg00063.html > > > > apparently was never applied. Dan, are you still planning on > > applying this patch? > > If you could look over that patch and tell me if it looks right, I'll > apply it. I had no way to test it with valid debug information. Your patch certainly looks right to me. I'm wondering about this comment, however: + /* Always apply the objfile offset. We can do this because + if the code used DW_EH_PE_absptr, it probably wasn't + relocatable, so the offset should be zero. */ + fs->pc += ANOFFSET (unit->objfile->section_offsets, + SECT_OFF_TEXT (unit->objfile)); I agree that we should always apply the objfile offset. In fact, even in the case of a DW_EH_PE_absptr in a relocatable object, it *still* should be right to apply the offset: in this case, there will be a relocation on the .eh_frame section that gets applied when loading it into memory. So if we'd read the value from the in-memory copy, it would be wrong to add any offset. However, we actually read the section contents via the symfile_relocate_debug_section routine, which -while it does apply relocations- assumes every section is located at its default offset. So to get actual addresses we still need to apply the section offset, right? Apart from that, just a cosmetic comment: I was wondering why you didn't simply add a back-link from struct dwarf2_cie to its containing struct comp_unit. Then you'd automatically have the CU available whereever you already have a CIE or FDE pointer, without having to add "unit" arguments to all those functions ... > > Apart from that, it would appear that the most logical size to > > use for target addresses in DWARF expression evaluation would > > be the target "void *" size for .eh_frame FDEs, and the value > > of the associated compilation unit's .debug_info address size > > header field value for .debug_frame FDEs (however, I'm not sure > > how to best determine that). > > DJ Delorie ran into this same mess on the GCC list a few days ago and > Ian had the helpful suggestion to just avoid the bits that depend on > the ambiguous "address size". If enough people do that, maybe it > won't matter what we pick... I think your choices sound correct. It's > hard for .debug_info, though, as there is no direct correlation or > dependency between the sections. Yes, unfortunately you cannot look up the CU that corresponds to the address range covered by the FDE, because to read that address range you already need to know the address size :-/ You could make a pass over all .debug_info CU headers in the whole objfile, and check whether they all agree on their address size value -- I think this should just about always be true, as even on those targets where GCC supports multiple address sizes (i.e. mips), they can only be changed via ABI-breaking options, so those should never be linked together into a single objfile. If they all *do* agree, then we have a number we can use ... Does this make sense? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com