Hello,
Not sure i have anything useful to say on discussion on ctorhoming but
should it be so ill try to chime in on discussion. On bugs i cant talk.
Didnt heavily test it or use it much at all but i could say how it may seem
when trying to compete with vc and how it may look from john does sw devel
side possibly not a superstar one.
Best regards,
Pawel Kunio
pt., 16.04.2021, 02:03 użytkownik David Blaikie <dblaikie at gmail.com>
napisał:
> On Thu, Apr 15, 2021 at 4:57 PM pawel k. <pawel.kunio at gmail.com>
wrote:
> >
> > Is constructor homing this featurette where class di is emitted only
for
> compunits with reference to constructor?
>
> Yep - both Clang and GCC already do something equivalent for any type
> with virtual functions - the debug info for that type is emitted only
> where the vtable is emitted (so called "vtable homing") so
it's not
> without precedent. Yeah, it means potentially missing any type that
> isn't constructed (types used only to hold a bunch of static members,
> for instance) - but perhaps such a type isn't needed anyway. This
> isn't done for types with trivial constructors - since they don't
> generate code, etc.
>
> > Id speculate therell be problems with it as i understand the idea by
> now.
>
> Certainly open to any critiques/bugs/etc. It's currently accessible
> under -fuse-ctor-homing
> https://www.mail-archive.com/cfe-commits at lists.llvm.org/msg218269.html
>
> > Shared type table feels bit more complex on impl side fir merging etc
> but feels stronger.
>
> Tradeoffs to be sure - anything that's shared during compile time's
> not really usable in the build environment (massively distributed) I
> support, but can work for others (like MSVC does). C++ modules (both
> Clang Header Modules and C++20 standard modules) offer another way to
> "home" debug info - since modules are then a first class build
product
> they can be used to home debug info quite reliably (template
> instantiations may be duplicated - since they may be instantiated in
> multiple unrelated places, but even then any module depending on a
> module with an insntantiation need not re-do that instantiation).
>
> - Dave
>
> >
> > Best regards,
> > Pawel Kunio
> >
> > pt., 16.04.2021, 01:40 użytkownik David Blaikie <dblaikie at
gmail.com>
> napisał:
> >>
> >> On Thu, Apr 15, 2021 at 4:22 PM pawel k. <pawel.kunio at
gmail.com> wrote:
> >> >
> >> > Ok for gdb, load time was major pain.
> >>
> >> Ah, for large binaries you probably want to compile with
> >> -ggnu-pubnames -Wl,--gdb-index (you must compile with this for
Split
> >> DWARF - it relies on the index) that takes, for instance, gdb
startup
> >> time debugging clang from 3 minutes to about 3 seconds. (lldb does
a
> >> better job lazy loading DWARF - so faster startup time even
without an
> >> index (& it can't use the gdb index anyway) trading off
some
> >> operations later will be slower as things are lazy loaded later
on)
> >>
> >> > Type casting was patchy some types missing etc,
> >>
> >> Hard to say what's at work there - happy to speculate/help if
you have
> >> a specific/isolated example.
> >>
> >> > some var tracking especially under optimizations was tricky
for
> example having to cast registers because info this var is stored in this
> register was missing
> >>
> >> Yeah, that's less about the workflow/technology, but more as
we like
> >> to say, the "quality of implementation" - keeping track
of variables
> >> under optimization is tricky, and different compilers do it
> >> well/poorly - DWARF certainly offers a good variety of ways to
express
> >> these things (and gaining more as DWARF improves - it's
certainly not
> >> "complete", but I don't think it ever can be -
there'll always be more
> >> cunning optimizations and cunning ways to try to recover the value
of
> >> user variables under those optimizations).
> >>
> >> > hmm also one mire thing that could minimize debug info size
could be
> shared types section with removing local copies per compilation unit.
> >>
> >> Yep - that can already be done with DWARF type units
> >> (-fdebug-types-section), but also various strategies to reduce
> >> emitting the types in the first place (hopefully we'll be
enabling the
> >> constructor homing strategy by default soon which should reduce
> >> duplicate type information significantly)
> >>
> >> > Also global vars etc could be stored in shared segment. Also
we could
> think of somehow indexing the db.
> >>
> >> Yeah, as mentioned above, gdb (& lld and gold) support the
gdb_index
> >> format and that can be generated at link time with -Wl,--gdb-index
> >> (objects need to be compiled with -ggnu-pubnames (that comes by
> >> default if you specify -gsplit-dwarf I think... ) for this to
work).
> >> And there is a DWARFv5 debug_names section, but it's not fully
> >> supported yet (we don't have any linker that supports merging
> >> .debug_names from object files into a unified .debug_names in the
> >> linked binary - nor any debuggers that can consume the
.debug_names
> >> index).
> >>
> >> > My other idea is indeed distributing stripped binaries and
devels
> keeping debug info dbs snapshots locally or via debug servers. If we dont
> wanna debug servers, stack traces etc should contain stack dumps maybe or
> some in the middle solution with lineinfo only possibly hashed etc.
> >> >
> >> > Best regards,
> >> > Pawel Kunio
> >> >
> >> > pt., 16.04.2021, 01:06 użytkownik David Blaikie <dblaikie
at gmail.com>
> napisał:
> >> >>
> >> >> On Thu, Apr 15, 2021 at 2:43 PM pawel k. via llvm-dev
> >> >> <llvm-dev at lists.llvm.org> wrote:
> >> >> >
> >> >> > Hiya,
> >> >> >
> >> >> > Enormous thanks for all suggests and extensive too.
Testing
> splitdwarf asap.
> >> >> >
> >> >> > Makes me think what i thought previously. We need
dwarf go pdbish
> way.
> >> >>
> >> >> Split DWARF provides something like this, though with
some different
> >> >> tradeoffs - for instance Split DWARF is easier to use in
a
> distributed
> >> >> build (since the compiler doesn't have to communicate
with a separate
> >> >> server while it's compiling).
> >> >>
> >> >> > Separate dblike possibly adressable by url.
> >> >>
> >> >> Symbol servers are another problem - even using classic
DWARF you can
> >> >> then strip the main binary, keep the unstripped binary
and put that
> >> >> unstripped binary on some kind of symbol server system
(I'm not sure
> >> >> if gdb supports something like that natively, but could
be done
> >> >> without DWARF changes).
> >> >>
> >> >> > I was hacking pdb techno before it got sexy. I know
a bit how it
> is organized and could try to help with architecting or designing such
> solution. Loved dbinfo on vstudio. Gdbish not so much.
> >> >>
> >> >> What sort of problems have you had with gdb or the DWARF
debugging
> >> >> workflow more generally?
> >> >>
> >> >> > And i was slaving on my corpo cotton plantation
passively using
> gdb for about a decade.
> >> >>
> >> >> (analogies to slavery aren't suitable for this
community)
> >> >>
> >> >> - Dave
> >> >>
> >> >> >
> >> >> > If catches anyones focus, lets discuss the solution.
> >> >> >
> >> >> > Best regards,
> >> >> > Pawel Kunio
> >> >> >
> >> >> > czw., 15.04.2021, 23:37 użytkownik Min-Yih Hsu
<minyihh at uci.edu>
> napisał:
> >> >> >>
> >> >> >> You can use `LLVM_USE_LINKER=lld` CMake variable
to adopt LLD (to
> build LLVM). And yes, LLD takes less memory and runs faster. Here are some
> other tips to save memory:
> >> >> >> 1. You can use `LLVM_PARALLEL_LINK_JOBS=N` (also
a cmake
> variable) to limit the amount of parallel linker jobs to save some memory.
> >> >> >>
> >> >> >> 2. Build libraries as shared library via
`BUILD_SHARED_LIBS=ON`
> CMake variable can dramatically speed up the linking time and save you some
> memory.
> >> >> >>
> >> >> >> 3. Since you’re building a Debug build (and
you’re building on
> Linux), `LLVM_USE_SPLIT_DWARF` can dramatically reduce the size of debug
> info, which, to some extend, also save you some memory during link time.
> >> >> >>
> >> >> >> Best,
> >> >> >> -Min
> >> >> >> > On Apr 15, 2021, at 1:05 PM, pawel k. via
llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >> >> >> >
> >> >> >> > Hello,
> >> >> >> > Im trying to build trunk clang in debug
version on oldish
> ubuntu with low mem. Linking lli takes ages and fails on low mem. Is there
> a chance building would succeed if i used lld instead of ld? If so is there
> an option either to force lld or whole clang toolchain use in cmake instead
> of default gcc (both gcc and clang are avail on system)? Otherwise I think
> ill stick with release.
> >> >> >> >
> >> >> >> > Best regards,
> >> >> >> > Pawel Kunio
> >> >> >> >
_______________________________________________
> >> >> >> > LLVM Developers mailing list
> >> >> >> > llvm-dev at lists.llvm.org
> >> >> >> >
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >> >> >>
> >> >> > _______________________________________________
> >> >> > LLVM Developers mailing list
> >> >> > llvm-dev at lists.llvm.org
> >> >> >
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210416/341ada65/attachment.html>