minaco2 / distcc

Automatically exported from code.google.com/p/distcc
GNU General Public License v2.0
0 stars 0 forks source link

Gdb tests fail in pumped mode on Ubuntu 9.10 amd64 #61

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
distcc version is svn rev 712

$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1

$ uname -a
Linux cesar-laptop 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC
2010 x86_64 GNU/Linux

$ gdb --version
GNU gdb (GDB) 7.0.1-ubuntu

I'm trying to run tests in pumped mode and get gdb related tests fail:
$ make pump-maintainer-check

(see gdb_fail.log)

The temp dirs of failing cases could be found in gdb_cases.tar.gz. I have
no clue what is the cause. All the tests pass in non-pumped mode after a
small change (see http://code.google.com/p/distcc/issues/detail?id=60).

During testing distccd shipped with my distro has been shut down.

I'd be glad to provide any info you need to solve this issue.

Original issue reported on code.google.com by madkinder on 18 Feb 2010 at 10:35

Attachments:

GoogleCodeExporter commented 9 years ago
I think this is due to some newly introduced nondeterminism in gcc.
I suspect that adding -frandom-seed=0 to the gcc command lines would solve this 
problem.

Could you please try that and see if it works?

(For a proper fix, we should use -frandom-seed=<filename>, e.g. 
"-frandom-seed=$<" in
the Makefile, and there should be an autoconf configure check to see if gcc 
accepts
-frandom-seed.)

Original comment by fergus.h...@gmail.com on 18 Feb 2010 at 11:46

GoogleCodeExporter commented 9 years ago
No luck, it didn't help.
To perform a quick and dirty check I hardcoded this option into the testcase 
itself,
like this:

class Gdb_Case(CompileHello_Case):
    """Test that distcc generates correct debugging information."""

    def compiler(self):
        """Command for compiling and linking."""
        return _gcc + " -g -frandom-seed=0 ";

Then I run:
$ make pump-single-test TESTNAME=Gdb_Case

(see output in with.log)

Then I saw that gcc misses some input files so I reverted the testcase back and 
run
it again to make sure that it is desired behavior (see without.log). I guess it 
was.

We should look for another solution unless I performed tests properly.

Original comment by madkinder on 19 Feb 2010 at 7:21

Attachments:

GoogleCodeExporter commented 9 years ago
Running

cd Gdb_Case
objdump --disassemble -x -s link/testtmp > link/testtmp.objdump
0 fergus@fergus-warp:~/Downloads/Gdb_Case $ objdump --disassemble -x -s 
run/testtmp > 
run/testtmp.objdump
diff -u link/testtmp.objdump run/testtmp.objdump

gives the following output:

--- link/testtmp.objdump        2010-03-02 01:25:46.517754000 -0500
+++ run/testtmp.objdump 2010-03-02 01:25:52.970832000 -0500
@@ -1,6 +1,6 @@

-link/testtmp:     file format elf64-x86-64
-link/testtmp
+run/testtmp:     file format elf64-x86-64
+run/testtmp
 architecture: i386:x86-64, flags 0x00000112:
 EXEC_P, HAS_SYMS, D_PAGED
 start address 0x0000000000400440
@@ -119,8 +119,8 @@
  400264 00000000 02000000 06000000 0f000000  ................
 Contents of section .note.gnu.build-id:
  400274 04000000 14000000 03000000 474e5500  ............GNU.
- 400284 5ec6b0bf 29591e1c 768c1bc4 5baa01e9  ^...)Y..v...[...
- 400294 6def8149                             m..I            
+ 400284 0c2785b5 a3caa623 4137cca2 f5783cc5  .'.....#A7...x<.
+ 400294 e3888b75                             ...u            
 Contents of section .hash:
  400298 03000000 04000000 01000000 03000000  ................
  4002a8 00000000 00000000 00000000 00000000  ................

So it looks like the differences are all in the .note.gnu.build-id section.

A little bit of web searching pulls up this description:
http://fedoraproject.org/wiki/Releases/FeatureBuildId

In short gcc is now by default stamping the binary with an MD5 sum of 
information 
that includes the debug section.  This test is asserting that compiling, 
munging the 
debug info, linking, and then stripping gives the same result as compiling, 
linking 
and then stripping.  This is no longer the case with the default --build-id 
setting 
for gcc.  So the failure is a false negative.

To make the test work correctly, we should check to see if gcc accepts "--build-
id=0x12345678", and if so, pass that.  See the attached patch.

Can you please try out the attached patch and tell me if it solves the problem 
for 
you?

Original comment by fergus.h...@gmail.com on 2 Mar 2010 at 7:09

Attachments:

GoogleCodeExporter commented 9 years ago
I've gone ahead and committed the patch in SVN revision 735.

Original comment by fergus.h...@gmail.com on 16 Nov 2010 at 7:07