lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 1 Dec 2020 17:08:50 -0800
From:   Fāng-ruì Sòng <>
To:     Segher Boessenkool <>
Cc:     Masahiro Yamada <>,
        Nick Desaulniers <>,
        Jakub Jelinek <>,
        Linux Kbuild mailing list <>,
        Linux Kernel Mailing List <>,,
        clang-built-linux <>,
        Nathan Chancellor <>,
        Sedat Dilek <>,
        Dmitry Golovin <>,
        Alistair Delva <>
Subject: Re: [PATCH v2 3/4] Kbuild: make DWARF version a choice

On 2020-12-01, Segher Boessenkool wrote:
>On Tue, Dec 01, 2020 at 12:38:16PM +0900, Masahiro Yamada wrote:
>> > We can bump -Wa,-gdwarf-2 to -Wa,-gdwarf-3 since GNU actually emits
>> > DWARF v3 DW_AT_ranges (see
>> > )
>> > This can avoid the `warning: DWARF2 only supports one section per
>> > compilation unit` warning for Clang.
>That warning should be "there can be only one section with executable
>code per translation unit", or similar.
>> I am not a DWARF spec expert.
>Neither am I.
>> Please teach me.
>> In my understanding, "DWARF2 only supports one section ..."
>> is warned only when building .S files with LLVM_IAS=1
>.S files are simply run through the C preprocessor first, and then given
>to the assembler.  The only difference there should be wrt debug info is
>you could have some macros that expand to assembler debug statements.
>> If this is due to the limitation of DWARF v2, why is it OK to
>> build .c files with LLVM_IAS?
>The compiler can of course make sure not to use certain constructs in
>its generated assembler code, while the assembler will have to swallow
>whatever the user wrote.

These are all correct. You can use `llvm-dwarfdump a.o` to dump a .o file.
It has one DW_TAG_compile_unit. If the translation unit has a single
contiguous address range, the assembler can emit a pair of
DW_AT_low_pc/DW_AT_high_pc (available in DWARF v2). In the case of
multiple executable sections, it is not guaranteed that in the final
linked image the sections will be contiguous, so the assembler has to
assume there may be non-contiguous address ranges and use DW_AT_ranges.

Unfortunately DW_AT_ranges was introduced in DWARF v3 and technically
not available in DWARF v2. But GNU as ignores this and emits
DW_AT_ranges anyway (this is probably fine - like using a GNU extension).

If -Wa,-gdwarf-2 -> -Wa,-gdwarf-3 can eliminate the LLVM integrated
assembler's warning, we should do it. If people think -Wa,-gdwarf-2 is
not useful and want to delete it, I'll be happier. Whether it is
necessary to use -Wa,-gdwarf-2/-Wa,-gdwarf-5? Personally I would think
this is unnecessary, but I won't mind if people don't mind the
additional complexity in Makefile. (I implemented the -gdwarf-5 address
range stuff for the integrated assembler).

Powered by blists - more mailing lists