This is the mail archive of the
mailing list for the binutils project.
cannot build mainline GCC with mainline binutils
- From: Bob Wilson <bwilson at tensilica dot com>
- To: binutils at sources dot redhat dot com
- Date: Mon, 29 Nov 2004 17:35:29 -0800
- Subject: cannot build mainline GCC with mainline binutils
- Organization: Tensilica, Inc.
I discovered a problem while trying to build mainline GCC with mainline binutils
for an xtensa-elf target. It looks like some of the recent comdat patches
require the assembler's DIFF_EXPR_OK macro to be defined. This is not true for
Xtensa or MIPS.
I'm seeing the problem when building libstdc++-v3/src/locale-inst.cc. The
generated assembly looks like this:
.size long_mangled_name, .-long_mangled_name
(The "long_mangled_name" here is:
The problem is the ".-long_mangled_name" expression in the .size directive.
This does not assemble unless DIFF_EXPR_OK is defined. (Either that or
something else is wrong in the Xtensa port of GAS, which is always a
possibility.) The error message is: "Error: operation combines symbols in
different segments". The data in the middle of the function apparently makes
the assembler think that "." is in a different segment than the start of the
I'm not sure how to resolve this. Some possibilities and questions:
* Perhaps GCC ought to be emitting .pushsection/.popsection around the data in
the middle of the function. I tried that out (by hand-editing the assembly
source) and it does indeed solve the problem.
* Why does DIFF_EXPR_OK have anything to do with the expression in a .size
directive? I thought DIFF_EXPR_OK was related to using PC-relative relocations,
and I don't think the assembler will allow a relocation in the ELF symbol table.
I.E., even if DIFF_EXPR_OK is defined, I think the assembler is resolving
this expression to a constant. Perhaps the expr() function ought to always
allow difference expressions, i.e., as if DIFF_EXPR_OK is defined, with the
check for valid difference expressions being handled when evaluating the "fix"es??
* Is there some other change that could be done in the assembler to handle this
case where a function body is broken up by some data in another section?
Any other thoughts or suggestions? I'm just not sure how to handle this one.