[U-Boot-Users] Das U-Boot applications and ELDK 4.0 breakage

[Bryan O'Donoghue]

Greetings.

The following code breaks U-Boot applications with ELDK 4.0 and 
presumably with reasonably recent gcc toolchains, though not with ELDK 3.1.1

#include <common.h>
#include <commproc.h>

static void function_1();
/*
int bug_test(int argc, char * argv[]) __attribute__ ((section 
(".text.uboot")));
*/

int bug_test(int argc, char * argv[])
{

         app_startup(argv);
         printf("Startup\n");

         function_1();
         function_1();

         return 0;
}

static void function_1()
{

         printf("%s\n", __FUNCTION__);
         return;
}

Compling this for powerpc yeilds

bethany at SlackwareBabe:~/devel/DasUBoot$ ppc_8xx-gdb examples/bug_test 

GNU gdb Red Hat Linux (6.3.0.0-1.21_1rh)
<snip>
(gdb) disass 0x40004
Dump of assembler code for function function_1:
0x00040004 <function_1+0>:      stwu    r1,-16(r1)
0x00040008 <function_1+4>:      mflr    r0
0x0004000c <function_1+8>:      bcl-    20,4*cr7+so,0x40010 <function_1+12>
0x00040010 <function_1+12>:     stmw    r30,8(r1)
0x00040014 <function_1+16>:     mflr    r30
0x00040018 <function_1+20>:     stw     r0,20(r1)
0x0004001c <function_1+24>:     lwz     r0,-16(r30)
0x00040020 <function_1+28>:     add     r30,r0,r30
0x00040024 <function_1+32>:     lwz     r3,-32768(r30)
0x00040028 <function_1+36>:     lwz     r4,-32764(r30)
0x0004002c <function_1+40>:     bl      0x400ec <printf>
0x00040030 <function_1+44>:     lwz     r0,20(r1)
0x00040034 <function_1+48>:     lmw     r30,8(r1)
0x00040038 <function_1+52>:     mtlr    r0
0x0004003c <function_1+56>:     addi    r1,r1,16
0x00040040 <function_1+60>:     blr
End of assembler dump.

bethany at SlackwareBabe:~/devel/DasUBoot$ ppc_8xx-gcc -v
<snip>
gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)

Compiling with ELDK 3.1.1 or simply calling function_1() just once in 
bug_test will result in the function bug_test being linked to 0x40004 as 
expected.

If I'm right what is happening is that the placement of functions in the 
text section has changed behaviour between toolchain versions and gcc 
now will optimise placement of functions/variables in sections.

I have tried messing about with various __attribute__ ((section ("x"))) 
promulgations to get around the fact that we are expecting the function 
bug_test to be present at 0x40004.

The only reliable way to do that is to specify to gcc 
-fno-unit-at-a-time during compile time. Apparently this prevents gcc 
from parsing the entire file before starting to generate assembler and 
consequently produces bug_test at the address 0x40004 as expected.

While -fno-unit-at-a-time wouldn't be _too_ bad, the gcc manual states 
that -fno-unit-at-a-time may not be supported in future releases and 
code that cares about the address of variables/functions should use 
explicate section attributes !

I haven't been able to figure out how to tell ld to create a 
"subsection" in the text section and to put ".text.uboot" at a specific 
address above.

For example -Ttext=0xblah --section-start=.uboot.text=0xblah completely 
ignores the --section-start and puts bug_test where *ld* thinks it 
should go.

Possibly one could apply an __attribute__ ((section (".uboot_entry"))) 
qualifier to a function and the Makefile could say something like 
--section-start=.uboot_entry=0x40000 -Ttext=0x50000 but, that's probably 
a little naff and make assumptions about how big your code will be.

This mightn't be a bug that's even worth fixing, i.e. the number of 
people who a) write applications and b) make multiple calls to locally 
defined functions in U-Boot probably numbers at 1 !

In any case I'm a linker script newbie so perhaps there is a 
simple/obvious/easy fix for this that I'm just missing, apologies if 
that is the case.


Greetings, Happy new year, etc.
Bryan

-- 
"Caveat Emptor" -- James T. Kirk, in no such episode