Community
Participate
Working Groups
Created attachment 277545 [details] attachment contain source code/application/line debug infomation Thanks for fixing Bug 543995, after applying this fix, we meet another test case fail, it only happen on e500v2. Compiler is: gnu-8.1.0.0 Extra debug option is: -gdwarf-3 -gstatement-frontiers -gstatement-frontiers is added to generated stmt, otherwise, compiler won’t generate stmt information. The issue happen when debug an application, attached the simple case, when plant break point on line 100, the break point is adjusted to line 101, the root cause is that compiler generated two same line entries: [0x000001bc] Extended opcode 2: set Address to 0x80000f4c [0x000001c3] Special opcode 11: advance Address by 0 to 0x80000f4c and Line by 1 to 99 [0x000001c4] Set column to 5 [0x000001c6] Extended opcode 2: set Address to 0x80000f90 [0x000001cd] Special opcode 11: advance Address by 0 to 0x80000f90 and Line by 1 to 100 [0x000001ce] Set column to 5 [0x000001d0] Extended opcode 2: set Address to 0x80000f90 [0x000001d7] Set is_stmt to 0 [0x000001d8] Copy [0x000001d9] Set column to 9 [0x000001db] Extended opcode 2: set Address to 0x80000fa0 [0x000001e2] Set is_stmt to 1 [0x000001e3] Special opcode 11: advance Address by 0 to 0x80000fa0 and Line by 1 to 101 Line number, column and address are the same, when unit_line_to_address() search the entry, it will return two areas, and the first is wrong, before applying fix of Bug 543995 (state->mAddress < code_next->mAddress) could skip the first entry, with fix of Bug 543995 (state->mAddress <= code_next->mAddress), both of them are returned. I am not sure whether compiler generate two same entry is reasonable, apparently tcf doesn’t handle this case. BTW, we only meet this issue on e500v2, there is no issue on e6500. The line info of e6500: [0x00000105] Set column to 5 [0x00000107] Special opcode 20: advance Address by 4 to 0x80000fc8 and Line by 1 to 79 [0x00000108] Set is_stmt to 1 [0x00000109] Advance Line by 19 to 98 [0x0000010b] Special opcode 103: advance Address by 28 to 0x80000fe4 and Line by 0 to 98 [0x0000010c] Special opcode 104: advance Address by 28 to 0x80001000 and Line by 1 to 99 [0x0000010d] Special opcode 104: advance Address by 28 to 0x8000101c and Line by 1 to 100 [0x0000010e] Set column to 10 [0x00000110] Set is_stmt to 0 [0x00000111] Copy The column of two entries are different.
The problem is ambiguous info for 0x80000f90. In particular, it has is_stmt both 0 and 1. It looks like compiler bug to me. I have committed a workaround. I could not validate the fix, because your test case is for vxWorks, and it crashes when I try to run it on PPC Linux. Please, consider re-linking for Linux when submitting a test case. Fixed. Thanks!
Thanks, it works.
