[llvm-dev] Is clang genned debuginfo really that huge
pawel k. via llvm-dev
llvm-dev at lists.llvm.org
Fri Apr 16 12:00:37 PDT 2021
Hello,
Yea i mean i know its large but some manage to make it even larger in other
projects like golang.
If that helps anyone id think of it as kind of db design kind of problem.
My understanding is debug standard was being created more or less ad hoc
and later as documentation of code. For example whole db being in major
order split by compilation units.
As of on efficiency of storage id probably think of making it as much as
possible shared in common sections, making the rest as compact as possible
but minding access from debugger use cases and possibly topping it with
some db style indices.
Id think pdb ms format could ne treated as gold standard. It seems to be
ultra efficient both for storage and accesses from debugger.
Best regards,
Pawel Kunio
pt., 16.04.2021, 17:10 użytkownik <paul.robinson at sony.com> napisał:
> In a RelWithDebInfo (-g -O2) build of Clang, over 90% of the final
> executable size is DWARF information.
>
> The percentage will be lower with a Debug build, but I don’t have an
> actual number for that.
>
> You can look at the sizes of ELF sections whose names start with .debug_
> to see for yourself.
>
> --paulr
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *pawel
> k. via llvm-dev
> *Sent:* Friday, April 16, 2021 10:00 AM
> *To:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* [llvm-dev] Is clang genned debuginfo really that huge
>
>
>
> Hi,
>
> Slightly weekendy offtopic on debug info and stacktraces as afterthought
> on my fight with building clang on lowbie machine and how not to approach
> this area.
>
>
>
> Slightly neg example: golang.
>
> https://social.lansky.name/@hn100/106075246574771701
> <https://urldefense.com/v3/__https:/social.lansky.name/@hn100/106075246574771701__;!!JmoZiZGBv3RvKRSx!prx6BiBJgvf-zJPhNmN0GKNXyFhCefia5K9p6Rd_3wnex5bVdKFDoLpex_Ev5XUsKw$>
>
>
>
> Sorry for offtop and have a nice weekend,
>
> Pk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210416/36806205/attachment.html>
More information about the llvm-dev
mailing list