• State Not Answered
  • Locked Locked
  • Replies 16 replies
  • Subscribers 22 subscribers
  • Views 3673 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Dealy bug (?) in CM0 microlib

Tamiryan Michael

Building with Microlib:

    s_tx_buffer                              0x100015d0   Data        2050  bluetooth_frame_handler.o(.bss)
    STACK                                    0x10001dd8   Section      304  startup_lpc11xx.o(STACK)

"s_tx_buffer" goes until 0x10001DD2 - but the stack grows backwards...?
This causes data corruptions - of course!

withuot Microlib:

    s_tx_buffer                              0x100015cc   Data        2050  bluetooth_frame_handler.o(.bss)
    .bss                                     0x10001dd0   Section       96  libspace.o(.bss)
    HEAP                                     0x10001e30   Section        0  startup_lpc11xx.o(HEAP)
    STACK                                    0x10001e30   Section      304  startup_lpc11xx.o(STACK)
    Heap_Mem                                 0x10001e30   Data           0  startup_lpc11xx.o(HEAP)
    Stack_Mem                                0x10001e30   Data         304  startup_lpc11xx.o(STACK)

Which looks better and indeed causes no corruptions.

Parents
  • 0

    This causes data corruptions - of course!

    Wrong. What you've shown does not cause any data corruption just like that, much less does it "of course" do so.

    Which looks better

    Specifically, please: how do you think that looks any better? What's the supposedly significant difference you see between

    a) 304 bytes of stack following almost immediately after the .bss section of one module, and

    b) 304 bytes of stack following immediately after the .bss section of some other module,

    and why do you expect it to prevent any data corruption in case b) that case a) exhibited?

    and indeed causes no corruptions.

    You're rather certainly wrong about that. Odds are you've just not noticed the corruption in that case yet --- because there's really no reason in the facts you've shown that would allow to concluse that it would be any less likely.

Reply
  • 0

    This causes data corruptions - of course!

    Wrong. What you've shown does not cause any data corruption just like that, much less does it "of course" do so.

    Which looks better

    Specifically, please: how do you think that looks any better? What's the supposedly significant difference you see between

    a) 304 bytes of stack following almost immediately after the .bss section of one module, and

    b) 304 bytes of stack following immediately after the .bss section of some other module,

    and why do you expect it to prevent any data corruption in case b) that case a) exhibited?

    and indeed causes no corruptions.

    You're rather certainly wrong about that. Odds are you've just not noticed the corruption in that case yet --- because there's really no reason in the facts you've shown that would allow to concluse that it would be any less likely.

Children