• Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 1034 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler: TI C library hides malloc/minit complexity within the linker

1138
Expert 1226 points

Tool/software: TI C/C++ Compiler

I'm looking through the malloc() code path in the support library for TI's ARM Optimizing C/C++ Compiler.


One path I was researching is how malloc() behaves when the system has been compiled with no heap allocated (i.e. specify --heap_size=0 to the linker).

As documented in both the TI assembler and TI compiler documentation, the TI linker:

The linker also creates a global symbol, __SYSMEM_SIZE, and assigns it a value equal to the size of the heap in bytes.

Looking through the code, specifically the minit() code within memory.c, it is clear that the code is not capable of dealing with a __SYSMEM_SIZE of 0.  If __SYSMEM_SIZE were 0, then calling malloc() would corrupt memory.

As it happens, the compilation chain _is_ attempting to handle this case, however.  It appears that the linker enforces a minimum size of 8.  If you specify --heap_size=0 (or, presumably, --heap_size=7), the TI linker will actually generate a .sysmem section of 8 bytes, and set __SYSMEM_SIZE to 8.

I would, and am, argue that this approach of implementing part of the C library functionality within the linker is not a clean separation of responsibility. 

I separately argue that putting part of this functionality within the linker hides functionality; it is very valuable to us to be able to look at the C library source, but the linker is more opaque.

Finally, I argue that the behavior is confusing.  I would have expected to be able to write my own code that could check __SYSMEM_SIZE against 0 to determine whether or not there is any heap compiled into the firmware.  Having to write this check instead against a value of 8 (or potentially some other architecture-dependent value) would be a surprising result.

I would like to request that the memory.c code be updated to explicitly handle a __SYSMEM_SIZE of 0, and the linker updated accordingly.

In the event that this request is not approved, I would like to request that this linker behavior be documented accordingly, potentially in the minit() source code itself as well as in the TI manuals.

--thx

  • TI__Guru**** 239130 points

    You started three different, though related, threads about issues with the malloc functions when attempting to use --heap_size=0.  I filed a single entry in the SDOWP system to address all of them.  The ID is CODEGEN-2112 .  You are welcome to follow it with the SDOWP link below in my signature.  The entry does not say there is a bug in the malloc functions.  Rather, it requests changes to make the implementation more robust and clear when handling the case of --heap_size=0.

    Thanks and regards,

    -George

  • in reply to George Mock
    Expert 1226 points

    Thanks for following up on my queries.

    I appreciate that these three issues are related to each other, and if it is easier for you to group them together under one tracking ID, then fair enough.

    Just to be clear, however, there _is_ a bug in the handling of malloc(), it does corrupt memory in a reasonable use case.

    While my preference is certainly to have all three of my different (but related) issues handled, it would be a shame if it turns out that a memory corruption bug were left unfixed for an extended period because it is tagged in your system as an enhancement rather than a defect.

    Also, there is a piece which may not have been clear about my request to confirm at link-time that no heap is being used:

    https://e2e.ti.com/support/development_tools/compiler/f/343/t/579456

    This request is _not_ to check at link-time whether or not the heap size has been specified as 0.  This request to enable to way to prevent the code from linking if there is any code present which might _attempt_ to use the heap.  (As such, I would expect it to fail to compile even if a heap size > 0 has been specified.)  Again, this is a kind of functionality available with the Keil ARM toolchain.

    --thx

  • in reply to 1138
    TI__Guru**** 239130 points

    Please rest assured that I will make all of your concerns known to the compiler development team.  Even though there is a mix of enhancements and bugs, I continue to think it makes sense to present them all at once.

    To be fair to you, I should point out a disadvantage in your situation.  When deciding what to prioritize, we (mostly) consider two things: ease of implementation, and the number of customers who benefit.  The ideal feature can be implemented in a day, and benefits all of our customers.  Your requests have trouble for both considerations.  They are not easy to implement, and the number of customers requesting these changes is few.

    Thanks and regards,

    -George