Colin Tuckley wrote:
> 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.
>
Sorry not to reply sooner. I had a week of "other job" activity.
I confirm that this seems to be different default behaviour in gcc 2.95
and 3.4 re placing zeroed variables in the bss section and not the data
section. Did you try adding -fno-zero-initialized-in-bss to OS_CFLAGS?
It works for me in principle. bootldr.nm now suggests that ack_commands
(for example) is a "D" thing and not a "B" thing as before.
Nick
> 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?
>
> regards,
>
> Colin
>
(text/plain)