IAR for ARM Map File Inconsistencies

Hello Samuel,

Samuel said:

1. In the module summary the code size of gpio.o is reported as 572 bytes, but if you add up the sum of the code segments, it comes out to be 392 bytes. Where is the remaining 180 bytes going in the gpio.o module? I see the same issue in several other modules too.

The 572 bytes would include the 392 bytes (which might just be the code) and the data that might have been used by one or more of the functions in the module (like "%d" that is passed to UARTprintf() would take up 2 bytes of data). An analysis of the disassembly would give a better understanding of how the remaining 180 bytes are used. The data used by each function is typically listed at the bottom of each function in disassembly.

Samuel said:

2. In the MODULE SUMMARY section the data size of gpio.o is 0 bytes, but in the ENTRY LIST section there is the data segment named g_pui32GPIOBaseAddrs, which section is correct?

Is "g_pui32GPIOBaseAddrs" a constant variable? Maybe that's the reason it is not listed separately under data but could have been included in the overall code size of gpio.o file.

Samuel said:

In addition, I see several functions where the sizes aren't shown at all, for example:

__aeabi_d2iz            0x000054dd          Code  Gb  DblToI32.o [6]
__iar_d2uiz             0x00005509          Code  Gb  DblToI32.o [6]

3. Why aren't the sizes of the functions shown?

Which section of the map file did you pick these functions from? Not sure why the size is not mentioned.

Samuel said:

4. Also, what do the "Gb" and "Lc" strings represent? Is it possible to deduce any information from them?

A quick Google search showed the following:

- Lc = local.
- Gb = global.
- Wk = weak.
- ?? = unknown.

I am not sure about the meaning though. Since "Lc" is listed against "g_pui32GPIOBaseAddrs" which seems to be a global variable (if TivaWare coding convention is followed). Maybe "Lc" stands for local to the module like a "static" variable.

Hope this helps!

Sai 

Sai,

1.

"The 572 bytes would include the 392 bytes (which might just be the code) and the data that might have been used by one or more of the functions in the module (like "%d" that is passed to UARTprintf() would take up 2 bytes of data). An analysis of the disassembly would give a better understanding of how the remaining 180 bytes are used. The data used by each function is typically listed at the bottom of each function in disassembly."

But wouldn't the 2 bytes from your example be listed as read only data? In the MODULE SUMMARY there is no "ro" data for gpio.o, copied from above:

*** MODULE SUMMARY
...
    Module                  ro code  ro data  rw data
    ------                  -------  -------  -------
...
driverlib.a: [5]
...
    gpio.o                      572

gpio.o doesn't have any ro (read only) data according to the MODULE SUMMARY. I don't think this explains where the 180 bytes is going.

2.

"Is "g_pui32GPIOBaseAddrs" a constant variable? Maybe that's the reason it is not listed separately under data but could have been included in the overall code size of gpio.o file."

Yes, the definition is static const uint32_t g_pui32GPIOBaseAddrs[] = .... Regardless, gpio.o doesn't show any read only, see the MODULE SUMMARY I pasted above. This adds another question: 5. Why isn't the g_pui32GPIOBaseAddrs variable shown as ro data in the MODULE SUMMARY?

3. The lines containing the __aeabi_d2iz and __iar_d2uiz functions were taken from the ENTRY LIST section.

4. The g_pui32GPIOBaseAddrs variable is static const and it's in a C file. IAR reports it as Lc, i.e. local as you mentioned, so it looks like IAR reported it correctly. I don't know TivaWare's coding convention but I assume this variable declaration simply isn't following the convention.

5. As I mentioned above, why isn't the g_pui32GPIOBaseAddrs variable shown as ro data in the MODULE SUMMARY of gpio.o?

Thanks,
Samuel