From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31161 invoked by alias); 1 Oct 2004 18:23:21 -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 31154 invoked from network); 1 Oct 2004 18:23:19 -0000 Received: from unknown (HELO skysamba) (81.195.20.213) by sourceware.org with SMTP; 1 Oct 2004 18:23:19 -0000 Received: from garrisonhq ([127.0.0.1]) by skysamba with esmtp (Exim 4.42) id 1CDS6U-0004c6-NW for gdb-patches@sources.redhat.com; Fri, 01 Oct 2004 22:26:02 +0400 Message-ID: <415DA139.6010309@mail.ru> Date: Fri, 01 Oct 2004 18:23:00 -0000 From: Igor Kovalenko User-Agent: Mozilla Thunderbird 0.6+ (X11/20040919) MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: Re: Patch: Handle relative paths in .debug_line References: <415B569E.2080805@mail.ru> <415B5898.1020203@mail.ru> In-Reply-To: <415B5898.1020203@mail.ru> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00021.txt.bz2 I'm willing to devote some time to this problem, as it prevents me from doing some necessary c++ debugging. So the question is what is currently more necessary to have this problem fixed: - Beat the testsuite into accepting one of available patches (e.g. by teaching the suite about dwarf2 case or teaching patches to pass the testsuite) - Have a test case for handling relative paths with dwarf2 Me wrote: > > Also I looked at regressions - this patch makes approximately the same > number > of failures as original relative paths patch. Test case gdb.base/unload.exp > might show the reason - there seems to be a problem in handling relative > paths > within regression testing scripts: > > Running ../../../gdb-dejagnu/gdb/testsuite/gdb.base/unload.exp ... > ERROR: couldn't open > "../../../gdb-dejagnu/gdb/testsuite/gdb.base/../../../gdb-dejagnu/gdb/testsuite/gdb.base/unloadshr.c": > > no such file or directory > FAIL: gdb.base/unload.exp: rerun to shared library breakpoint > The same holds for disassemble failures, I've not checked others yet. My failure list have: +FAIL: gdb.base/commands.exp: breakpoint in bp_deleted_in_command_test +FAIL: gdb.base/commands.exp: breakpoint in temporary_breakpoint_commands +FAIL: gdb.mi/mi-disassemble.exp: data-disassemble file, line assembly mixed +FAIL: gdb.mi/mi-disassemble.exp: data-disassemble range assembly mixed +FAIL: gdb.mi/mi-disassemble.exp: data-disassemble file, line, number assembly mixed +FAIL: gdb.mi/mi-disassemble.exp: data-disassemble file, line, number (zero lines) assembly mixed +FAIL: gdb.mi/mi-disassemble.exp: data-disassemble file, line, number (more than main lines) assembly mixed +FAIL: gdb.mi/mi-file.exp: request path info of current source file (basics.c) +FAIL: gdb.mi/mi2-disassemble.exp: data-disassemble file, line assembly mixed +FAIL: gdb.mi/mi2-disassemble.exp: data-disassemble range assembly mixed +FAIL: gdb.mi/mi2-disassemble.exp: data-disassemble file, line, number assembly mixed +FAIL: gdb.mi/mi2-disassemble.exp: data-disassemble file, line, number (zero lines) assembly mixed +FAIL: gdb.mi/mi2-disassemble.exp: data-disassemble file, line, number (more than main lines) assembly mixed +FAIL: gdb.mi/mi2-file.exp: request path info of current source file (basics.c) -- Kind regards, Igor V. Kovalenko