Q:

How to find C++ language constructs allocating dynamic memory?

I work on an embedded system firmware code-basis which currently uses dynamic memory allocation. Now, all dynamic memory allocation shall be removed for reliability reasons.
As a first step, I removed the _sbrk syscall implementation, such that all dynamic allocations fail to link. Since I compile with -ffunction-sections -fdata-sections and link with -Wl,--gc-sections I expect the link step to complete as long as no dynamic memory allocation occurs. (This worked for me in past C projects, unsure about C++ here.)
Although the following linker error message is expected, it does not help to find the C++ construct which triggers the dynamic allocation.
[...]arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'
collect2: error: ld returned 1 exit status

Is there an effective way to find C++ language constructs, which use dynamic heap allocation (apart from the obvious use of new)?
EDIT: I am looking for a static tool, not a runtime instrumentation/analysis technique.
EDIT2: (Since somebody removed the appropriate tags:) The project targets an STM32F4 MCU and is compiled and linked with an GCC-based arm-none-eabi-* toolchain.

A:

The problem with blocking linkage to sbrk is that sbrk is the very bottom of the heap management process and is not necessarily called for all allocations.  It is simply a means of adding to the existing heap pool.
The new operator may be overloaded, or placement-new, so need not even perform dynamic allocation or allocation via the system heap. However instances of new that do will at least call malloc().
The GNU linker --cref output may help; this will tell you for each symbol, what files reference them.  Unfortunately the GNU linker does not have the --callgraph option that the ARM linker has, which will show the complete call path that leads to any particular function. 
Avoiding explicit linkage of dynamic memory allocation probably means removing most of the C++ specific parts of the standard library - certainly STL container classes, std::string.

