Re: [Balloon] bootldr and gcc 3.3 - the story continues

In message <44168E8E.3010006@tuckley.org> Colin Tuckley writes:
>Over the weekend I tried to track down what I thought was a problem with the
>optimiser in gcc 3.3 vs the one in gcc 2.95. I started getting inconsistent
>test results and after confusing myself and then sorting things out I've
>come to the conclusion that the optimiser isn't to blame - at least not
>directly.
>
>What does seem to be the problem is that the compiler is putting variables
>that are explicitly initialised to zero into the BSS segment, presumably
>because it assumes this segment gets zeroed before execution starts. However
>this doesn't seem to be true in our case.
>
>So, can someone explain how the BSS gets zeroed in the bootldr environment
>on balloon? I found some code for it (zbss) in bootldr.c but it doesn't get
>compiled. I also had a look through the various bits of assembler code, but
>I don't know ARM assembler and couldn't spot anything obvious.

I don't have the code, but this suggests that there is a problem with
pre-processor control of how bootldr.c is compiled and/or linked. This is
assuming that gcc V2.95 does compile it where as V3.3 does not. Either that
or linker control file is not generating the correct symbols for BSS causing
the linker at least to believe there is NO BSS symbols for zbss to use, so
does not link in zbss.

>When I jflash the code into the balloon it appears to program a lot of
>zero's at the end but this is going into Flash, can someone point me to the
>code that copies the bootldr into RAM - maybe it's not copying enough (or
>any) of BSS?

On most systems using gcc (and other C compilers) BSS is NOT copied to the
file or image of the application, this is what the startup code MUST perform.
There should be something in the linker control file to determine where
BSS starts and ends, so that the startup code knows what memory range to
zero.

For example from some code that I have compiled under gcc 3.3 for a different
target had this in the linker control file:-

SECTIONS
{
  .vects   0x0000000 : { *(.vectors); } > rom
  .text    0x0000100 : { *(.text) *(.rodata); } > rom
  .strings 0x001B000 : { *(.strings); } > rom
  .mdata   0x001F000 : { _mdata = .; } > rom
  .checks  0x001FFFC : { *(.checks); } > rom
  .data    0x0FFEF20 : AT(ADDR(.mdata))
                          { _data = .; *(.data) _edata = .; } > ram
  .bss               : { _bss = .; *(.bss) *(COMMON); _ebss = .; } > ram
  .stack   0x0FFFF20 (NOLOAD) : { _stack = .; *(.stack); } > ram
}

Note symbols _bss and _ebss which are used.

Hopefully this might help you track down the problem, but I could be
completely off the wall.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate