Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Application hangs before main(), update: __uClibc_main.o related?

2005-09-14 by arkeryd

These exact 12 bytes of bss memory, occupied by __uClibc_main.o, cause
the trouble. Normally main() won't start, but if doing a workaround in
startup.s so that these bytes are not cleared, then main() starts.

(
.map file extract:
 .bss           0x40000b0c        0xc
/cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/li
bc.a(__uClibc_main.o)
                0x40000b0c                __environ
                0x40000b0c                environ
                0x40000b10                __progname
)

What could it be?

Kind Regards

/ DA

--- In lpc2000@yahoogroups.com, "arkeryd" <arkeryd@y...> wrote:
> According to debug session trough simulator,
> R1 (bss start) is loaded with 0x40000380 and R2 (bss end) with
> 0x40001748, in other words the exact same addresses as in the .map
> file.
> 
> 
> After investigating further I have found that the range of memory,
> where clearing causes software to hang, is the same as bss range
used
> by standard c libraries, below follows excerpt from the .map file.
> 
> Feels weirder and weirder...
> 
> .bss           0x40000b0c        0xc
> /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/li
> bc.a(__uClibc_main.o)
>                 0x40000b0c                __environ
>                 0x40000b0c                environ
>                 0x40000b10                __progname
>  .bss           0x40000b18        0xc
> /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/li
> bc.a(__exit_handler.o)
>                 0x40000b1c                __exit_function_table
>                 0x40000b18                __exit_count
>                 0x40000b20                __exit_slots
>  .bss           0x40000b24        0x4
> /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/libc.a(exit.o)
>                 0x40000b24                __exit_cleanup
>  .bss           0x40000b28        0x4
> /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/libc.a(abort.o)
>  .bss           0x40000b2c       0x98
> /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/libc.a(malloc.o)
>  .bss           0x40000bc4        0x4
> /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/libc.a(brk.o)
>                 0x40000bc4                ___brk_addr
>  .bss           0x40000bc8        0x8
> /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/libc.a(errno.o)
>                 0x40000bcc                _h_errno
>                 0x40000bc8                errno
>                 0x40000bcc                h_errno
>                 0x40000bc8                _errno
>  .bss           0x40000bd0        0xa
> /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/li
> bc.a(_ppfs_parsespec.o)
>  *fill*         0x40000bda        0x2 00
>  .bss           0x40000bdc        0x8
> /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/libc.a(mbsrtowcs.o)
>  .bss           0x40000be4        0x8
> /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/
libc.a(__mbsnrtowcs.o)
>  .bss           0x40000bec      0x200
> /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/
libc.a(_stdio_init.o)
> 
> 
> Kind Regards
> 
> / DA
> 
> 
> --- In lpc2000@yahoogroups.com, "xjag74" <detlef.weidner@w...>
wrote:
> > Hi,
> > 
> > try to figure out with which values R1 und R2 are loaded before
the 
> > loop (the values for the symbols __bss_start__ and __bss_end__).
> > 
> > Regards
> > XJAG
> > 
> > --- In lpc2000@yahoogroups.com, "arkeryd" <arkeryd@y...> wrote:
> > > Thanks, but...
> > > 
> > > I checked the .map file and it shows the same thing, the bss
area 
> > ends
> > > at address 0x40001748.
> > > 
> > > The ram area ranges from 0x40000000 to 0x40003FFF and the stack
> is 
> > at
> > > the end of the ram area, and total stack size is below 0x500
> bytes.
> > > 
> > > So as described below, it does't look like is an overlap
> conflict, 
> > but
> > >     main() refuses to start unless commenting out the clear bss
> code
> > > from startup.s.  
> > > 
> > > I can't even get some dummy code just setting the leds - using 
> > MBC2100
> > > dev board - followed by an eternal looop at beginning of main()
to
> > > run, unless commenting out the code for clearing bss section.
> > > 
> > > Kind Regards
> > > 
> > > / DA
> > > 
> > > 
> > > 
> > > --- In lpc2000@yahoogroups.com, "xjag74" <detlef.weidner@w...> 
> > wrote:
> > > > Hi,
> > > > 
> > > > have a look to the Map-file.
> > > > Check if the bss area is within the range of the RAM memory
> area 
> > > > (below the stack area).
> > > > 
> > > > regards
> > > > xjag
> > > > 
> > > > 
> > > > --- In lpc2000@yahoogroups.com, "arkeryd" <arkeryd@y...>
wrote:
> > > > > Hi,
> > > > > 
> > > > > After adding several new source files to my application for
> > > LPC2129,
> > > > > it hangs when jumping from startup.s to main(). 
> > > > > 
> > > > > The first thing that came to my mind was that perhaps too
> much 
> > ram
> > > > > memory was now used.
> > > > > However, after checking by running startup.s trough the 
> > debugger,
> > > it
> > > > > doesn't seem like that.
> > > > > I use the default startup.s for LPC2129.
> > > > > 
> > > > > The last address used by the .data- and .bss-sections
> > > > > (variables/arrays) in my application is 0x40001748.
> > > > > 
> > > > > And this should not collide with stack either, as I use the
> > > default
> > > > > stack address and sizes:
> > > > > Interrupt Mode size: 0x80
> > > > > User/system mode size: 0x400
> > > > > And just 4 bytes size in other modes.
> > > > > Top of stack address: 0x40004000.
> > > > > 
> > > > > The weird thing is even though no memory collision should
> occur,
> > > the
> > > > > application starts if I comment out the "Clear .bss section 
> > code"
> > > in
> > > > > startup.s, so it must somehow be some collision, but I don't
> > > > > understand why.
> > > > > 
> > > > > # Clear .bss section (Zero init)
> > > > >                 MOV     R0, #0
> > > > >                 LDR     R1, =__bss_start__
> > > > >                 LDR     R2, =__bss_end__
> > > > > LoopZI:         CMP     R1, R2
> > > > >                 STRLO   R0, [R1], #4
> > > > >                 BLO     LoopZI
> > > > > 
> > > > > Any input to clear my confusion would be much appreciated!
:)

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.