https://sourceware.org/bugzilla/show_bug.cgi?id=16908
--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jan Beulich <jbeul...@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=657edeab3857130ddc005a88104711dd9e339ff0 commit 657edeab3857130ddc005a88104711dd9e339ff0 Author: Jan Beulich <jbeul...@suse.com> Date: Tue Apr 12 09:03:43 2022 +0200 gas: further adjust file/line handling for .macro Commit 7992631e8c0b ("gas/Dwarf: improve debug info generation from .irp and alike blocks"), while dealing okay with actual assembly source files not using .file/.line and alike outside but not inside of .macro, has undue effects when the logical file/line pair was already overridden: Line numbers would continuously increment while processing the expanded macro, while the goal of the PR gas/16908 workaround is to keep the expansion associated with the line invoking the macro. However, as soon as enough state was overridden _inside_ the macro to cause as_where() to no longer fall back top as_where_physical(), honor this by resuming the bumping of the logical line number. Note that from_sb_is_expansion's initializer was 1 for an unknown reason. While renaming the variable and changing its type, also change the initializer to "expanding_none", which would have been "0" in the original code. Originally the initializer value itself wasn't ever used anyway (requiring sb_index != -1), as it necessarily had changed in input_scrub_include_sb() alongside setting sb_index to other than -1. Strictly speaking input_scrub_insert_line() perhaps shouldn't use expanding_none, yet none of the other enumerators fit there either. And then strictly speaking that function probably shouldn't exist in the first place. It's used only by tic54x. -- You are receiving this mail because: You are on the CC list for the bug.
