bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/16908] #line directives are ignored inside macros


From: cvs-commit at gcc dot gnu.org
Subject: [Bug gas/16908] #line directives are ignored inside macros
Date: Tue, 12 Apr 2022 07:05:09 +0000

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 <jbeulich@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=657edeab3857130ddc005a88104711dd9e339ff0

commit 657edeab3857130ddc005a88104711dd9e339ff0
Author: Jan Beulich <jbeulich@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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]