RE: vmlinux parse error 2.6.12.5

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

----Original Message----
>From: Nicolas Pitre
>Sent: 25 August 2005 14:38

[  I've Cc'd in the binutils list, because I think this is a real binutils
problem (albeit one that may only be documentable rather than directly
solvable).  If anyone reading from that list is familiar with
ldexp.c/exp_fold_tree(), could they please take a look at the last four
paragraphs of this post?  The context here is that we're trying to use
ASSERT to verify that at least one of the object files we are linking
together has a non-zero amount of data for a particular input section.  ]

> On Thu, 25 Aug 2005, Mirco Fuchs wrote:
> 
>> 
>> Hi,
>> 
>>>> I'm getting the following error when build for a Mainstone 2 with
>>>> 2.6.12.5 
>>>> 
>>>> /usr/local/arm-linux/bin/arm-linux-ld:arch/arm/kernel/vmlinux/lds:825:
>>>> parse error 
>>>> 
>>>> I'm using arm-linux-gcc 3.3.2 and ld 2.14.90.0.7
>> 
>>> Upgrade your binutils to at least 2.15.
>> 
>> I just compiled a 2.6.12 kernel for an arm target with arm-linux-gcc
>> 3.4.4 and binutils 2.16, but i still have the same problem.
> 
> Make sure your new binutils is properly installed and actually used.
> 

  Hmm, I'm having a problem with those ASSERTs as well.  I've got
binutils-2.15, and both the assertions fire unless I comment them out:

--------------------<example>--------------------
dk@mace /repository/armtools/merge/test-postmerge/armtools/linux>
/artimi/swtoo
ls/windows/bin/arm-linux-ld -EL  -p --no-undefined -X -T
arch/arm/kernel/vmlinu
x.lds.asm   -o .tmp_vmlinux1 -T arch/arm/kernel/vmlinux.lds.asm
arch/arm/kernel
/head.o arch/arm/kernel/init_task.o  init/built-in.o --start-group
usr/built-i
n.o  arch/arm/kernel/built-in.o arch/arm/mm/built-in.o
arch/arm/common/built-i
n.o  arch/arm/mach-pxa/built-in.o  arch/arm/nwfpe/built-in.o
kernel/built-in.o
  mm/built-in.o  fs/built-in.o  ipc/built-in.o  security/built-in.o
crypto/bui
lt-in.o  lib/lib.a  arch/arm/lib/lib.a  lib/built-in.o
arch/arm/lib/built-in.o
  drivers/built-in.o  sound/built-in.o  net/built-in.o --end-group -v -v
-Map m
ap.txt
GNU ld version 2.15
GNU ld version 2.15
/artimi/swtools/windows/bin/arm-linux-ld: missing CPU support

<    comment out first ASSERT directive    >

dk@mace /repository/armtools/merge/test-postmerge/armtools/linux>
/artimi/swtoo
ls/windows/bin/arm-linux-ld -EL  -p --no-undefined -X -T
arch/arm/kernel/vmlinu
x.lds.asm   -o .tmp_vmlinux1 -T arch/arm/kernel/vmlinux.lds.asm
arch/arm/kernel
/head.o arch/arm/kernel/init_task.o  init/built-in.o --start-group
usr/built-i
n.o  arch/arm/kernel/built-in.o arch/arm/mm/built-in.o
arch/arm/common/built-i
n.o  arch/arm/mach-pxa/built-in.o  arch/arm/nwfpe/built-in.o
kernel/built-in.o
  mm/built-in.o  fs/built-in.o  ipc/built-in.o  security/built-in.o
crypto/bui
lt-in.o  lib/lib.a  arch/arm/lib/lib.a  lib/built-in.o
arch/arm/lib/built-in.o
  drivers/built-in.o  sound/built-in.o  net/built-in.o --end-group -v -v
-Map m
ap.txt
GNU ld version 2.15
GNU ld version 2.15
/artimi/swtools/windows/bin/arm-linux-ld: no machine record defined
--------------------<example>--------------------

  If I comment them out, the link completes (well, actually my link is
currently failing with a few bad_udelays, but that's a side-issue), and I
can see from the map file that both the proc and arch info sections do in
fact contain real data:

--------------------<example>--------------------
                0xc001f8d0                _einittext = .
                0xc001f8d0                __proc_info_begin = .
 *(.proc.info)
 .proc.info     0xc001f8d0      0x210 arch/arm/mm/built-in.o
                0xc001fae0                __proc_info_end = .
                0xc001fae0                __arch_info_begin = .
 *(.arch.info)
 .arch.info     0xc001fae0       0x38 arch/arm/mach-pxa/built-in.o
                0xc001fae0                __mach_desc_ARMCORE
                0xc001fb18                __arch_info_end = .
--------------------<example>--------------------

  If I compare the map files, when the ASSERT triggers I see that the map
file ends immediately after the "Archive member included because of file
(symbol)" section, and before the "Memory Configuration" part of the map
output.

  ISTM that ld is evaluating the ASSERT directives after reading source
files, but _before_ doing any linking, meaning that no symbols are actually
defined at that point.  I haven't checked the souce code to find out, but
this would make sense: it's the same reason why you can't use symbols in
MEMORY directives (see
http://sources.redhat.com/ml/binutils/2004-03/msg00540.html and
http://sources.redhat.com/ml/binutils/2004-03/msg00571.html).

  There's nothing in the docs to suggest when the expression in the ASSERT
macro is evaluated, but I reckon it must be before the output file is opened
and symbols get their values assigned, and that would be consistent with the
point at which the map file is truncated.

  There is a testcase in the ld testsuite that uses the ASSERT macro.  It
looks like this:

---------------------<quote>---------------------
dk@mace /repository/gcc-build/arm/binutils-build> cat
/repository/armtools/binutils/ld/testsuite/ld-scripts/assert.t
SECTIONS
{
  .empty : {}
  ASSERT (!SIZEOF(.empty), "Empty is not empty")
}
---------------------<quote>---------------------

  If the proc and arch info were on their own in output sections, we could
test that, but attempting to use sizeof on the input sections like so:

---------------------<quote>---------------------
ASSERT (!SIZEOF(.proc.info), "missing CPU support")
ASSERT (!SIZEOF(.arch.info), "no machine record defined")
---------------------<quote>---------------------

produced the following result:

---------------------<snip!>---------------------
/artimi/swtools/windows/bin/arm-linux-ld: internal error
/repository/armtools/binutils-2.15/ld/ldexp.c 745
---------------------<snip!>---------------------

  It also failed in just the same way when I tried creating a couple of
dummy output sections just to get the size of the info: if I modify the
tailend of the linker script to look like this:

---------------------<quote>---------------------
        .stab 0 : { *(.stab) }
        .stabstr 0 : { *(.stabstr) }
        .stab.excl 0 : { *(.stab.excl) }
        .stab.exclstr 0 : { *(.stab.exclstr) }
        .stab.index 0 : { *(.stab.index) }
        .stab.indexstr 0 : { *(.stab.indexstr) }
        .comment 0 : { *(.comment) }
        .test.proc.info : {
                        *(.proc.info)
        }
        .test.arch.info : {
                        *(.arch.info)
        }
}

ASSERT (!SIZEOF(.test.proc.info), "missing CPU support")
ASSERT (!SIZEOF(.test.arch.info), "no machine record defined")
---------------------<quote>---------------------

I still see the assertion.  I'm not sure what causes it yet; the proximate
cause is that exp_fold_tree (in ldexp.c) gets passed a tree with an invalid
or unknown value in the type.node_class field, which causes it to hit the
default case of a switch and abort using the FAIL() macro.  I don't know yet
what's in that tree object or how valid it may be, if at all.

  I notice, however, that there is no "case etree_sizeof" in that switch.  I
was going to suggest that it was an accidental omission, but then it occurs
to me that we still have the same problem:   ASSERT is evaluated early, long
before symbols have values assigned to them, but also long before the input
sections have been placed in output sections, so I don't see how SIZEOF
could be usable in an ASSERT either.  I can only assume that the testcase
passes because the SIZEOF expression is not folded in the test case, for
some reason.

  I'm not sure yet how to test for the section size being zero, but I just
don't think ASSERT is up to the job.  It may or may not still be possible in
the linker script, or it may need to be done in the external build machinery
(e.g. objcopy out the section to a raw binary and test the file size, or
similary).


  For the moment, I recommend commenting out those lines, and checking
manually that you have proc and arch info in your final vmlinux image.

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