| Message ID | 20210204064037.1281726-1-ndesaulniers@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Kbuild: DWARF v5 support | expand |
On Thu, Feb 4, 2021 at 7:40 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > DWARF v5 is the latest standard of the DWARF debug info format. > > DWARF5 wins significantly in terms of size and especially so when mixed > with compression (CONFIG_DEBUG_INFO_COMPRESSED). > > Link: http://www.dwarfstd.org/doc/DWARF5.pdf > > Patch 1 is a cleanup that lays the ground work and isn't DWARF > v5 specific. > Patch 2 implements Kconfig and Kbuild support for DWARFv5. > > Changes from v7: > (Strictly commit message changes) > * Pick up Nathan's reviewed by tags for both patches. > * Add note about only modifying compiler dwarf info, not assembler dwarf > info, as per Nathan. > * Add link to Red Hat bug report and Chris' reported by on patch 2. > * Add more info from Jakub on patch 2 commit message. > * Reorder info about validating version, noting the tree is not "clean" > in the sense that parts mess up existing CFLAGS, or don't use > DEBUG_CFLAGS. I will not be adding such cleanups to this series. They > can be done AFTER. > * Update note about 2.35.2 (rather than include the full text Jakub > wrote on it in https://patchwork.kernel.org/project/linux-kbuild/patch/20201022012106.1875129-1-ndesaulniers@google.com/#23727667). > * Add note that GCC 11 has changed the implicit default version. > I have intensively tested a lot of versions of this series and some other issues reported and got fixed. So my comments for followers: [ Download v8 with b4 ] link="https://lore.kernel.org/r/20210204064037.1281726-1-ndesaulniers@google.com" b4 -d am $link [ Pre-Patch before applying v8 ] "kbuild: Remove $(cc-option,-gdwarf-4) dependency from DEBUG_INFO_DWARF4" https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild&id=3f4d8ce271c7082be75bacbcbd2048aa78ce2b44 [ DEBUG_CFLAGS thread and fix ] https://marc.info/?t=161233893400006&r=1&w=2 https://marc.info/?l=linux-kbuild&m=161233892923723&w=2 Feel free to be more verbose and include links (to patches). I guess I need to test harder to get a Tested-by credit :-)? Thanks for v8, I will use it for some testing with BTF/pahole. - Sedat - > Changes from v6: > * Reorder sections from linker script to match order from BFD's internal > linker script. > * Add .debug_names section, as per Fangrui. > * Drop CONFIG_DEBUG_INFO_DWARF2. Patch 0001 becomes a menu with 1 > choice. GCC's implicit default version of DWARF has been DWARF v4 > since ~4.8. > * Modify the test script to check for the presence of > https://sourceware.org/bugzilla/show_bug.cgi?id=27195. > * Drop the clang without integrated assembler block in > 0002. Bumps the version requirement for GAS to 2.35.2, which isn't > released yet (but should be released soon). Folks looking to test > with clang but without the integrated assembler should fetch > binutils-gdb, build it from source, add a symlink to > binutils-gdb/gas/as-new to binutils-gdb/gas/as, then prefix > binutils-gdb/gas/as to their $PATH when building the kernel. > > Changes from v5: > * Drop previous patch 1, it has been accepted into kbuild: > https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild&id=3f4d8ce271c7082be75bacbcbd2048aa78ce2b44 > * Trying to set -Wa,-gdwarf-4 in the earlier patch was the source of > additional complexity. Drop it that part of the patch. We can revisit > clang without the integrated assembler setting -Wa,-gdwarf-4 later. > That is a separate problem from generally supporting DWARF v5. > * Rework the final patch for clang without the integrated assembler. > -Wa,-gdwarf-5 is required for DWARF5 in that case otherwise GAS will > not accept the assembler directives clang produces from C code when > generating asm. > > Changes from v4: > * drop set -e from script as per Nathan. > * add dependency on !CONFIG_DEBUG_INFO_BTF for DWARF v5 as per Sedat. > * Move LLVM_IAS=1 complexity from patch 2 to patch 3 as per Arvind and > Masahiro. Sorry it took me a few tries to understand the point (I > might still not), but it looks much cleaner this way. Sorry Nathan, I > did not carry forward your previous reviews as a result, but I would > appreciate if you could look again. > * Add Nathan's reviewed by tag to patch 1. > * Reword commit message for patch 3 to mention LLVM_IAS=1 and -gdwarf-5 > binutils addition later, and BTF issue. > * I still happen to see a pahole related error spew for the combination > of: > * LLVM=1 > * LLVM_IAS=1 > * CONFIG_DEBUG_INFO_DWARF4 > * CONFIG_DEBUG_INFO_BTF > Though they're non-fatal to the build. I'm not sure yet why removing > any one of the above prevents the warning spew. Maybe we'll need a v6. > > Changes from v3: > > Changes as per Arvind: > * only add -Wa,-gdwarf-5 for (LLVM=1|CC=clang)+LLVM_IAS=0 builds. > * add -gdwarf-5 to Kconfig shell script. > * only run Kconfig shell script for Clang. > > Apologies to Sedat and Nathan; I appreciate previous testing/review, but > I did no carry forward your Tested-by and Reviewed-by tags, as the > patches have changed too much IMO. > > Changes from v2: > * Drop two of the earlier patches that have been accepted already. > * Add measurements with GCC 10.2 to commit message. > * Update help text as per Arvind with help from Caroline. > * Improve case/wording between DWARF Versions as per Masahiro. > > Changes from the RFC: > * split patch in 3 patch series, include Fangrui's patch, too. > * prefer `DWARF vX` format, as per Fangrui. > * use spaces between assignment in Makefile as per Masahiro. > * simplify setting dwarf-version-y as per Masahiro. > * indent `prompt` in Kconfig change as per Masahiro. > * remove explicit default in Kconfig as per Masahiro. > * add comments to test_dwarf5_support.sh. > * change echo in test_dwarf5_support.sh as per Masahiro. > * remove -u from test_dwarf5_support.sh as per Masahiro. > * add a -gdwarf-5 cc-option check to Kconfig as per Jakub. > > Nick Desaulniers (2): > Kbuild: make DWARF version a choice > Kbuild: implement support for DWARF v5 > > Makefile | 6 +++--- > include/asm-generic/vmlinux.lds.h | 7 +++++- > lib/Kconfig.debug | 36 +++++++++++++++++++++++++------ > scripts/test_dwarf5_support.sh | 8 +++++++ > 4 files changed, 47 insertions(+), 10 deletions(-) > create mode 100755 scripts/test_dwarf5_support.sh > > -- > 2.30.0.365.g02bc693789-goog >
On Wed, Feb 3, 2021 at 10:58 PM Sedat Dilek <sedat.dilek@gmail.com> wrote: > > I guess I need to test harder to get a Tested-by credit :-)? You're right Sedat, I'm sorry. Your testing is invaluable; thank you for taking the time to help and credit is a powerful incentive. It can be difficult to know whether to carry forward tags or not when a patch is revised. Keeping track whether someone sent an explicit Tested By vs including it based on feedback that implied they tried it. If you've tested v7 or v8, please reply explicitly with tested by tags, or perhaps Masahiro can apply those for you. It can be difficult to know what's broken if you apply too many out of tree patches though.
On Thu, Feb 4, 2021 at 8:45 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > On Wed, Feb 3, 2021 at 10:58 PM Sedat Dilek <sedat.dilek@gmail.com> wrote: > > > > I guess I need to test harder to get a Tested-by credit :-)? > > You're right Sedat, I'm sorry. Your testing is invaluable; thank you > for taking the time to help and credit is a powerful incentive. > > It can be difficult to know whether to carry forward tags or not when > a patch is revised. > > Keeping track whether someone sent an explicit Tested By vs including > it based on feedback that implied they tried it. If you've tested v7 > or v8, please reply explicitly with tested by tags, or perhaps > Masahiro can apply those for you. > Unfortunately, some recent patches around CBL and kbuild miss my Tested-by's and are already queued up in the remote Git's. Maybe, I was simply pissed off this fact when writing my response to you. Feel free to add my... Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # v1-v8 with LLVM/Clang v11.0.1+ & v12.0.0-rc1 amd64 Looking at the (git) diff v7 -> v8 - seen from the code - nothing changed. Feel free to add the links to thread(s) and patch(es) I gave as a feedback in my other response. One reason for missed Tested-by's I see is I am NOT subscribed to some mailing-list. > It can be difficult to know what's broken if you apply too many out of > tree patches though. > "Nicht verkomplifizieren." In English: "R(e)D(u)C(e) complexity" is normally one of my life philosophies. Fighting with... "As usual: It has to work in my development environment - first." Sorry, I insisted that it *has* to work in my environment. It has no secrets - all patches I have queued up in my custom patchset is publically available. That does not mean all of them are or will be upstreamed. Bonne chance with the Linux-BPF folks and send my apologies to have fooled them. It's one of my """strength of character""" (note 3 quotes) :-). - Sedat -