This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
- From: "iains at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 23 Jan 2012 11:46:19 +0000
- Subject: [Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
- Auto-submitted: auto-generated
- References: <bug-51941-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941
--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> 2012-01-23 11:46:19 UTC ---
(In reply to comment #2)
> Created attachment 26424 [details]
> Candidate fix for the bug
>
> This candidate fix works for me on both x86_64-unknown-linux-gnu and
> x86_64-apple-darwin10 built as a cross compiler.
>
> The problem was that on darwin, we get an extra line
> .set L$set$31,LASF0-Lsection__debug_str
>
> and I am not sure why.
The reason for making the offsets absolute is limitations on what the native
tool-chain can handle in terms of generating/using relocs
(although there might well be other latent issues since there is no testing of
dwarf > 2 on darwin so far).
> I don't think we need to prevent the test from running on Darwin (because of it
> generating dwarf4) as, IIUC, we don't rely on anything released by Apple for
> this. We just scan the assembly output from cc1plus.
>
> Could some Darwin savvy people confirm that the fix works for them?
As a fix for the test-case this works for me (and, logically, there is no
reason to exclude darwin if the test works there).
We will have to deal with the other issues as and when we have dwarf > 2 on
Darwin.
(obviously the test-case is emitting incorrect assembler for darwin, since it
assumes that the target can assemble ELF-style named sections).