Community
Participate
Working Groups
CQ:WIND00-TCDIAB-12363 When debugging highly optimized code, instruction reordering or code that's optimized out can lead to very unexpected mappings between source numbers and actual addresses. In one case, it happened for a customer that he wanted to set a breakpoint in an initialization routine void init() { myGlobal = 0; } but since the compiler had optimized out the assignment and replaced it with static BSS initialization, the breakpoint got relocated to a different function just beneath this. Such relocation behavior is extremely confusing and not acceptable. I'm not sure if the concrete issue described here can be due to incorrect debug info (can it?) but I'm wondering what TCF can do to avoid such problems. What about a Preference to disable breakpoint relocation for instance, or limit it to 3 lines maximum ? Any other thoughts / ideas ?
It is ether compiler fault or a bug in TCF symbol info reader. To tell more, I would need the ELF file.
Hi Eugene, The only information I can provide is that: - In the debug_infos, there are 2 compilation unit for the SAME C file. The first compilation unit has NO AT_low_pc / AT_high_pc. The second compilation unit has AT_low_pc / AT_high_pc. - In the debug_lines, there are 2 compilation unit for the SAME C file. The first compilation unit has the searched line with an address. Perfect, this address is returned. The second compilation unit hasn't the searched line, that will lead to the "wrong relocation". However, should the TCF debugger go to the SECOND compilation unit since it could find a match in the debug_lines ? One could say no. However, a breakpoint can be spread at several @ so in a sense, it is normal to look in the second compilation unit, especially since AT_low_pc / AT_high_pc is provided...As said previously, the second compilation hasn't the exact line so the closest match is also provided. So the customer ends-up with 2 addresses : the right one and a bogus one. Very Best Regards, Xavier.
