On Thu, Oct 2, 2025 at 10:55 AM Jan Hubicka <[email protected]> wrote:
>
> >
> > IIRC this will add linkage name into early debug, so with LTO this pre-dates
> > any mangling done by WPA. Did you check how it behaves with LTO?
>
> auto-profile is read at compile time (before LTO). It
> needs to apply profile measured on optimized program to almost
> unoptimized one. We have get_original_name which knows what suffixes
> are added after auto-profile (isra, constprop, lto_priv, part, cold).
> >
> > linkage names add quite some bloat - the patch indicates we never added
> > them for local visibility functions? As for the name/TU pair, the TU should
> > be discoverable by walking the DIE parents.
>
> Yes, dwarf contains them only for public symbols (including optimized
> out comdats). I am not sure what they are used for, I see it was
> originally MIPS extension that became part of dwarf. If function is not
> inline AFDO tools will use symbol name, but if it is inline there is no
> info. llvm adds it always.
ISTR removing them alltogether made gdb unhappy, but that was 10 years
ago - I think they do not add much value but possibly save mangling/demangling
in gdb.
I'd say we do not want to expand usage unconditionally for everyone, because
it's mostly redundant info.
> >
> > -gdebug-for-auto-profile is a bit verbose, I wonder (unless you plan more
> > changes here) whether a -g[no-]linkage-names or
> > -glinkage-names={default,full,none}
> > might be more universally useful?
> I am not sure what kind of command line interface we want to arrive for,
> but I would like to have one option for user to specify that he/she
> intends to perf the program and use auto-profile later.
I'm fine with a -gafdo switch that turns on individual bits, but the ability
to turn off linkage names separately sounds appealing to me ;)
> This is relatively complicated at clang side. Manual
> https://clang.llvm.org/docs/UsersManual.html#using-sampling-profilers
> suggests:
>
> clang++ -O2 -gline-tables-only \
> -fdebug-info-for-profiling -funique-internal-linkage-names \
> code.cc -o code
>
> for training run.
>
> -gline-tables-only enables debug info w/o debug for
> types at all (so less than our -O1). I think it may make sense to have
> similar switch, singe the debug info is then much smaller. It is not
> that useful for debuging then, but still useful for profiling by perf
> etc.
You still need inline info, aka parse dwarf to figure abstract origins, etc?
> -fdebug-info-for-profiling enables
> discriminators, so I tought it may be benefical to have simlar name.
> (which I got wrong in the email). There is no documentation of that
> option, but grepping clang sources seems to show only this difference.
>
> I think we may have two things
>
> 1) -gdebug-info-for-profiling which enables necessary bits of debug
> info. I do not know why they went for -f
> 2) -fauto-profile-friendly (or better name) which will set up debug
> but also disable optimizations not working well with auto-profile.
> This is, for example, ICF that leads to completely misplaced
> profile.
>
> -funique-internal-linkage-names adds the .uniq suffixes
> to all internal symbols which I would like to avoid. It breaks asm
> statements and causes bloat of symbol tables. LLVM folks says they are
> replacing it anyway.
>
> I am also fine with -glinkage-names= and -gdiscriminators,
> but we probably want some umbrella switch for those planning to use
> auto-fdo.
Agreed.
> I am not thrilled with a way clang handles the tooling of auto-fdo.
> While solving individual problem I however try to look to what they do
> and try to avoid unnecesary wheels reinventions. I thinkt he sugested
> command line above is way too verbose and sensitive to actual setup.
>
> For example on Windows one needs to use
>
> clang-cl /O2 -gdwarf -gline-tables-only ^
> /clang:-fdebug-info-for-profiling /clang:-funique-internal-linkage-names ^
> code.cc /Fe:code /fuse-ld=lld /link /debug:dwarf
>
> Which looks awful.
>
> LLVM has also competely alternative way to do instrumentation using
> -fpseudo-probe-for-profiling which is an alternative to
> -fdebug-info-for-profiling and its implementation is described in this
> review thread https://reviews.llvm.org/D86193
> Pseudo-probes internally are implemented as kind of debug statements.
> They are builtin calls that fake incrementing some counter which gets
> through the compilation and ends up in separate section.
>
> Newither -fdebug-info-for-profiling or -fpseudo-probe-for-profiling is
> documented in clang manual. -fdebug-info-for-profiling is
>
> As discussed, I think we can try to follow the path of improving debug
> info especially since I think most of the changes necessary are actually
> useful to real debugging. In addition to the way to get unique names
> for internal linkage functions, I also need to solve the problem with
> multiple stacktraces per instruction which would be indeed useful if you
> want to implement single-stepping over optimized out code. Jakub
> mentioned that this is being worked on at GDB side.
Yes. So as for the patch in question can you please add
-glinkage-names={default,none,all} and gate generation appropriately?
And alias -g[no-]linkage-names to none/default appropriately.
Thanks,
Richard.
> Honza
> >
> >
> > > gcc/ChangeLog:
> > >
> > > * dwarf2out.cc (add_linkage_name): Store linkage names
> > > of private function symbols to help auto-fdo.
> > >
> > > diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
> > > index 0bd8474bc37..95d9f219cf0 100644
> > > --- a/gcc/dwarf2out.cc
> > > +++ b/gcc/dwarf2out.cc
> > > @@ -22235,7 +22235,10 @@ add_linkage_name (dw_die_ref die, tree decl)
> > > {
> > > if (debug_info_level > DINFO_LEVEL_NONE
> > > && VAR_OR_FUNCTION_DECL_P (decl)
> > > - && TREE_PUBLIC (decl)
> > > + && (TREE_PUBLIC (decl)
> > > + /* Linkage names of internal function symbols
> > > + are used by auto-fdo. */
> > > + || TREE_CODE (decl) == FUNCTION_DECL)
> > > && !(VAR_P (decl) && DECL_REGISTER (decl))
> > > && die->die_tag != DW_TAG_member)
> > > add_linkage_name_raw (die, decl);
