c++ - Finding the memory location of a compile-time constructed class -

i'm trying memory-usage analysis of using compile-time constructed classes looking @ artifacts generated compilation. i've marked several class constructors "constexpr" , made sure they're trivial ensure compile-time construction. viewing map file, can see constructors , destructor functions not included in .text section more.

where, though, these classes appear? had assumed included in .data section static instance of class, doesn't seem case. .text section has shrunk other sections seem same. data going?

(i'm using gcc 5.2.0 , creating statically-linked elf.)

edit: here's bit of sample code.

#include <stddef.h> #include <stdint.h>  struct abstractmemoryaccess {     virtual uint32_t read() const = 0;      virtual void write(const uint32_t data) const = 0; };  class concertememoryaccess : public abstractmemoryaccess { public:     constexpr concertememoryaccess(const size_t baseaddress)         : _baseaddress(baseaddress)     {         // empty     }      virtual uint32_t read() const     {         return *(volatile uint32_t *)(_baseaddress);     }       virtual void write(const uint32_t data) const     {         *(volatile uint32_t *)(_baseaddress) = data;     }  private:     const size_t _baseaddress; };  #define arbitrary_peripheral_address 0x40001000  int main(void) {     concertememoryaccess memoryaccessor(arbitrary_peripheral_address);     abstractmemoryaccess &rabsmemoryaccessor = memoryaccessor;      while (1)     {         uint32_t readdata = rabsmemoryaccessor.read();         rabsmemoryaccessor.write(readdata);     }      return 0; } 

which decompiles this:

000006a4 <main>:  6a4:   b0004000    imm 16384  6a8:   e8601000    lwi r3, r0, 4096  6ac:   b0004000    imm 16384  6b0:   f8601000    swi r3, r0, 4096  6b4:   b800fff0    bri -16 // 6a4 <main> 

so looks it's inlining memory accesses... true non-trivial cases? calls on constexpr object inlined?

that code can de-virtualized, why vtable isn't needed , it's possible compile virtuals away nothing. compiler can see both classes, they're in same translation unit.

de-virtualization can happen across translation units when using link-time optimization (lto.)

so looks it's inlining memory accesses... true non-trivial cases? calls on constexpr object inlined?

no. it's in example, it's rather easy de-virtualize functions. once happens, there's no virtual anymore , no vtable go through, usual optimizations of non-virtual functions kick in, , stuff can compile away thin air.