From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-46261-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 19343 invoked by alias); 22 Nov 2006 19:53:49 -0000
Received: (qmail 19334 invoked by uid 22791); 22 Nov 2006 19:53:48 -0000
X-Spam-Check-By: sourceware.org
Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Nov 2006 19:53:43 +0000
Received: (qmail 11853 invoked from network); 22 Nov 2006 19:53:41 -0000
Received: from unknown (HELO localhost) (jimb@127.0.0.2)   by mail.codesourcery.com with ESMTPA; 22 Nov 2006 19:53:41 -0000
To: gdb-patches@sourceware.org
Subject: Re: [rfc] Do not make up line information
References: <20061122154249.GA3884@nevyn.them.org>
From: Jim Blandy <jimb@codesourcery.com>
Date: Wed, 22 Nov 2006 19:53:00 -0000
In-Reply-To: <20061122154249.GA3884@nevyn.them.org> (Daniel Jacobowitz's message of "Wed, 22 Nov 2006 10:42:49 -0500")
Message-ID: <m33b8b6yvu.fsf@codesourcery.com>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2006-11/txt/msg00265.txt.bz2


Daniel Jacobowitz <drow@false.org> writes:
> We'll never return a line number for function "foo", because with modern
> debug info we'll have an end marker for that part of the line table,
> represented as an entry for line 0.  But if the code for foo_init has
> inlined code from any header file that foo doesn't have, we'll have another
> symtab sharing the same blockvector whose lowest PC value is after "bar".
> We'll select that as the "best match", since it's the closest thing
> following bar.  We'll subtract one from the line number (probably putting us
> on the start of an inline function definition) and report that as the
> line for bar.

Wow --- that's weird code.  Where did that alt->line - 1 come from?

If we can't find the original motivation, the change looks like an
obvious improvement to me.