Opened 17 months ago

Closed 17 months ago

Last modified 14 months ago

#4641 closed task (fixed)

ICA: gcc compilers (c++, gcc, cc1, cc1plus, ...) differ between first and second build

Reported by: Bruce Dubbs Owned by: lfs-book
Priority: normal Milestone: 10.0
Component: Book Version: SVN
Severity: normal Keywords:
Cc:

Description

Using objdump -d, it is found that the assembly code differ between first and second build (different use of register, use of different opcodes, ...). I suspect it has something to do with LTO, which would be applied on second pass and not on first, but its highly speculative.

Solution None yet... (any idea welcome!)

Change History (12)

comment:1 by Bruce Dubbs, 17 months ago

From pierre.labastie:

Possible solution

Do a 3-stage bootstrap for GCC. (removing --disable-bootstrap).

comment:2 by Bruce Dubbs, 17 months ago

From pierre.labastie:

Or build BLFS GCC as soon as possible (with or without bootstrap). But I think we'd rather avoid bootstrapping. Building gcc three times is already rather time consuming.

Thinking more about this: if nothing else, try a 2-stage bootstrap. Maybe it is enough. Those are just random thoughts though. I'm building a 2-stage ICA saving build directories of gcc. Hopefully, something should emerge from the comparison of the build directories.

comment:3 by Bruce Dubbs, 17 months ago

From pierre.labastie:

I've been able to set up an example for the gcc differences, using one of the affected files, which is spellcheck.o. On a finished lfs, cd /sources and unpack gcc, cd to the unpacked tree, then:

mkdir build1 && cd build1
CC=/tools/bin/gcc                     \
CXX=/tools/bin/g++                    \
../configure --prefix=/usr            \
             --enable-languages=c,c++ \
             --disable-multilib       \
             --disable-bootstrap      \
             --with-system-zlib
make -j4 all-build
make -j4 configure-host
cd gcc
make -j4 c-family/c-spellcheck.o
cd ../..
mkdir build2 && cd build2
../configure --prefix=/usr  
#... then the same thing again in build2 without setting CC and CXX

On my machine the produced .o files are different. As can be seen by diffing the output of objdump -d.

comment:4 by Bruce Dubbs, 17 months ago

From pierre.labastie:

The problem is the following: the header files which are included, are not the same in each case.

The reason is that the search directory order is not the same, because for /tools/bin/g++, /usr/include is first, while for g++, it comes after /usr/include/c++/9.3.0. And somehow, with this different order, one file is included in the second case, which is not included in the first, containing a lot of use instructions. I guess this is the reason why the generated code is not the same (some different types used).

Solution Use -idirafter instead of -isystem in the specs file. That puts /usr/include at the end of the search. This solves the above problem, and headers for programs which are only in chapter 6 can be found in /usr/include. For those which are in chapter 5 too, /tools/include will be used instead. But this is not a problem, since those headers are the same.

comment:5 by Bruce Dubbs, 17 months ago

From pierre.labastie:

The -idirafter solution is not totally satisfactory: I happen to have build on two different distros, and one of them generated gcc-pass2 with intl support from glibc, while the other not.

But with -idirafter, the glibc headers from /tools are used instead of those from /usr. Those in /usr do have intl support, but not those in /tools. So some programs are slightly different between first pass (using /tools) and second pass (using /usr).

in reply to:  1 comment:6 by Pierre Labastie, 17 months ago

Replying to bdubbs:

From pierre.labastie:

Possible solution

Do a 3-stage bootstrap for GCC. (removing --disable-bootstrap).

This solution is proposed by xry111 (author lost when splitting the original ticket)

in reply to:  5 comment:7 by Pierre Labastie, 17 months ago

Replying to bdubbs:

From pierre.labastie:

The -idirafter solution is not totally satisfactory: I happen to have build on two different distros, and one of them generated gcc-pass2 with intl support from glibc, while the other not.

But with -idirafter, the glibc headers from /tools are used instead of those from /usr. Those in /usr do have intl support, but not those in /tools. So some programs are slightly different between first pass (using /tools) and second pass (using /usr).

This diagnostic is wrong. There are differences in gcov, but they are the same whether using -idirafter or -isystem (I cannot edit/remove this comment since I do not own it)

comment:8 by Bruce Dubbs, 17 months ago

In comment 3 above, I note that we build gcc differently in chapter 5 and chapter 6.

In Chapter 5 we build mpfr, gmp, and mpc as a part of gcc. In Chapter 6 they are separate external libraries.

In Chapter 5, /tools is embedded in the gcc executable. In Chapter 6, is is /usr.

It does not surprise me that files built with tools are slightly different from those build with Chapter 6 gcc. We do not have any instances of mis-compiliation that I know about.

Perhaps we should just leave this as wontfix.

comment:9 by Pierre Labastie, 17 months ago

I have saved the "build" directory for each ICA build of gcc. With the -idirafter switch, there are no differences in the .o or .a files. So it is rather clean? and I think we should make the change in the book (*). But still there are differences in gcov...

Looking at the link command for gcov, it is found that it links with in-tree .a or .o files, but uses the -static-libgcc and -static-libstdc++ flags. So I suspect it links against the libstdc++.a and libgcc.a from /tools on first iteration, while it links afainst the ones in /usr on 2nd and 3rd.

Let's try a diff of those libraries.

(*) Bruce also thinks that it is educational to have -idirafter (private communication)

Version 0, edited 17 months ago by Pierre Labastie (next)

comment:10 by Pierre Labastie, 17 months ago

Hmm, nothing useful found. I've committed the change to -idirafter at r11819. Will try once more. Leaving open for now.

comment:11 by Pierre Labastie, 17 months ago

Resolution: fixed
Status: newclosed

Closing. I do not know what to do more. gcov is not a critical part of the system anyway. If anybody wants to try, my host is debian 8 (purposedly old). And gettext is not installed... Closing as fixed, because only gcov is still affected, and not always.

comment:12 by Bruce Dubbs, 14 months ago

Milestone: 9.210.0

Milestone renamed

Note: See TracTickets for help on using tickets.