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

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@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@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
participants (1)
-
Bryan O'Donoghue