RE: vmlinux parse error 2.6.12.5

RE: vmlinux parse error 2.6.12.5

[Dave Korn]

----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....

RE: vmlinux parse error 2.6.12.5

[Nicolas Pitre]

On Thu, 25 Aug 2005, Dave Korn wrote:

>   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).

I don't know about your setup but ...

I am using binutils version 2.15 from a build of crosstools:

/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/bin/arm-softfloat-linux-gnu-ld -v
GNU ld version 2.15

Compiling the current Linux kernel version 2.6.13-rc7 for Mainstone:

  [...]
  LD      init/built-in.o
  LD      .tmp_vmlinux1
  KSYM    .tmp_kallsyms1.S
  AS      .tmp_kallsyms1.o
  LD      .tmp_vmlinux2
  KSYM    .tmp_kallsyms2.S
  AS      .tmp_kallsyms2.o
  LD      vmlinux
  SYSMAP  System.map
  SYSMAP  .tmp_System.map
  OBJCOPY arch/arm/boot/Image
  Kernel: arch/arm/boot/Image is ready

Now, editing arch/arm/mach-pxa/mainstone.c and commenting out the whole 
MACHINE_START record at the bottom of the file and recompiling:

  [...]
  LD      init/built-in.o
  LD      .tmp_vmlinux1
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/bin/arm-softfloat-linux-gnu-ld:
 no machine record defined
make: *** [.tmp_vmlinux1] Error 1

So in this case everything works as expected for me at least.  Of course 
uncommenting the machine record in arch/arm/mach-pxa/mainstone.c results 
in a compiling again kernel.  And given the time the ASSERT has been 
present in the kernel tree it certainly must have worked fine for most 
people (and for those who had the problem then moving to binutils >= 
2.15 seemed to have done some good too).


Nicolas

RE: vmlinux parse error 2.6.12.5

[Dave Korn]

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

> On Thu, 25 Aug 2005, Dave Korn wrote:
> 
>>   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).
> 
> I don't know about your setup but ...

  Kernel 2.6.12.5, Binutils 2.15, Gcc 3.3.3, armcore target.

> So in this case everything works as expected for me at least.  Of course
> uncommenting the machine record in arch/arm/mach-pxa/mainstone.c results
> in a compiling again kernel.  

  That is very strange then.  I've been using binutils 2.15 all along.  I
didn't see this problem building 2.6.7, but it appeared when I tried moving
up to 2.6.12.5, without changing the toolchain in any way at all.

  Nonetheless, I still don't see _how_ it could possibly work, given the
known facts about the order in which ld does things.

> And given the time the ASSERT has been
> present in the kernel tree 

  How long _has_ the ASSERT been present?  It wasn't in 2.6.7.  As far as I
can see (assuming the file dates at
http://www.kernel.org/pub/linux/kernel/v2.6/ are actually correct and
more-or-less when the versions were released), that implies that it cannot
have been there any earlier than june last year.  It may have only been
present for a few versions and then be working again in 2.6.13.x

> it certainly must have worked fine for most
> people (and for those who had the problem then moving to binutils >=
> 2.15 seemed to have done some good too).

  Hmm, still hasn't helped me any.  Very strange.

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

Re: vmlinux parse error 2.6.12.5

[Alan Modra]

On Thu, Aug 25, 2005 at 04:22:28PM +0100, Dave Korn wrote:
>   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>---------------------

You can't reference input sections.  The arg of SIZEOF, ADDR, LOADADDR
is always an output section.  So you are in fact referencing a
non-existent output section.

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

I'm not sure why 2.15 is giving you this.  I know we've fixed a number
of bugs relating to non-existent output sections, and a bug in printing
assert statements if -Map is requested.

> 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

No, ASSERT is evaluated at various stages of the link process.  Which is
probably not the right thing to do, as it means multiple messages can be
emitted.  We also don't fail the assertion if the expression can't be
evaluated for some reason.  I think that ought to be fixed too.

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.

Index: ld/ldexp.c
===================================================================
RCS file: /cvs/src/src/ld/ldexp.c,v
retrieving revision 1.54
diff -u -p -r1.54 ldexp.c
--- ld/ldexp.c	5 Aug 2005 13:52:13 -0000	1.54
+++ ld/ldexp.c	26 Aug 2005 00:15:11 -0000
@@ -590,7 +590,9 @@ fold_name (etree_type *tree)
 	  lang_output_section_statement_type *os;
 
 	  os = lang_output_section_find (tree->name.name);
-	  if (os != NULL && os->processed > 0)
+	  if (os == NULL)
+	    new_abs (0);
+	  else if (os->processed > 0)
 	    new_abs (os->bfd_section->size / opb);
 	}
       break;
@@ -655,15 +657,8 @@ exp_fold_tree_1 (etree_type *tree)
 
     case etree_assert:
       exp_fold_tree_1 (tree->assert_s.child);
-      if (expld.result.valid_p)
-	{
-	  if (expld.phase == lang_mark_phase_enum)
-	    /* We don't care if assert fails or not when we are just
-	       marking if a section is used or not.  */
-	    expld.result.value = 1;
-	  else if (!expld.result.value)
-	    einfo ("%X%P: %s\n", tree->assert_s.message);
-	}
+      if (expld.phase == lang_final_phase_enum && !expld.result.value)
+	einfo ("%X%P: %s\n", tree->assert_s.message);
       break;
 
     case etree_unary:

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

RE: vmlinux parse error 2.6.12.5

[Dave Korn]

----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....

Re: vmlinux parse error 2.6.12.5

[Jared Hulbert]

>   How long _has_ the ASSERT been present?  It wasn't in 2.6.7.  As far as I
> can see (assuming the file dates at
> http://www.kernel.org/pub/linux/kernel/v2.6/ are actually correct and
> more-or-less when the versions were released), that implies that it cannot
> have been there any earlier than june last year.  It may have only been
> present for a few versions and then be working again in 2.6.13.x

It is in 2.6.12 but not 2.6.11.12 the file to look at is
arch/arm/kernel/vmlinux.lds.S

> > it certainly must have worked fine for most
> > people (and for those who had the problem then moving to binutils >=
> > 2.15 seemed to have done some good too).
> 
>   Hmm, still hasn't helped me any.  Very strange.

Warning!  Possibly really dumb statements and questions follow. 
Proceed with caution:

I don't understand this.  The ld script starts as a .S file which is
run through gcc to preprocess it into vmlinux.lds.  Shouldn't the
ASSERT's be triggered there and not when ld goes to work with the
.lds?  Is it possible this a gcc version problem rather than a bintool
problem?

RE: vmlinux parse error 2.6.12.5

[Dave Korn]

----Original Message----
>From: Jared Hulbert
>Sent: 26 August 2005 17:19

>>   How long _has_ the ASSERT been present?  It wasn't in 2.6.7.  As far

> It is in 2.6.12 but not 2.6.11.12 the file to look at is
> arch/arm/kernel/vmlinux.lds.S

  Thank you; that means that the assert has only been there for a couple of
months and it's entirely possible that the problem is real and I'm just one
of the first to be tripped up by it, rather than that it's been working fine
for everyone for ages ....

> Warning!  Possibly really dumb statements and questions follow.

  There's no such thing as a dumb question!  The only dumb thing is thinking
you already know instead of asking or otherwise finding out!

> Proceed with caution:
> 
> I don't understand this.  The ld script starts as a .S file which is
> run through gcc to preprocess it into vmlinux.lds.  Shouldn't the
> ASSERT's be triggered there and not when ld goes to work with the
> .lds?  

  Nope, because a) 'ASSERT' is not the same thing as the C language
'assert'.  Also, b) the script file is only being preprocessed (using gcc's
-E flag), not compiled.  Also, c) assert is a run-time check, not a
compile-time check.

> Is it possible this a gcc version problem rather than a bintool
> problem?

  So for those three reasons, no; ASSERT is just a text string that means
nothing to the preprocessor and is passed through unaltered to the output
file, where it eventually ends up being fed to ld, which does interpret it
and perform the test.


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

RE: vmlinux parse error 2.6.12.5

[Dave Korn]

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



> No, ASSERT is evaluated at various stages of the link process.  Which is
> probably not the right thing to do, as it means multiple messages can be
> emitted.  We also don't fail the assertion if the expression can't be
> evaluated for some reason.  I think that ought to be fixed too.

  Hmm.

  ASSERTs are stored as lang_statement_union_type objects, with the type
equal to lang_assignment_statement_enum; IOW, they are stored as a kind of
bogus assignment statement.

  This means that they are evaluated (during final phase) by
lang_do_assignments_1, in the same loop that actually performs the work of
assigning values to all symbols.

  Doesn't this mean that lang_do_assignments_1 could perhaps be processing
an ASSERT _before_ it processes the real assignment statement that gives
that symbol its correct value?  Given the correct ordering of statements?



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

Re: vmlinux parse error 2.6.12.5

[Alan Modra]

On Fri, Aug 26, 2005 at 07:38:47PM +0100, Dave Korn wrote:
>   Doesn't this mean that lang_do_assignments_1 could perhaps be processing
> an ASSERT _before_ it processes the real assignment statement that gives
> that symbol its correct value?  Given the correct ordering of statements?

Yes.  It also means that when --relax is given (some targets relax by
default) that you might see an assert triggering more than once.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: vmlinux parse error 2.6.12.5

[Russell King - ARM Linux]

On Fri, Aug 26, 2005 at 05:39:51PM +0100, Dave Korn wrote:
> >>   How long _has_ the ASSERT been present?  It wasn't in 2.6.7.  As far
> 
> > It is in 2.6.12 but not 2.6.11.12 the file to look at is
> > arch/arm/kernel/vmlinux.lds.S
> 
>   Thank you; that means that the assert has only been there for a couple of
> months and it's entirely possible that the problem is real and I'm just one
> of the first to be tripped up by it, rather than that it's been working fine
> for everyone for ages ....

If you read the ld info pages, you'll find that ASSERT() is documented
as a valid linker script command, and has been since about binutils 2.13.
It seems that there isn't an obvious syntactic error in the file, and it
works fine for the majority(?) of people.

I suggest folk who encounter this problem to report it to the binutils
folk so that they can investigate - the problem may be related to how
you built your binutils.

Also, when there is a resolution of this from the binutils people, please
let us know here the result.  Thanks.