On Fri, Oct 25, 2019 at 1:52 AM Indu Bhagat wrote:
>
>
>
> On 10/11/2019 04:41 AM, Jakub Jelinek wrote:
> > On Fri, Oct 11, 2019 at 01:23:12PM +0200, Richard Biener wrote:
> >>> (coreutils-0.22)
> >>>.debug_info(D1) | .debug_abbrev(D2) | .debug_str(D4) | .ctf
> >>> (uncompressed) | ratio
On 10/11/2019 04:41 AM, Jakub Jelinek wrote:
On Fri, Oct 11, 2019 at 01:23:12PM +0200, Richard Biener wrote:
(coreutils-0.22)
.debug_info(D1) | .debug_abbrev(D2) | .debug_str(D4) | .ctf
(uncompressed) | ratio (.ctf/(D1+D2+0.5*D4))
ls 30616 |1136 |21098
On 18 Oct 2019, Pedro Alves stated:
> On 10/18/19 2:21 PM, Richard Biener wrote:
>
In most cases local types etc are a fairly small contributor to the
total volume -- but macros can contribute a lot in some codebases.
>>> (The
Linux kernel's READ_ONCE macro is one I've personally be
On 10/18/19 2:21 PM, Richard Biener wrote:
>>> In most cases local types etc are a fairly small contributor to the
>>> total volume -- but macros can contribute a lot in some codebases.
>> (The
>>> Linux kernel's READ_ONCE macro is one I've personally been bitten by
>> in
>>> the past, with a new
On October 18, 2019 1:59:36 PM GMT+02:00, Pedro Alves wrote:
>On 10/17/19 7:59 PM, Nick Alcock wrote:
>> On 17 Oct 2019, Richard Biener verbalised:
>>
>>> On Thu, Oct 17, 2019 at 7:36 PM Nick Alcock
>wrote:
On 11 Oct 2019, Indu Bhagat stated:
> Compile with -g -gdwarf-like-ctf and
On 10/17/19 7:59 PM, Nick Alcock wrote:
> On 17 Oct 2019, Richard Biener verbalised:
>
>> On Thu, Oct 17, 2019 at 7:36 PM Nick Alcock wrote:
>>>
>>> On 11 Oct 2019, Indu Bhagat stated:
Compile with -g -gdwarf-like-ctf and use dwz -o
(using
dwz compiled from the master branch) on
On 10/17/19 6:36 PM, Nick Alcock wrote:
> A side note here: the sizes given above are uncompressed sizes, but in
> the real world CTF is almost always compressed: the threshold for
> compression is in theory customizable but at the moment is hardwired at
> 4KiB-uncompressed in the linker. I usually
On 17 Oct 2019, Richard Biener verbalised:
> On Thu, Oct 17, 2019 at 7:36 PM Nick Alcock wrote:
>>
>> On 11 Oct 2019, Indu Bhagat stated:
>> > Compile with -g -gdwarf-like-ctf and use dwz -o
>> > (using
>> > dwz compiled from the master branch) on the generated binaries:
>> >
>> > (coreutils-0
On Thu, Oct 17, 2019 at 7:36 PM Nick Alcock wrote:
>
> On 11 Oct 2019, Indu Bhagat stated:
> > Compile with -g -gdwarf-like-ctf and use dwz -o (using
> > dwz compiled from the master branch) on the generated binaries:
> >
> > (coreutils-0.22)
> > .debug_info(D1) | .debug_abbrev(D2) | .debug
On 11 Oct 2019, Indu Bhagat stated:
> Compile with -g -gdwarf-like-ctf and use dwz -o (using
> dwz compiled from the master branch) on the generated binaries:
>
> (coreutils-0.22)
> .debug_info(D1) | .debug_abbrev(D2) | .debug_str(D4) | .ctf
> (uncompressed) | ratio (.ctf/(D1+D2+0.5*D4))
>
On 9 Oct 2019, Indu Bhagat told this:
> Yes, CTF does not support C++ at this time. To cover all of C (including
> GNU C extensions), we need to add representation for things like Vector type,
> non IEEE float etc. (somewhat infrequently occurring constructs)
One note: adding C++ support will not
On 10/11/2019 04:23 AM, Richard Biener wrote:
Thanks for your pointers.
CTF does not encode location information. So, I used early exit in the
add_src_coords_attributes to avoid generation of location info (file, line,
column). To answer Richard's question, CTF does have type debug info
for f
On Fri, Oct 11, 2019 at 01:23:12PM +0200, Richard Biener wrote:
> > (coreutils-0.22)
> > .debug_info(D1) | .debug_abbrev(D2) | .debug_str(D4) | .ctf
> > (uncompressed) | ratio (.ctf/(D1+D2+0.5*D4))
> > ls 30616 |1136 |21098 | 26240
> > | 0.6
On Fri, Oct 11, 2019 at 1:06 AM Indu Bhagat wrote:
>
>
>
> On 10/09/2019 12:49 AM, Jakub Jelinek wrote:
> > On Wed, Oct 09, 2019 at 09:41:09AM +0200, Richard Biener wrote:
> >> There's a mechanism to get type (and decl - I suppose CTF also
> >> contains debug info
> >> for function declarations no
On 10/09/2019 12:49 AM, Jakub Jelinek wrote:
On Wed, Oct 09, 2019 at 09:41:09AM +0200, Richard Biener wrote:
There's a mechanism to get type (and decl - I suppose CTF also
contains debug info
for function declarations not only its type?) info as part of early
debug generation.
The attached "h
On Tue, Oct 08, 2019 at 10:26:13PM -0700, Indu Bhagat wrote:
> The justification for CTF is and will remain - a compact, faster debug
> format
> for type information and support some online debugging use-cases (like
> backtraces) in future.
Approximate backtraces, sure. (It cannot know if anothe
On Wed, Oct 09, 2019 at 09:41:09AM +0200, Richard Biener wrote:
> There's a mechanism to get type (and decl - I suppose CTF also
> contains debug info
> for function declarations not only its type?) info as part of early
> debug generation.
> The attached "hack" simply mangles dwarf2out to output t
On Wed, Oct 9, 2019 at 7:26 AM Indu Bhagat wrote:
>
>
>
> On 10/08/2019 08:37 AM, Pedro Alves wrote:
> > On 10/4/19 8:23 PM, Indu Bhagat wrote:
> >> Hello,
> >>
> >> At GNU Tools Cauldron this year, some folks were curious to know more on
> >> how
> >> the "type representation" in CTF compares vi
On 10/08/2019 08:37 AM, Pedro Alves wrote:
On 10/4/19 8:23 PM, Indu Bhagat wrote:
Hello,
At GNU Tools Cauldron this year, some folks were curious to know more on how
the "type representation" in CTF compares vis-a-vis DWARF.
I was one of those, and I brought this up to Jose, after your
pres
On 10/4/19 8:23 PM, Indu Bhagat wrote:
> Hello,
>
> At GNU Tools Cauldron this year, some folks were curious to know more on how
> the "type representation" in CTF compares vis-a-vis DWARF.
I was one of those, and I brought this up to Jose, after your
presentation. Glad to see the follow up! Th
On Mon, Oct 7, 2019 at 4:47 PM Indu Bhagat wrote:
> On 10/07/2019 12:35 AM, Richard Biener wrote:
> > On Fri, Oct 4, 2019 at 9:12 PM Indu Bhagat
> wrote:
> >> Hello,
> >>
> >> At GNU Tools Cauldron this year, some folks were curious to know more
> on how
> >> the "type representation" in CTF com
On 10/07/2019 12:35 AM, Richard Biener wrote:
On Fri, Oct 4, 2019 at 9:12 PM Indu Bhagat wrote:
Hello,
At GNU Tools Cauldron this year, some folks were curious to know more on how
the "type representation" in CTF compares vis-a-vis DWARF.
[...]
So, for the small C testcase with a union, e
On Fri, Oct 4, 2019 at 9:12 PM Indu Bhagat wrote:
>
> Hello,
>
> At GNU Tools Cauldron this year, some folks were curious to know more on how
> the "type representation" in CTF compares vis-a-vis DWARF.
>
> I use small testcase below to gather some numbers to help drive this
> discussion.
>
> [ib
Hello,
At GNU Tools Cauldron this year, some folks were curious to know more on how
the "type representation" in CTF compares vis-a-vis DWARF.
I use small testcase below to gather some numbers to help drive this discussion.
[ibhagat@ibhagatpc ctf-size]$ cat ctf_sizeme.c
#define MAX_NUM_MSGS 5
24 matches
Mail list logo
