Failed to process map file when gcov build option is used

[bethmal]

Hi,

fpvgcc fails to process map file when below build options are used.

-fprofile-arcs -ftest-coverage

Thanks.

[chintal]

Can you please provide a map file that fails with these build options? Based on what I've seen before, I would not be surprised if the solution is simply a matter of ignoring some lines in the map files.

[bethmal]

Hi Chintal,

Please find below abstracted piece of map data.
Symbols with leading .data..LPBX are making errors.

 .data..LPBX1   0x2002051c       0x2c D:\lib\libdevmgr.a(devmgr.c.obj)
 .data.__gcov_.prv_is_occupy
                0x20020548       0x18 D:\lib\libdevmgr.a(devmgr.c.obj)
 .data.__gcov_.prv_set_occupy
                0x20020560       0x18 D:\lib\libdevmgr.a(devmgr.c.obj)
 .data.__gcov_.prv_clr_occupy
                0x20020578       0x18 D:\lib\libdevmgr.a(devmgr.c.obj)
 .data.__gcov_.prv_find_devbyname
                0x20020590       0x18 D:\lib\libdevmgr.a(devmgr.c.obj)
 .data.__gcov_.prv_find_devidx
                0x200205a8       0x18 D:\lib\libdevmgr.a(devmgr.c.obj)
 .data.__gcov_.devmgr_dev_occupy
                0x200205c0       0x18 D:\lib\libdevmgr.a(devmgr.c.obj)
 .data.__gcov_.EmbeddedV_Device_Instantiate
                0x200205d8       0x18 D:\lib\libdevmgr.a(devmgr.c.obj)
 .data.__gcov_.devmgr_dev_exist
                0x200205f0       0x18 D:\lib\libdevmgr.a(devmgr.c.obj)
 .data.__gcov_.devmgr_dev_release
                0x20020608       0x18 D:\lib\libdevmgr.a(devmgr.c.obj)
 .data.__gcov_.devmgr_dev_cnt
                0x20020620       0x18 D:\lib\libdevmgr.a(devmgr.c.obj)
 .data..LPBX0   0x20020638       0x3c D:\lib\libdevmgr.a(devmgr.c.obj)
 .data.__gcov_.devmgr_devinfo_get
                0x20020674       0x18 D:\lib\libdevmgr.a(devmgr.c.obj)

Error message:
Firmware Report for d:\Integration\SmokingTestApplication\build\Engdata\bin\output.mapTraceback (most recent call last):
File "fpvgcc\datastructures\ntree.py", line 227, in get_node
File "fpvgcc\datastructures\ntree.py", line 143, in get_child_by_ident
ValueError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "ev-fpvgcc.py", line 55, in
File "ev-fpvgcc.py", line 39, in generate_footprint
File "fpvgcc\fpv.py", line 570, in process_map_file
File "fpvgcc\fpv.py", line 517, in process_linkermap_line
File "fpvgcc\fpv.py", line 458, in process_linkermap_section_detail_line
File "fpvgcc\fpv.py", line 294, in linkermap_get_newnode
File "fpvgcc\datastructures\ntree.py", line 231, in get_node
File "fpvgcc\gccMemoryMap.py", line 154, in add_child
File "fpvgcc\datastructures\ntree.py", line 74, in add_child
ValueError: Child with that identifier already exists:
[40292] Failed to execute script 'ev-fpvgcc' due to unhandled exception!

[chintal]

I'm pretty sure this is caused because of the repeated separator (data..LPBX1).

Do you happen to know what the meaning of this is? I expect .data..LPBX1 means something different than .data.LPBX1.

To resolve the exception in the script, these are options I can think of:

• ignore these lines entirely. This is what I do for other syntactically different lines which do not actually have a footprint in terms of size on device.
• Treat .data..LPBX as if it were .data.LPBX1, but this may result in the symbol listings being littered with LPBX1 and similar which may actually be incorrect there. Size analysis may also get thrown off slightly due to this.
• Treat .data..LPBX as .data.unk.LPBX1. This is my preferred solution, since we retain the information that there was something different about the name, even though we don't quite know or care what it is. Also, it would not be appropriate to ignore the line entirely since the example you showed suggests there is an actual footprint in .data, because the shift in address corresponds to the declared size.

Any of these three solutions should allow the script to at least run. Do you have any insight into which solution is likely to be meaningfully correct?

[bethmal]

Those are compiler generated symbols during compiling time, or we can say they are from instrumented code when compile with gcov features. So I also prefer 3rd solution. We can present there is unknow information but can not exclude them from footprint usage.