Make lld's -gdb-index work without -ggnu-pubnames

[rui314]

Bugzilla Link	34820
Version	unspecified
OS	All
CC	@dwblaikie,@emaste,@MaskRay,@nico,@pogo59,@pawelsopensource,@Trass3r

Extended Description

Currently, lld's -gdb-index doesn't work without adding -ggnu-pubnames to the compiler command line. Looks like GNU gold can create a correct .gdb_index section without that compiler flag.

We want to improve lld so that it can create a .gdb_index section without passing -ggnu-pubnames to compilers.

[rui314]

assigned to @rui314

[rui314]

I talked about this with David Blaikie.

• We are not sure if gold actually creates completely valid .gdb_index sections if -ggnu-pubnames was not given.

• We probably can create completely valid .gdb_index if we parse DWARF debug info, but that is time-consuming.

• It might make sense to emit a warning if -gdb-index is given but input files don't seem to have been compiled with -ggnu-pubnames, but we are not completely sure if there are no false positives.

[MaskRay]

Looks like a wontfix (https://reviews.llvm.org/D54497). gold does have the traversal code. It is valid but the use case for this feature is probably too narrow. Moreover, people care more about DWARF v5 and its accelerated table now.

[dwblaikie]

I think this should be addressed - but not necessarily by having lld correctly parse all the DWARF & build names from scratch.

I'll still argue this bug is a good place for this request - because as it currently stands, lld produces in incorrect index in the absence of gnu-pubnames (so a request that this "work" in a broad sense, as in "is correct" - not necessarily "indexes everything")

To summarize a recent discussion:

• given an input with a CU without gnu-pubnames, lld currently includes that CU in the gdb-index, but without any names indexed - this leads consumers to not manually index the CU because they believe it's already covered by the index

• lld should either index the contents (expensive in both link time and linker implementation complexity - probably undesirable as the first resolution of this bug indicated) or produce an index that does not suggest such CUs are covered by it

• additionally, probably a warning that the index is incomplete would be nice (perhaps when -gdb-index is used, a warning if any CU is missing pubnames, and an error if /all/ CUs are missing pubnames)

[nico]

Should we make -ggnu-pubnames the default in clang if -g is given so that things at least Just Work when using lld with clang? Or are there drawbacks to that?

[pogo59]

Should we make -ggnu-pubnames the default in clang if -g is given so that
things at least Just Work when using lld with clang? Or are there drawbacks
to that?

I think only for "gdb tuning"? Definitely not for "sce tuning."
Also only for v2-v4; for v5 I'd think we'd prefer the v5 index.

[dwblaikie]

Should we make -ggnu-pubnames the default in clang if -g is given so that
things at least Just Work when using lld with clang? Or are there drawbacks
to that?

Debug info size cost is the main one - and it'd still be broken for gcc+lld, because gcc doesn't default to pubnames.

And this incompatibility isn't with all clang+lld, only clang+lld+gdb-index, so if someone's opting in to gdb-index they can also opt in to -ggnu-pubnames on the compile. Not ideal, indeed - be great to get lld fixed one way or another (either indexing things in the absence of pubnames, which seems expensive to me - or at least making the gdb-index accurately reflect that it does not index certain CUs (due to the missing pubnames))

[Trass3r]

-gsplit-dwarf activates the option but not sure how v5 affects everything:

llvm-project/clang/lib/Driver/ToolChains/Clang.cpp

Lines 4366 to 4374 in 812ad21

	if (DwarfFission != DwarfFissionKind::None ||
	(PubnamesArg && checkDebugInfoOption(PubnamesArg, Args, D, TC)))
	if (!PubnamesArg ||
	(!PubnamesArg->getOption().matches(options::OPT_gno_gnu_pubnames) &&
	!PubnamesArg->getOption().matches(options::OPT_gno_pubnames)))
	CmdArgs.push_back(PubnamesArg && PubnamesArg->getOption().matches(
	options::OPT_gpubnames)
	? "-gpubnames"
	: "-ggnu-pubnames");

[aury6623]

@rui314

It might make sense to emit a warning if -gdb-index is given but input files don't seem to have been compiled with -ggnu-pubnames, but we are not completely sure if there are no false positives.

Just a short 8 years later, I submitted a patch for this 😄 Any recollection of which false positives you were concerned about? My patch will only emit the warning if --gdb-index is used, and an input object file contains .debug_info, but does not contain either .debug_gnu_pubnames or .debug_gnu_pubtypes. That seems reasonable to me, but I'm a novice here!

I tried to use DWARF v5 replacements, but it seems that gdb still does not accept .debug_names emitted by llvm, so I'm stuck with .gdb_index for now.

[MaskRay]

While warnings are generally acceptable in Linux distros and OSS environments, corporate users and large projects using custom toolchains often upgrade warnings to errors by specifying --fatal-warnings. Reporting a warning should probably be deferred to a lint tool. It's also quite difficult to ensure that all object files have .debug_gnu_pubnames - when you have prebuilt object files.

Latest gdb has .debug_names support. And I've found this statement "I consider .gdb_index to be near the end of its life." at https://sourceware.org/bugzilla/show_bug.cgi?id=33316