Message ID | 20180619090024.c2yqabvk6oujs6dm@localhost.localdomain |
---|---|
State | New, archived |
Headers |
Received: (qmail 16284 invoked by alias); 19 Jun 2018 09:03:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@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 Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 130333 invoked by uid 89); 19 Jun 2018 09:00:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.2 spammy=Contents, H*MI:localhost X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Jun 2018 09:00:54 +0000 Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 816B2AF95 for <gdb-patches@sourceware.org>; Tue, 19 Jun 2018 09:00:33 +0000 (UTC) Date: Tue, 19 Jun 2018 11:00:32 +0200 From: Tom de Vries <tdevries@suse.de> To: gdb-patches@sourceware.org Subject: [PATCH][gdb/testsuite] Fix error message test in dw2-error.exp Message-ID: <20180619090024.c2yqabvk6oujs6dm@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170912 (1.9.0) X-IsSubscribed: yes |
Commit Message
Tom de Vries
June 19, 2018, 9 a.m. UTC
Hi, the executable used in dw2-error.exp is compiled from a .s that was generated with dwarf2 debug information but has been hand-edited to set the version in the compilation unit header to 0x99: ... .Ldebug_info0: .long 0x4e # Length of Compilation Unit Info .value 0x99 # DWARF version number .long .Ldebug_abbrev0 # Offset Into Abbrev. Section ... Consequently, dwarf2read.c:read_comp_unit_head() interprets the compilation unit header as dwarf5, which starts with fields unit_length (4 or 12 byte unsigned), version (uhalf), and unit_type (ubyte). So, the unit_type field is initialized from the first byte of .Ldebug_abbrev0 offset. Using objdump, we find that the value of that byte is 0x64. ... Contents of section .debug_info: ... 00c0 00450000 0001804e 00000099 00640000 .E.....N.....d.. ... And indeed gdb errors out accordingly (note: 0x64 == 100): ... (gdb) file outputs/gdb.dwarf2/dw2-error/dw2-error Reading symbols from outputs/gdb.dwarf2/dw2-error/dw2-error... Dwarf Error: wrong unit_type in compilation unit header (is 100, should be 1 or 2) [in module outputs/gdb.dwarf2/dw2-error/dw2-error] (no debugging symbols found)...done. ... The test fails however because it expects the error message to contain 0 instead of the 100 we're seeing. This patch fixes the failure by allowing any value for the unit_type in the error message. Tested on x86_64-linux. OK for trunk? Thanks, - Tom [gdb/testsuite] Fix error message test in dw2-error.exp 2018-06-19 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-error.exp: Allowing any value for the unit_type in the "wrong unit_type in compilation unit header" error message. --- gdb/testsuite/gdb.dwarf2/dw2-error.exp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 06/19/2018 11:00 AM, Tom de Vries wrote: > Hi, > > the executable used in dw2-error.exp is compiled from a .s that was generated > with dwarf2 debug information but has been hand-edited to set the version in > the compilation unit header to 0x99: > ... > .Ldebug_info0: > .long 0x4e # Length of Compilation Unit Info > .value 0x99 # DWARF version number > .long .Ldebug_abbrev0 # Offset Into Abbrev. Section > ... > > Consequently, dwarf2read.c:read_comp_unit_head() interprets the compilation > unit header as dwarf5, which starts with fields unit_length (4 or 12 byte > unsigned), version (uhalf), and unit_type (ubyte). So, the unit_type > field is initialized from the first byte of .Ldebug_abbrev0 offset. > > Using objdump, we find that the value of that byte is 0x64. > ... > Contents of section .debug_info: > ... > 00c0 00450000 0001804e 00000099 00640000 .E.....N.....d.. > ... > > And indeed gdb errors out accordingly (note: 0x64 == 100): > ... > (gdb) file outputs/gdb.dwarf2/dw2-error/dw2-error > Reading symbols from outputs/gdb.dwarf2/dw2-error/dw2-error... > Dwarf Error: wrong unit_type in compilation unit header > (is 100, should be 1 or 2) > [in module outputs/gdb.dwarf2/dw2-error/dw2-error] > (no debugging symbols found)...done. > ... > > The test fails however because it expects the error message to contain 0 > instead of the 100 we're seeing. > > This patch fixes the failure by allowing any value for the unit_type in the > error message. > > Tested on x86_64-linux. > > OK for trunk? > > Thanks, > - Tom > > [gdb/testsuite] Fix error message test in dw2-error.exp > > 2018-06-19 Tom de Vries <tdevries@suse.de> > > * gdb.dwarf2/dw2-error.exp: Allowing any value for the unit_type in > the "wrong unit_type in compilation unit header" error message. > > --- > gdb/testsuite/gdb.dwarf2/dw2-error.exp | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-error.exp b/gdb/testsuite/gdb.dwarf2/dw2-error.exp > index e22667dea5..441e0f8db5 100644 > --- a/gdb/testsuite/gdb.dwarf2/dw2-error.exp > +++ b/gdb/testsuite/gdb.dwarf2/dw2-error.exp > @@ -41,7 +41,7 @@ gdb_test_no_output "set breakpoint pending off" > > # First test that reading symbols fails. > gdb_test "file $binfile" \ > - {Reading symbols.*Dwarf Error: wrong unit_type in compilation unit header \(is 0, should be 1 or 2\).*} \ > + {Reading symbols.*Dwarf Error: wrong unit_type in compilation unit header \(is [0-9]+, should be 1 or 2\).*} \ > "file $testfile" > > # Now check that we can still break given the minimal symbol. >
On 06/19/2018 10:00 AM, Tom de Vries wrote: > the executable used in dw2-error.exp is compiled from a .s that was generated > with dwarf2 debug information but has been hand-edited to set the version in > the compilation unit header to 0x99: > ... > .Ldebug_info0: > .long 0x4e # Length of Compilation Unit Info > .value 0x99 # DWARF version number > .long .Ldebug_abbrev0 # Offset Into Abbrev. Section > ... > > Consequently, dwarf2read.c:read_comp_unit_head() interprets the compilation > unit header as dwarf5, That right there looks like the real bug to me. I went looking for the history behind the testcase, and got surprised that the testcase is expecting that "wrong unit_type in compilation unit header" error instead of the same error that had been reported in the original bug report at <https://sourceware.org/bugzilla/show_bug.cgi?id=14931>: ~~~~~ Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module ....build/gdb/gdb] ~~~~~ read_and_check_comp_unit_head calls error_check_comp_unit_head after calling read_comp_unit_head, and thus AFAICT error_check_comp_unit_head would error out with the "wrong version" error, the one that had been reported in the original bug report. That seems like a much better error to me. static void error_check_comp_unit_head (struct dwarf2_per_objfile *dwarf2_per_objfile, struct comp_unit_head *header, struct dwarf2_section_info *section, struct dwarf2_section_info *abbrev_section) { const char *filename = get_section_file_name (section); if (header->version < 2 || header->version > 5) error (_("Dwarf Error: wrong version in compilation unit header " "(is %d, should be 2, 3, 4 or 5) [in module %s]"), header->version, filename); So it seems to me that read_comp_unit_head shouldn't be trying to interpret contents of a dwarf version that gdb doesn't understand. Seems like that error_check_comp_unit_head version check is too late? How about moving it into read_and_check_comp_unit_head? Of course, the testcase would then be adjusted to expect the new message, and it would expect 153/0x99 exactly instead of any number, which ensures that gdb reads and prints the version number correctly. Thanks, Pedro Alves > which starts with fields unit_length (4 or 12 byte > unsigned), version (uhalf), and unit_type (ubyte). So, the unit_type > field is initialized from the first byte of .Ldebug_abbrev0 offset. > > Using objdump, we find that the value of that byte is 0x64. > ... > Contents of section .debug_info: > ... > 00c0 00450000 0001804e 00000099 00640000 .E.....N.....d.. > ... > > And indeed gdb errors out accordingly (note: 0x64 == 100): > ... > (gdb) file outputs/gdb.dwarf2/dw2-error/dw2-error > Reading symbols from outputs/gdb.dwarf2/dw2-error/dw2-error... > Dwarf Error: wrong unit_type in compilation unit header > (is 100, should be 1 or 2) > [in module outputs/gdb.dwarf2/dw2-error/dw2-error] > (no debugging symbols found)...done. > ... > > The test fails however because it expects the error message to contain 0 > instead of the 100 we're seeing. > > This patch fixes the failure by allowing any value for the unit_type in the > error message.
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-error.exp b/gdb/testsuite/gdb.dwarf2/dw2-error.exp index e22667dea5..441e0f8db5 100644 --- a/gdb/testsuite/gdb.dwarf2/dw2-error.exp +++ b/gdb/testsuite/gdb.dwarf2/dw2-error.exp @@ -41,7 +41,7 @@ gdb_test_no_output "set breakpoint pending off" # First test that reading symbols fails. gdb_test "file $binfile" \ - {Reading symbols.*Dwarf Error: wrong unit_type in compilation unit header \(is 0, should be 1 or 2\).*} \ + {Reading symbols.*Dwarf Error: wrong unit_type in compilation unit header \(is [0-9]+, should be 1 or 2\).*} \ "file $testfile" # Now check that we can still break given the minimal symbol.