RE: vmlinux parse error 2.6.12.5

["Dave Korn" <dave dot korn at artimi dot com>]

----Original Message----
>From: Alan Modra
>Sent: 26 August 2005 01:37

> After this patch
> 
>   ASSERT (ADDR (nonexistent) == 0, "don't be silly")
>   ASSERT (ADDR (nonexistent) != 0, "don't be silly")
>   ASSERT (SIZEOF (nonexistent) != 0, "don't be silly")
> 
> all give one "don't be silly" each and a link failure, while
> 
>   ASSERT (SIZEOF (nonexistent) == 0, "don't be silly")
> 
> passes.
> 
> 	* ldexp.c (fold_name <SIZEOF>): Return 0 for non-existent section.
> 	(exp_fold_tree_1): Print assert message only in final stage of
> 	linking.  Trigger assertion failure if expression cannot be
> 	evaluated.

  I've applied your patch, but it still doesn't help me.  Even when
expld.phase == lang_final_phase_enum (or allocation_done in my case, because
I'm using stock 2.15 source, the difference between two symbols comes out as
zero.  That's because (extract from my debugging printf's here:)

--------------------------<snip!>--------------------------
valid assert subtract: (__proc_info_end - __proc_info_begin)
left operand __proc_info_end Val $0001e000 name '(null)' valid, section
.init/bfd .init
right operand __proc_info_begin Val $0001e000 name '(null)' valid, section
.init/bfd .init
Val $00000000 name '(null)' valid, section *ABS*/bfd *ABS*
Operands after folding: lhs: __proc_info_end rhs: __proc_info_begin

valid assert subtract: (__arch_info_end - __arch_info_begin)
left operand __arch_info_end Val $0001e000 name '(null)' valid, section
.init/bfd .init
right operand __arch_info_begin Val $0001e000 name '(null)' valid, section
.init/bfd .init
Val $00000000 name '(null)' valid, section *ABS*/bfd *ABS*
Operands after folding: lhs: __arch_info_end rhs: __arch_info_begin
--------------------------<snip!>--------------------------

  To get that output, I inserted the following code:

        etree_type *expr = tree->assert_s.child;
            if ((expr->type.node_class == etree_binary) &&
(expr->type.node_code == '-'))
            {
                fprintf (outferr, "valid assert subtract: ");
                exp_print_tree (expr);
                fprintf (outferr, "\n");

                fprintf (outferr, "left operand ");
                exp_print_tree (expr->binary.lhs);
                result = exp_fold_tree (expr->binary.lhs,
                    current_section, allocation_done, dot, dotp);
                fprintf (outferr, " Val $%08x name '%s' %svalid, section
%s/bfd %s\n",
                    result.value, result.str, result.valid_p ? "" : "in", 
                    result.section->name,
result.section->bfd_section->name);

                fprintf (outferr, "right operand ");
                exp_print_tree (expr->binary.rhs);
                result = exp_fold_tree (expr->binary.rhs,
                                    current_section, allocation_done, dot,
dotp);
                fprintf (outferr, " Val $%08x name '%s' %svalid, section
%s/bfd %s\n",
                    result.value, result.str, result.valid_p ? "" : "in", 
                    result.section->name,
result.section->bfd_section->name);
                bugon = 1;
            }
        }

just before "if (expld.phase == lang_final_phase_enum &&
!expld.result.value)" in your patch.  (I wanted to be sure that calling
exp_fold_tree on the operands of the subtract didn't fold them from symbol
refs down to constants at an early time before they got their final values).
So they certainly appear to have equal values at the time the assert is
evaluated.  However, if I remove the %F from the einfo call, so that the
linker doesn't abort after the assert fires, I see from the map output 

                0xc001f88c                __proc_info_begin = .
 *(.proc.info)
 .proc.info     0xc001f88c      0x210 arch/arm/mm/built-in.o
                0xc001fa9c                __proc_info_end = .
                0xc001fa9c                __arch_info_begin = .
 *(.arch.info)
 .arch.info     0xc001fa9c       0x38 arch/arm/mach-pxa/built-in.o
                0xc001fa9c                __mach_desc_ARMCORE
                0xc001fad4                __arch_info_end = .

that they do actually get assigned different values.  But not until later on
than the time at which the assert is evaluated.  I know where that value of
0x1e000 that they evaluate to comes from, as well: it's the size of the
eventual output section into which they're going to be placed:

.init           0xc0008000    0x1e000


  Does that make _any_ sense?  

[  As to that crash, that's down to print_assignment not expecting to be fed
assert etrees and so calling exp_fold_tree on assignment->exp->assign.src
without first checking assignment->exp->type.node_class actually is an
assignment; it's already fixed in mainline.  ]


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....