On Mon, 28 Sep 2020 17:58:58 +0200, Jakub Jelinek wrote:
> On Mon, Sep 28, 2020 at 05:46:08PM +0200, Jan Kratochvil wrote:
> > On Mon, 28 Sep 2020 17:35:26 +0200, Jakub Jelinek wrote:
> > > A way out of this could be either to use comdat .debug_info etc. sections
> > > (but that would result in
On Wed, 07 Oct 2020 09:58:37 +0200, Jan Kratochvil wrote:
> On Wed, 07 Oct 2020 00:46:24 +0200, Jeff Law wrote:
> > On 9/30/20 3:50 AM, Jan Kratochvil wrote:
> > > When we start talking about RHEL (and CentOS) DWZ is completely pointless
> > > then
> > > as DWZ there saves only 0.28% of
On Tue, Oct 06, 2020 at 04:46:24PM -0600, Jeff Law wrote:
>
> On 9/30/20 3:50 AM, Jan Kratochvil wrote:
> > On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote:
> >> But the GCC community
> >> doesn't really test that option and it's known to be broken with LTO.
> > I haven't seen any GCC PR for
On Wed, 07 Oct 2020 00:46:24 +0200, Jeff Law wrote:
> On 9/30/20 3:50 AM, Jan Kratochvil wrote:
> > On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote:
> >> But the GCC community
> >> doesn't really test that option and it's known to be broken with LTO.
> > I haven't seen any GCC PR for
On 9/30/20 3:50 AM, Jan Kratochvil wrote:
> On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote:
>> But the GCC community
>> doesn't really test that option and it's known to be broken with LTO.
> I haven't seen any GCC PR for -fdebug-types-section being broken with LTO.
I'm not aware of one
On 10/4/20 2:48 PM, Jan Kratochvil wrote:
> On Tue, 29 Sep 2020 22:29:44 +0200, Mark Wielaard wrote:
>> I was just discussing that recently with the Hotspot Perf GUI
>> maintainer. And we concluded that if .debug files would be compressed
>> then we would need an uncompressed cache somewhere. The
On Mon, 05 Oct 2020 09:20:53 +0200, Florian Weimer wrote:
> Fedora Server still defaults to LVM and XFS, as far as I know. I expect
> that downstream will continue to use XFS as well.
>
> I don't think you can assume that debugging information will be stored
> on btrfs file systems.
OK. Then
* Jan Kratochvil:
> On Mon, 05 Oct 2020 08:28:03 +0200, Florian Weimer wrote:
>> Why do you think that? Using debuginfo for perf and the like seems to
>> be much more common than actual debugging, based on what I see
>> downstream.
>
> OK, interesting, thanks for the info. Still that does not
On Mon, 05 Oct 2020 08:28:03 +0200, Florian Weimer wrote:
> Why do you think that? Using debuginfo for perf and the like seems to
> be much more common than actual debugging, based on what I see
> downstream.
OK, interesting, thanks for the info. Still that does not change anything with
btrfs
* Jan Kratochvil:
> On Tue, 29 Sep 2020 22:29:44 +0200, Mark Wielaard wrote:
>> I was just discussing that recently with the Hotspot Perf GUI
>> maintainer. And we concluded that if .debug files would be compressed
>> then we would need an uncompressed cache somewhere. The issue with
>> having
On Tue, 29 Sep 2020 22:29:44 +0200, Mark Wielaard wrote:
> I was just discussing that recently with the Hotspot Perf GUI
> maintainer. And we concluded that if .debug files would be compressed
> then we would need an uncompressed cache somewhere. The issue with
> having the on-disk debuginfo files
On Mon, 28 Sep 2020 16:51:02 +0200, Jan Kratochvil wrote:
> To make DWZ better consumable it needs to have the partial units separately
> parseable. That way they can be shared at IR level and not just at DWARF level
> That means:
> * DW_TAG_partial_unit should have DW_AT_language.
> *
On Wed, 30 Sep 2020 23:42:56 +0200, Michel Alexandre Salim wrote:
> On Mon, 2020-09-28 at 16:50 +0200, Jan Kratochvil wrote:
> > For example during Fedora Package Review Process do some packages get
> > rejected because they would make the distribution too large? Not worth of
> > including such
On Mon, 2020-09-28 at 16:50 +0200, Jan Kratochvil wrote:
>
> For example during Fedora Package Review Process do some packages get
> rejected
> because they would make the distribution too large? Not worth of
> including
> such new package? I am not aware of such decision and it even sounds
>
On 9/29/20 5:59 PM, Neal Gompa wrote:
I feel like it's worth giving my perspective here as someone who has
done similar work in other distributions.
Thanks for that viewpoint. As a compiler optimizer junkie, I don't
really follow things on the RPM side, so hearing about that process has
On Tue, 29 Sep 2020 22:31:28 +0200, Mark Wielaard wrote:
> Note that you are using -ffunction-sections together with -flto.
> With -flto you don't need -ffunction-sections.
>
> -ffunction sections might cause functions to be dropped by the linker
> without updating the DWARF DIEs, causing things
On Tue, 29 Sep 2020 22:35:14 +0200, Mark Wielaard wrote:
> On Mon, Sep 28, 2020 at 04:50:59PM +0200, Jan Kratochvil wrote:
> > * DW_TAG_partial_unit should have DW_AT_language.
> > * DW_TAG_partial_unit must contain only types (struct/class).
> >Currently they contain for example also static
On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote:
> -fdebug-types-section a supported option in the sense that it's in the
> compiler and we'll fix bugs in it when we can. But the GCC community
> doesn't really test that option and it's known to be broken with LTO.
I believe you base this
On Fri, 25 Sep 2020 16:29:26 +0200, Jan Kratochvil wrote:
> On Fri, 25 Sep 2020 12:10:22 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > I would love to see a comparison of numbers for three things:
> > - raw debuginfo without dwz or -fdebug-types-section
>
> Oops, I do not have this number, I can
On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote:
> But the GCC community
> doesn't really test that option and it's known to be broken with LTO.
I haven't seen any GCC PR for -fdebug-types-section being broken with LTO.
During one abigail diff I did not see any difference. I plan to run a
On Tue, Sep 29, 2020 at 7:32 PM Jeff Law wrote:
>
>
> On 9/28/20 8:50 AM, Jan Kratochvil wrote:
> >
> > DWARF standard sometimes makes mistakes, for example .debug_pubnames and
> > .debug_pubtypes were never really usable and DWARF-5 removed them. It may be
> > perfectly possible the DWZ
On 9/28/20 8:50 AM, Jan Kratochvil wrote:
On Mon, 28 Sep 2020 12:31:59 +0200, Mark Wielaard wrote:
If you want to make -fdebug-types-sections the default you really
should work with the upstream GCC developers to figure out why they
don't want that.
I haven't seen that, according to Richard
Hi Jan,
On Mon, Sep 28, 2020 at 04:50:59PM +0200, Jan Kratochvil wrote:
> To make DWZ better consumable it needs to have the partial units separately
> parseable. That way they can be shared at IR level and not just at DWARF
> level
> That means:
> * DW_TAG_partial_unit should have
On Mon, Sep 28, 2020 at 05:46:08PM +0200, Jan Kratochvil wrote:
> On Mon, 28 Sep 2020 17:35:26 +0200, Jakub Jelinek wrote:
> > So, was this compiled by GCC or clang?
>
> Fedora Koji package:
> lldb-debuginfo-11.0.0-0.2.rc3.fc34.x86_64
>
> GNU GIMPLE 10.2.1 20200916 (Red Hat 10.2.1-4) -m64
Hi Jan,
On Mon, Sep 28, 2020 at 05:28:57PM +0200, Jan Kratochvil wrote:
> On Mon, 28 Sep 2020 12:31:59 +0200, Mark Wielaard wrote:
> > I do find your statistics per package useful because they show dwz is
> > in general effective by producing at least 20% (more) on-disk size
> > reduction,
>
> I
On Mon, Sep 28, 2020 at 08:29:21PM +0200, Jan Kratochvil wrote:
> On Mon, 28 Sep 2020 17:58:58 +0200, Jakub Jelinek wrote:
> > On Mon, Sep 28, 2020 at 05:46:08PM +0200, Jan Kratochvil wrote:
> > > https://whova.com/embedded/session/llvm_202010/1193947/
> >
> > If you do it on the compiler side,
On Mon, 28 Sep 2020 17:58:58 +0200, Jakub Jelinek wrote:
> On Mon, Sep 28, 2020 at 05:46:08PM +0200, Jan Kratochvil wrote:
> > https://whova.com/embedded/session/llvm_202010/1193947/
>
> If you do it on the compiler side, you'll get a lot of those pesky partial
> units you so hate on the lldb
On Mon, Sep 28, 2020 at 05:46:08PM +0200, Jan Kratochvil wrote:
> > A way out of this could be either to use comdat .debug_info etc. sections
> > (but that would result in quite large increase of *.o file sizes), or let
> > the linker or a tool like DWZ discard or simplify such DIEs.
> > I don't
On Mon, 28 Sep 2020 17:35:26 +0200, Jakub Jelinek wrote:
> So, was this compiled by GCC or clang?
Fedora Koji package:
lldb-debuginfo-11.0.0-0.2.rc3.fc34.x86_64
GNU GIMPLE 10.2.1 20200916 (Red Hat 10.2.1-4) -m64 -mtune=generic -march=x86-64
-g -g -g -O2 -O2 -O2 -O2 -fno-openmp
On Mon, Sep 28, 2020 at 05:15:16PM +0200, Jan Kratochvil wrote:
> On Mon, 28 Sep 2020 12:42:33 +0200, Jakub Jelinek wrote:
> > On Mon, Sep 28, 2020 at 12:31:59PM +0200, Mark Wielaard wrote:
> > > Finally I am interested in your proposal to implement a different way
> > > to reduce the size of DIE
On Mon, 28 Sep 2020 12:31:59 +0200, Mark Wielaard wrote:
> I do find your statistics per package useful because they show dwz is
> in general effective by producing at least 20% (more) on-disk size
> reduction,
I am ignoring the on-disk size, I always measure just *-debuginfo.rpm size.
If anyone
On Mon, 28 Sep 2020 12:42:33 +0200, Jakub Jelinek wrote:
> On Mon, Sep 28, 2020 at 12:31:59PM +0200, Mark Wielaard wrote:
> > Finally I am interested in your proposal to implement a different way
> > to reduce the size of DIE trees by eliminating "unused" DIEs. It is
> > hard to predict what
On Mon, 28 Sep 2020 12:31:59 +0200, Mark Wielaard wrote:
> If you want to make -fdebug-types-sections the default you really
> should work with the upstream GCC developers to figure out why they
> don't want that.
I haven't seen that, according to Richard Biener from GCC
-fdebug-types-section is
On Mon, 28 Sep 2020 14:08:48 +0200, Mark Wielaard wrote:
> It is certainly a clever setup and makes sense if your build bottleneck
> is sending files around between different machines. But I don't think
> this is the generic Fedora packager or developer use case.
I agree and I do not propose
Hi,
On Fri, 2020-09-25 at 17:18 +0200, Florian Weimer wrote:
> * Robbie Harwood:
> > Jan Kratochvil writes:
> > > So why is Google using it for everything?
> >
> > If I could eliminate one bad thought pattern in software design it would
> > probably be this one.
> >
> > In brief: you are not
On Mon, Sep 28, 2020 at 12:31:59PM +0200, Mark Wielaard wrote:
> Finally I am interested in your proposal to implement a different way
> to reduce the size of DIE trees by eliminating "unused" DIEs. It is
> hard to predict what effect that would have without seeing an
> implementation (in theory
Hi Jan,
On Fri, 2020-09-25 at 11:43 +0200, Jan Kratochvil wrote:
> On Fri, 25 Sep 2020 01:35:43 +0200, Mark Wielaard wrote:
> > Replying since I am mentioned by name in this proposal and it seems to
> > argue for removing a feature I am currently working on to make sure it
> > works correctly
Thanks Jan,
I had subsequently discovered your COPR, which does work with the DWZ symbols
and allow debugging, however your version is missing Swift support, and so
doesn't support Swift function name demangling and variable display etc.
+1 for moving to -fdebug-types-section anyway.
Regards,
On Fri, 25 Sep 2020 16:29:26 +0200, Jan Kratochvil wrote:
> On Fri, 25 Sep 2020 12:10:22 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > - debuginfo with dwz (current approach)
>
> rpm size: 35186079102
> disk size: 177913332940
>
> > - debuginfo with -fdebug-types-section
>
> rpm size:
> > That is orthogonal - that is one can add it to DWZ or -fdebug-types-section
> > the same way. It would be for another Fedora Change proposal but I do not
> > think it matters for F-33 as it already implements:
> > https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression
I added
On Fri, 25 Sep 2020 17:40:50 +0200, Florian Weimer wrote:
> The numbers are very difficult understand because it's not clear what
> you are measuring. Especially since as far I understand it, parts are
> not yet fully implemented, so we can't know yet if all the required data
> is there.
TL;DR
* Jan Kratochvil:
> On Fri, 25 Sep 2020 17:09:54 +0200, Robbie Harwood wrote:
>> So saying "Google does it" (or similar) is *not* a good argument.
>
> So let's stick only to the numbers I sent in other mails.
> In fact I do not understand why we talk about anything except the
> numbers.
The
On Fri, 25 Sep 2020 17:09:54 +0200, Robbie Harwood wrote:
> So saying "Google does it" (or similar) is *not* a good argument.
So let's stick only to the numbers I sent in other mails.
In fact I do not understand why we talk about anything except the numbers.
Jan
* Robbie Harwood:
> Jan Kratochvil writes:
>
>> So why is Google using it for everything?
>
> If I could eliminate one bad thought pattern in software design it would
> probably be this one.
>
> In brief: you are not Google, nor are you Facebook, nor Amazon. Your
> problems are not their
Jan Kratochvil writes:
> So why is Google using it for everything?
If I could eliminate one bad thought pattern in software design it would
probably be this one.
In brief: you are not Google, nor are you Facebook, nor Amazon. Your
problems are not their problems. Your use case is not their
On Fri, 25 Sep 2020 12:10:22 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> I'm missing some good statistics.
I have 1.6TB of statistics, ask me anything. It is calculated by my scripts:
https://git.jankratochvil.net/?p=massrebuild.git;a=tree
git clone
On Fri, 25 Sep 2020 13:43:40 +0200, Neal Gompa wrote:
> On Fri, Sep 25, 2020 at 7:26 AM Ryan wrote:
> >
> > > == Benefit to Fedora ==
> > > * Better compatibility with existing debugging and tracing tools,
> > > primarily [https://lldb.llvm.org/ LLDB].
> >
> > Thanks for your work on this Ben and
On Fri, 25 Sep 2020 13:56:47 +0200, Jakub Jelinek wrote:
> Jan had probably problems getting his DWZ support upstreamed into LLDB
It isn't completely easy, I have already upstreamed a lot of preparatory work
for the DWZ patchset which is good for LLDB in general.
Just before upstreaming the
On Fri, 25 Sep 2020 07:08:27 +0200, Dominique Martinet wrote:
> Jan Kratochvil wrote on Thu, Sep 24, 2020:
> > Copy-pasted it at the bottom of this mail. I do not know the talk but TL;DR
> > existing DWARF contains some dead DIEs - unused/deduplicated functions and
> > also
> >
On Thu, Sep 24, 2020 at 11:59:44AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DebugInfoStandardization
>
> == Summary ==
> Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did
> not get widespread and the tool is not much maintained it became
> burden to
On Fri, Sep 25, 2020 at 7:26 AM Ryan wrote:
>
> > == Benefit to Fedora ==
> > * Better compatibility with existing debugging and tracing tools,
> > primarily [https://lldb.llvm.org/ LLDB].
>
> Thanks for your work on this Ben and Jan, Just as an interested user, use of
> the DWZ format
> == Benefit to Fedora ==
> * Better compatibility with existing debugging and tracing tools,
> primarily [https://lldb.llvm.org/ LLDB].
Thanks for your work on this Ben and Jan, Just as an interested user, use of
the DWZ format significantly limits Swift development on Fedora, as it is
I'm missing some good statistics.
> * DWZ advantage: On the whole Fedora distro it saves 3.3% (5GB of the
> 157GB distribution size)
What is this comparing? Is this the size of binary rpm or the
installation-on-disk footprint?
I would love to see a comparison of numbers for three things:
- raw
On Fri, 25 Sep 2020 11:36:47 +0200, Mark Wielaard wrote:
> On Thu, Sep 24, 2020 at 08:34:48PM +0200, Jan Kratochvil wrote:
> > error: Allocatable section after non-allocatable ones
> > https://sourceware.org/bugzilla/show_bug.cgi?id=24251#c10
>
> That isn't a longterm unfixed bug.
It
On Fri, 25 Sep 2020 01:35:43 +0200, Mark Wielaard wrote:
> Replying since I am mentioned by name in this proposal and it seems to
> argue for removing a feature I am currently working on to make sure it
> works correctly with GCC11 if it switches to producing DWARF5 by
> default.
The problem is
On Fri, 25 Sep 2020 11:01:53 +0200, Neal Gompa wrote:
> On Fri, Sep 25, 2020 at 3:08 AM Florian Weimer wrote:
> > This is not a -dbgsym package, so it probably has been created by a
> > different procedure. I do not know how Ubuntu distributes their -dbgsym
> > packages. An example from Debian
On Thu, Sep 24, 2020 at 08:34:48PM +0200, Jan Kratochvil wrote:
> > The tool is not easily maintained,
>
> I did not mention it there but it is true there are some longterm unfixed
> bugs in DWZ so that it gives up on optimization of many builds:
> error: Allocatable section after
On Fri, Sep 25, 2020 at 3:08 AM Florian Weimer wrote:
>
> * Jan Kratochvil:
>
> > On Thu, 24 Sep 2020 19:16:32 +0200, Neal Gompa wrote:
> >> Then that certainly means that Ubuntu uses this too, since they reuse
> >> the dbgsym subpackage generation for the ddeb system they have now.
> >
> > I am
* Jan Kratochvil:
> On Thu, 24 Sep 2020 19:16:32 +0200, Neal Gompa wrote:
>> Then that certainly means that Ubuntu uses this too, since they reuse
>> the dbgsym subpackage generation for the ddeb system they have now.
>
> I am not much familiar with Debian/Ubuntu but I cannot find any use of DWZ
Jan Kratochvil wrote on Thu, Sep 24, 2020:
> > That talk doesn't load for me, sorry if I ask something answered in
> > there.
>
> I have added a title there now but the URL loads for me even in lynx+wget.
Yeah sorry it finally loaded after 10+ minutes, that was weird.
> Copy-pasted it at the
Hi,
Replying since I am mentioned by name in this proposal and it seems to
argue for removing a feature I am currently working on to make sure it
works correctly with GCC11 if it switches to producing DWARF5 by
default. The proposal seems based on some misunderstandings.
On Thu, Sep 24, 2020 at
Ben Cotton wrote on Thu, Sep 24, 2020:
> ** If the 3.3% size increase is a concern I can implement a different
> optimization ([https://whova.com/embedded/session/llvm_202010/1193947/
> talk (2)]) as a GCC post-processing phase which would require no
> changes in any DWARF consumers.
That talk
On Thu, 24 Sep 2020 20:04:22 +0200, Stephen John Smoogen wrote:
> The original language of the proposal said no other distribution used DWZ,
> and that the format was not adopted and should be removed.
I have already updated the Wiki in the meantime based on new information from
this list:
On Thu, 24 Sep 2020 20:10:45 +0200, Neal Gompa wrote:
> I do not feel that this is a valid premise either, since the reason
> for no dwz support in LLDB is because nobody contributed it.
> I'm slightly surprised that Red Hat's debuginfo engineers hadn't already
> contributed support for it into
On Thu, Sep 24, 2020 at 2:04 PM Stephen John Smoogen wrote:
>
>
>
> On Thu, 24 Sep 2020 at 13:44, Jan Kratochvil
> wrote:
>>
>> On Thu, 24 Sep 2020 19:16:32 +0200, Neal Gompa wrote:
>> > Then that certainly means that Ubuntu uses this too, since they reuse
>> > the dbgsym subpackage generation
On Thu, 24 Sep 2020 at 13:44, Jan Kratochvil
wrote:
> On Thu, 24 Sep 2020 19:16:32 +0200, Neal Gompa wrote:
> > Then that certainly means that Ubuntu uses this too, since they reuse
> > the dbgsym subpackage generation for the ddeb system they have now.
>
> I am not much familiar with
On Thu, 24 Sep 2020 19:16:32 +0200, Neal Gompa wrote:
> Then that certainly means that Ubuntu uses this too, since they reuse
> the dbgsym subpackage generation for the ddeb system they have now.
I am not much familiar with Debian/Ubuntu but I cannot find any use of DWZ
there:
On Thu, Sep 24, 2020 at 1:13 PM Peter Pentchev wrote:
>
> On Thu, Sep 24, 2020 at 01:01:17PM -0400, Neal Gompa wrote:
> > On Thu, Sep 24, 2020 at 12:00 PM Ben Cotton wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/DebugInfoStandardization
> > >
> > > == Summary ==
> > > Fedora 18
On Thu, 24 Sep 2020 19:01:17 +0200, Neal Gompa wrote:
> This is not true. Debian started producing -dbgsym packages and
> putting them in a separate repository years ago:
> https://wiki.debian.org/AutomaticDebugPackages
>
> dwz is used by virtually all RPM based distributions now, including
>
On Thu, Sep 24, 2020 at 01:01:17PM -0400, Neal Gompa wrote:
> On Thu, Sep 24, 2020 at 12:00 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/DebugInfoStandardization
> >
> > == Summary ==
> > Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did
> > not get
On Thu, Sep 24, 2020 at 12:00 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/DebugInfoStandardization
>
> == Summary ==
> Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did
> not get widespread and the tool is not much maintained it became
> burden to make
71 matches
Mail list logo
