From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31805 invoked by alias); 4 Feb 2003 04:07:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31797 invoked from network); 4 Feb 2003 04:07:24 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by 172.16.49.205 with SMTP; 4 Feb 2003 04:07:24 -0000 Received: from [192.168.1.2] (HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.0.5) with ESMTP-TLS id 2640113; Mon, 03 Feb 2003 23:07:23 -0500 Date: Tue, 04 Feb 2003 04:07:00 -0000 From: Daniel Berlin To: Jim Blandy cc: Andrew Cagney , Daniel Jacobowitz , Mark Kettenis , "" Subject: Re: RFC: Variables in blocks of registers In-Reply-To: Message-ID: References: <200302011448.h11EmCkP001176@elgar.kettenis.dyndns.org> <3E3BEC50.9040104@redhat.com> <20030201171001.GB29662@nevyn.them.org> <3E3C3200.8070803@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-02/txt/msg00065.txt.bz2 On Mon, 3 Feb 2003, Jim Blandy wrote: > > Andrew Cagney writes: > > >> dwarf2 makes it possible to scatter a value across both memory and > > >> registers. It's been proposed that the `struct value' be augmented > > >> with something like `struct location' that knows how to find any > > >> sub component of a value. > > > However, right now GCC doesn't generate this. Probably because it > > > would kill us. > > > > I'm not so sure. In the past, GCC hasn't waited for GDB so I don't > > think that would be the reason now. > > I thought it had. A lot of the C++ stuff, for example; > DW_AT_MIPS_linkage_name; etc. > Yup. GCC has and does wait for GDB quite a bit, contrary to Andrew's assertion. There have been times when people get frustrated enough to give up waiting, it depends on the feature and the person who implemented it. Generally, I wait indefinitely to commit, and complain a lot. Others stew quietly, but give up waiting for GDB, and just commit it without waiting for gdb to catch up. If you'd rather me just do that, so you can consistently say that gcc doesn't wait for gdb, i'll happily do so. Just give me the word, and i'll go remove DW_AT_mips_linkage_name, for instance. It'll save a *large* amount of space in the C++ object files and binaries. There's other pieces of code already committed that are waiting for gdb too, a quick scan found this #if 0'd block in dwarf2out.c: #if 0 /* Disable this optimization for now; GDB wants to see two line notes at the beginning of a function so it can find the end of the prologue. */ /* Don't emit anything for redundant notes. Just updating the address doesn't accomplish anything, because we already assume that anything after the last address is this line. */ if (line_info->dw_line_num == current_line && line_info->dw_file_num == current_file) continue; #endif