This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Gold] problem building linux kernel
This is an uninitialized-variable bug. Depenidng of whether KEEP_LEFT
or KEEP_RIGHT is set, we will propagate the left or right operand's
alignment. However, not all sub-classes of Expression return
alignment in Expression::value(). In particular,
Symbol_expression::value() does not and causes this expression to have
garbage alignment value:
init_per_cpu__gdt_page = gdt_page + __per_cpu_load;
Markus: Can you try initializing left_alignment and right_alignment to
zero around line 390 of expression.cc? That is a band-aid only to
test my theory.
I think the proper fix is to always return a proper alignment (0 if
none is required) in all sub-classes of Expression when a caller of
Expression::value() passes a pointer for alignment result.
-Doug
#define BINARY_EXPRESSION(NAME, OPERATOR, KEEP_LEFT, KEEP_RIGHT, IS_DIV, WARN) \
class Binary_ ## NAME : public Binary_expression \
{ \
public: \
Binary_ ## NAME(Expression* left, Expression* right) \
: Binary_expression(left, right) \
{ } \
\
uint64_t \
value(const Expression_eval_info* eei) \
{ \
Output_section* left_section; \
uint64_t left_alignment; \
uint64_t left = this->left_value(eei, &left_section, \
&left_alignment); \
Output_section* right_section; \
uint64_t right_alignment; \
uint64_t right = this->right_value(eei, &right_section, \
&right_alignment); \
if (KEEP_RIGHT && left_section == NULL && right_section != NULL) \
{ \
if (eei->result_section_pointer != NULL) \
*eei->result_section_pointer = right_section; \
if (eei->result_alignment_pointer != NULL) \
*eei->result_alignment_pointer = right_alignment; \
} \
else if (KEEP_LEFT \
&& left_section != NULL \
&& right_section == NULL) \
{ \
if (eei->result_section_pointer != NULL) \
*eei->result_section_pointer = left_section; \
if (eei->result_alignment_pointer != NULL) \
*eei->result_alignment_pointer = right_alignment; \
} \
On Thu, Nov 18, 2010 at 10:26 AM, Doug Kwan (éæå) <dougkwan@google.com> wrote:
> On Thu, Nov 18, 2010 at 7:38 AM, Ian Lance Taylor <iant@google.com> wrote:
>
>> Doug, I don't know what is going on, but there is clearly a 32-x-64
>> problem somewhere. ÂAll these values are sign extended from 32 bits to
>> 64 bits. ÂTry building gold with -m32.
>
> You're spot on. ÂBuilding gold with -m32 does the trick.
>
> Elf file type is EXEC (Executable file)
> Entry point 0x1000000
> There are 6 program headers, starting at offset 64
>
> Program Headers:
> ÂType      Offset  VirtAddr      PhysAddr
> FileSiz ÂMemSiz  Flg Align
> ÂLOAD Â Â Â Â Â 0x001000 0xffffffff81000000 0x0000000001000000
> 0x5bb000 0x5bb000 R E 0x5ffb20100
> ÂLOAD Â Â Â Â Â 0x5bc000 0xffffffff815bb000 0x00000000015bb000
> 0x0645a8 0x0645a8 RWE 0x5ffb20100
> ÂLOAD Â Â Â Â Â 0x621000 0xffffffffff600000 0x0000000001620000
> 0x000888 0x000888 R E 0x5ffb20100
> ÂLOAD Â Â Â Â Â 0x622000 0x0000000000000000 0x0000000001621000
> 0x011f80 0x011f80 RW Â0x5ffb20100
> ÂLOAD Â Â Â Â Â 0x634000 0xffffffff81633000 0x0000000001633000
> 0x0c3000 0x0c3000 RWE 0x5ffb20100
> ÂNOTE Â Â Â Â Â 0x462430 0xffffffff81461430 0x0000000001461430
> 0x000040 0x000040 Â Â 0x4
>
> I will look deeper and see what's wrong.
>
> -Doug
>