[Bug gas/26143] gas generates invalid line table entry
https://sourceware.org/bugzilla/show_bug.cgi?id=26143 --- Comment #4 from Alexandre Oliva --- tom> I get the impression that the "which might not be the same as that of the following assembly instruction" formulation refers to a situation like this yup nick> what do you think that the assembler should be doing in this situation? ISTM that .cfi_endproc should implicitly bump (increment or reset) the view number. I don't think that would solve the issue of strict dwarf compliance though. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26143] gas generates invalid line table entry
https://sourceware.org/bugzilla/show_bug.cgi?id=26143 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=26092 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26143] gas generates invalid line table entry
https://sourceware.org/bugzilla/show_bug.cgi?id=26143 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=95574 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26143] gas generates invalid line table entry
https://sourceware.org/bugzilla/show_bug.cgi?id=26143 --- Comment #3 from Nick Clifton --- (In reply to Tom de Vries from comment #2) Hi Tom, > So, I don't agree with this assessment. Ok, in which case it would seem that the bug is actually due to the compiler generating: .loc 1 12 5 view .LVU14 .cfi_endproc instead of: .loc 1 12 5 .cfi_endproc As you previously suggested. (Or maybe .LUV14 ought to be replaced with -0 ?) So shouldn't this be a compiler bug report and not an assembler bug report ? Basically what I am getting at is - what do you think that the assembler should be doing in this situation ? Generate an error message about a malformed line table ? Automatically remove the last row from the table ? Something else ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26143] gas generates invalid line table entry
https://sourceware.org/bugzilla/show_bug.cgi?id=26143 Tom de Vries changed: What|Removed |Added CC||aoliva at sourceware dot org --- Comment #2 from Tom de Vries --- (In reply to Nick Clifton from comment #1) > (In reply to Tom de Vries from comment #0) > Hi Tom, > > > [0x0080] Special opcode 75: advance Address by 5 to 0x1c and Line by > > 0 to 12 > > [0x0081] Extended opcode 1: End of Sequence > > > Every line number program sequence must end with a DW_LNE_end_sequence > > instruction which creates a row whose address is that of the byte after the > > last target machine instruction of the sequence. > > > One the one hand, the end-of-sequence declares that address 0x1c is one past > > the byte of the last target machine instruction of the sequence. > > > > On the other hand, the special opcode declares a target instruction starting > > at address 0x1c, that is part of that same sequence. > > Ah - but special opcodes do not necessarily assert that there is a target > instruction starting at the address they reference. Hi Nick, As indicated in dwarf4 standard 6.2.5.1 point 3, each special opcode adds a row to the matrix. Each row represents a machine instruction, as implied here in 6.2: ... If space were not a consideration, the information provided in the .debug_line section could be represented as a large matrix, with one row for each instruction in the emitted object code. ... The exception is a row with end_sequence set to true, but that's not the case for the row generated by: ... [0x0080] Special opcode 75: advance Address by 5 to 0x1c and Line by 0 to 12 ... So, I don't agree with this assessment. If you still think my interpretation is wrong, you should state an alternative one. What does the generated row mean according to you, in terms of the DWARF standard? > > > > This option causes a row to be added to .debug_line in reference to the > > current address (which might not be the same as that of the following > > assembly instruction), > > > I cannot tell from the formulation "in reference to the current address > > (which might not be the same as that of the following assembly instruction)" > > whether this particular instance of .loc usage is valid. > > My take on this is that the "view" directive specifies a property for an > address, but it does not require that there be an instruction at that > address. Hence the generated line number table is correct... > I'm not sure the semantics of the view directive are relevant to the correctness of the generated line number table. It's my understanding that the implementation for views intends to emit pure dwarf with no extensions, and that the view info can be interpreted by consumers with support, and ignored by consumers without support. After watching Alexandre Oliva's 2017 GNU Cauldron presentation, I get the impression that the "which might not be the same as that of the following assembly instruction" formulation refers to a situation like this: ... .loc .balign 32 .loc insn1 ... where the first loc may or may not refer to insn1. ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26143] gas generates invalid line table entry
https://sourceware.org/bugzilla/show_bug.cgi?id=26143 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Tom de Vries from comment #0) Hi Tom, > [0x0080] Special opcode 75: advance Address by 5 to 0x1c and Line by > 0 to 12 > [0x0081] Extended opcode 1: End of Sequence > Every line number program sequence must end with a DW_LNE_end_sequence > instruction which creates a row whose address is that of the byte after the > last target machine instruction of the sequence. > One the one hand, the end-of-sequence declares that address 0x1c is one past > the byte of the last target machine instruction of the sequence. > > On the other hand, the special opcode declares a target instruction starting > at address 0x1c, that is part of that same sequence. Ah - but special opcodes do not necessarily assert that there is a target instruction starting at the address they reference. > This option causes a row to be added to .debug_line in reference to the > current address (which might not be the same as that of the following > assembly instruction), > I cannot tell from the formulation "in reference to the current address > (which might not be the same as that of the following assembly instruction)" > whether this particular instance of .loc usage is valid. My take on this is that the "view" directive specifies a property for an address, but it does not require that there be an instruction at that address. Hence the generated line number table is correct... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
