From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-108696-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 25185 invoked by alias); 23 Dec 2013 23:17:22 -0000
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
Received: (qmail 25175 invoked by uid 89); 23 Dec 2013 23:17:22 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-ig0-f180.google.com
Received: from mail-ig0-f180.google.com (HELO mail-ig0-f180.google.com) (209.85.213.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 23 Dec 2013 23:17:21 +0000
Received: by mail-ig0-f180.google.com with SMTP id uq1so14383719igb.1        for <gdb-patches@sourceware.org>; Mon, 23 Dec 2013 15:17:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=1e100.net; s=20130820;        h=x-gm-message-state:mime-version:in-reply-to:references:date         :message-id:subject:from:to:cc:content-type;        bh=5m+70YZThFv2fKS1vvA1ry3hF8z8nGuTzQGcbJtEzPQ=;        b=bQ/CpOQcKRqgUmyTmo0n6BbhjgYGPAb/OfKTKbn4n3FP0Js9Mq/luYs+iun4RErRG2         /vVuc/p26Jv79DFV+VIQtDIAClAj3iwzEkYF+n6Iyx4ilBTfdQaB+2pYZ8cQbdWDqTAT         RdiTHNMJbzkzK5ZLzfVmSm8dhH/u2eNlomPJuLPejKkUYkR68iy4IviwJxncduK8f39q         s0ZM3HRK0cqYRU3kU6euzpyTlNUbYYqntdxDvjJDw4eYCFu6amElgoweMINr5Hr/ktgM         b18pJoteR3gU+x5GuZbqq/rhIjo7GwROm2KebGPoxtOtaeYbi49UzEVVUiQ/kV0aWfpa         6XPg==
X-Gm-Message-State: ALoCoQl0pRkm8I1AAEDhN8sGw37vnnCkwnfbCjY6cbE502kkrPiZhmbesed93eZN1L+DyrlZPNBEmmxaZseqlujGF9xOmar8DVGTb5CUboHK0z9h2ETf+MFeSOoQboJEVJDSkbQpzN7XXokQA9WwF0VwNEoj7ljKpYfHNxYLR4fqzASawJ7ATZm8U18kWNm9KMLS4FDrFI0SgsEn4t6Ts6jz0m3UtYBe6Q==
MIME-Version: 1.0
X-Received: by 10.42.48.202 with SMTP id t10mr18786229icf.9.1387840639841; Mon, 23 Dec 2013 15:17:19 -0800 (PST)
Received: by 10.64.18.200 with HTTP; Mon, 23 Dec 2013 15:17:19 -0800 (PST)
In-Reply-To: <87haa3ie0r.fsf@fleche.redhat.com>
References: <CAEG7qUxE2eiqv0nGe6=UJ9NpsgCAf0WtG2VPtiJpczaWatxwmg@mail.gmail.com>	<87haa3ie0r.fsf@fleche.redhat.com>
Date: Mon, 23 Dec 2013 23:17:00 -0000
Message-ID: <CAEG7qUzqKpfakRh+5rD_4B+HDajdhRxsLqgxz5C=UyDGyLoOHA@mail.gmail.com>
Subject: Re: [Patch] Use "<unknown>" instead of NULL when a symbol isn't found
From: Sterling Augustine <saugustine@google.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches <gdb-patches@sourceware.org>, Keith Seitz <keiths@redhat.com>
Content-Type: text/plain; charset=UTF-8
X-SW-Source: 2013-12/txt/msg00900.txt.bz2

On Fri, Dec 20, 2013 at 10:16 AM, Tom Tromey <tromey@redhat.com> wrote:
> I wonder whether some correction or workaround is required elsewhere.

There are various parts of linepec.c that assume that this field is
never null, either by assertion or by dereferencing it. Any other
workaround (at least for the case I'm dealing with) would probably
just print an error message.

>
> Sterling> The following patch simply assigns the symbol name as "<unknown>"
> Sterling> instead of NULL, allowing the debugger to make forward progress in the
> Sterling> face of an erroneous debug line table entry.
>
> You didn't say whether you regression-tested this; but assuming so, it
> is ok.

I did run regressions and it didn't introduce any new ones.

Thanks. Committed as posted.