Thanks everyone for great advice, maybe we should mention some of this on
the https://llvm.org/docs/GettingStarted.html page.
Maybe under a subtitle like "Development on low-end devices" or
something.
This would be helpful for newcomers who are working with low-end devices.
Also since it was not mentioned, ccache <https://ccache.dev/> can help
with
build times during development.
pawel k. via llvm-dev <llvm-dev at lists.llvm.org>, 16 Nis 2021 Cum, 03:10
tarihinde şunu yazdı:
> 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
>>
> _______________________________________________
> 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/83241ec4/attachment-0001.html>