On Tue, Jan 15, 2013 at 6:53 PM, Jan Kratochvil wrote:
> On Tue, 15 Jan 2013 11:09:46 +0100, Steven Bosscher wrote:
>> Unless someone can shoot holes in this test approach,
>
> While the sum of *.o files sizes may make sense in some cases I would find
> more useful to measure it only for the final
On Tue, 15 Jan 2013 11:09:46 +0100, Steven Bosscher wrote:
> Unless someone can shoot holes in this test approach,
While the sum of *.o files sizes may make sense in some cases I would find
more useful to measure it only for the final executables and after they have
been processed by dwz.
Besides
Hello,
In this stabs vs. dwarf discussion, so far it's more been about
assumptions than numbers. So let's throw in some numbers!
The following debug sizes are for CSiBE-v2.1.1 on mipsisa64-elf, with
the LRA branch at r195108. All CSiBE test cases are packages written
in C.
Debug size is computed
> Then it is expected that dwarf debug is much bigger than stabs debug,
> since the latter does not include any of the value tracking capabilities
> of dwarf. Without that it is almost impossible for a debugger to
> display the true value of local variables.
Indeed. And it would be interesting t
David Taylor writes:
> Optimized, -O2.
Then it is expected that dwarf debug is much bigger than stabs debug,
since the latter does not include any of the value tracking capabilities
of dwarf. Without that it is almost impossible for a debugger to
display the true value of local variables.
Andr
On Mon, 14 Jan 2013 17:12:25 +0100, Doug Evans wrote:
> Not that I think it's a priori worth the effort to dig deeper, but for
> another datapoint, Redhat added an lza-compressed mini-dwarf-debug
> section. I'm not sure what it supports (if anything beyond making
> backtraces better).
It can cont
>> Next, I compiled a 5000-line C++ source file at both -O0 and -O2.
>
> I have to assume that David is working with C code, as stabs debugging
> for C++ is nearly unusable.
I assumed that too, but I figured C++ would be worse than C as far as
DWARF vs. stabs size. I'd still be interested to figur
Andreas Schwab wrote:
> David Taylor writes:
>
> > {As to what d90f.elf is -- that's unimportant; but, it's the kernel for
> > one of the boards in one of our hardware products.]
>
> Is it an optimized or an unoptimized build?
Optimized, -O2. According to find piped to wc, there's 2587 C fil
On Fri, Jan 11, 2013 at 6:55 PM, Cary Coutant wrote:
>>> If I use objcopy --compress-debug-sections to compress the DWARF debug
>>> info (but don't use it on the STABS debug info), then the file size
>>> ratio is 3.4.
>>>
>>> While 3.4 is certainly better than 11.5, unless I can come up with a
>>>
On Fri, Jan 11, 2013 at 7:17 PM, Ian Lance Taylor wrote:
> On Fri, Jan 11, 2013 at 5:55 PM, Cary Coutant wrote:
>>
>> Next, I compiled a 5000-line C++ source file at both -O0 and -O2.
>
> I have to assume that David is working with C code, as stabs debugging
> for C++ is nearly unusable.
That wa
David Taylor writes:
> {As to what d90f.elf is -- that's unimportant; but, it's the kernel for
> one of the boards in one of our hardware products.]
Is it an optimized or an unoptimized build?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01
On Fri, Jan 11, 2013 at 5:55 PM, Cary Coutant wrote:
>
> Next, I compiled a 5000-line C++ source file at both -O0 and -O2.
I have to assume that David is working with C code, as stabs debugging
for C++ is nearly unusable.
Ian
>> If I use objcopy --compress-debug-sections to compress the DWARF debug
>> info (but don't use it on the STABS debug info), then the file size
>> ratio is 3.4.
>>
>> While 3.4 is certainly better than 11.5, unless I can come up with a
>> solution where the ratio is less than 2, I'm not currently
On Fri, Jan 11, 2013 at 6:52 AM, David Taylor wrote:
> Doug Evans wrote:
>> So while plain dwarf may be 8-12x of stabs, progress has been made,
>> and we shouldn't base decisions on incomplete analyses.
>
> ...
>
> If I use objcopy --compress-debug-sections to compress the DWARF debug
> info (but
Doug Evans wrote:
> On Thu, Jan 3, 2013 at 9:52 AM, nick clifton wrote:
> >> Switching to DWARF causes our build products directory (which contains
> >> *NONE* of the intermediate files) to swell from 1.2 GB to 11.5 GB.
> >> Ouch! The DWARF ELF files are 8-12 times the size of the STABS ELF
> >
> Okay. If there is no direct use of TLS in GNAT, then testing with the
> new support would not provide any additional feedback and sanity
> checks of the support.
Right.
On Tue, Jan 8, 2013 at 9:46 AM, Arnaud Charlet wrote:
> We haven't done any work to support TLS in gnu as/ld on AIX (other
> than ignore these sections for now to avoid generating hard errors), so
> enabling TLS in GCC would indeed cause some troubles, although we don't
> use TLS directly in GNAT
> It would be helpful for Adacore to contribute the support upstream
> into the FSF tree, not only to make GNU Binutils more useful on AIX
> but to avoid others duplicating your work -- especially in
> incompatible ways.
Indeed.
> The large TOC feature (cmodel=large) is not used by default and th
On Tue, Jan 8, 2013 at 3:10 AM, Joel Brobecker wrote:
> I was able to speak to Tristan, yesterday, and he confirmed that
> we haven't been able to contribute a few of the patches he wrote.
> Unfortunately, his TODO list is more than full, at the moment, and
> we don't think he'll have time to work
I was able to speak to Tristan, yesterday, and he confirmed that
we haven't been able to contribute a few of the patches he wrote.
Unfortunately, his TODO list is more than full, at the moment, and
we don't think he'll have time to work on that for a while. I might
have time in the next few weeks t
> I and others have not been able to use GNU as and GNU ld to bootstrap
> GCC. The resulting object files and shared objects mostly worked in
> small experiments, but failed for larger projects, like GCC.
>
> Also, GNU as and GNU ld do not contain support for the new
> cmodel=large and thread loca
On Sat, Jan 5, 2013 at 9:52 AM, Joel Brobecker wrote:
>> It does not look like the changes were merged into the FSF tree. This
>> also does not support some of the more recent AIX features added to
>> GCC.
>
> Tristan is usually pretty good at sending these sorts of patches.
> I will ask him on M
> It does not look like the changes were merged into the FSF tree. This
> also does not support some of the more recent AIX features added to
> GCC.
Tristan is usually pretty good at sending these sorts of patches.
I will ask him on Monday if some might be missing. He's been
extremely busy lately
On Sat, Jan 5, 2013 at 2:53 AM, Joel Brobecker wrote:
>> > Can you please clarify what "GNU ld is not completely usable" means?
>> > Is that referring to DWARF support? to compatibility with specific AIX
>> > releases? to compatibility with AIX DWARF feature?
>>
>> Sorry, I meant what "GNU ld is n
> > Can you please clarify what "GNU ld is not completely usable" means?
> > Is that referring to DWARF support? to compatibility with specific AIX
> > releases? to compatibility with AIX DWARF feature?
>
> Sorry, I meant what "GNU ld is now completely usable" means because I
> believe that it act
On Fri, Jan 4, 2013 at 3:20 PM, David Edelsohn wrote:
> On Thu, Jan 3, 2013 at 11:12 PM, Joel Brobecker wrote:
>>> AIX still uses STABS. GCC produces it and GDB consumes it.
>>>
>>> Recent releases of AIX now support DWARF as well, but GCC and GDB have
>>> not been converted to use it on AIX.
>>
On Thu, Jan 3, 2013 at 11:12 PM, Joel Brobecker wrote:
>> AIX still uses STABS. GCC produces it and GDB consumes it.
>>
>> Recent releases of AIX now support DWARF as well, but GCC and GDB have
>> not been converted to use it on AIX.
>
> Note that GNU ld is now completely usable; and one of the s
> AIX still uses STABS. GCC produces it and GDB consumes it.
>
> Recent releases of AIX now support DWARF as well, but GCC and GDB have
> not been converted to use it on AIX.
Note that GNU ld is now completely usable; and one of the side
effects of using GNU ld is the ability to switch over to D
On Thu, Jan 3, 2013 at 9:52 AM, nick clifton wrote:
>> Switching to DWARF causes our build products directory (which contains
>> *NONE* of the intermediate files) to swell from 1.2 GB to 11.5 GB.
>> Ouch! The DWARF ELF files are 8-12 times the size of the STABS ELF
>> files.
>>
>> If the DWARF fi
On Thu, Jan 3, 2013 at 4:53 PM, Jonas Maebe wrote:
>
> On 03 Jan 2013, at 21:53, David Edelsohn wrote:
>
>> AIX still uses STABS. GCC produces it and GDB consumes it.
>
> More precisely, AIX uses Stabx. It's similar to Stabs, but different in quite
> a few ways. To add to the confusion, GCC prod
On 03 Jan 2013, at 21:53, David Edelsohn wrote:
> AIX still uses STABS. GCC produces it and GDB consumes it.
More precisely, AIX uses Stabx. It's similar to Stabs, but different in quite a
few ways. To add to the confusion, GCC produces and GDB consumes a hybrid of
Stabs and Stabx on AIX for
On Thu, Jan 3, 2013 at 12:02 PM, Tom Tromey wrote:
>> "David" == David Taylor writes:
>
> David> It appears that STABS is largely in maintenance mode. Are there any
> David> plans to deprecate STABS support? If STABS enhancements were made and
> David> posted would they be frowned upon? Or
> "David" == David Taylor writes:
David> It appears that STABS is largely in maintenance mode. Are there any
David> plans to deprecate STABS support? If STABS enhancements were made and
David> posted would they be frowned upon? Or would they be reviewed for
David> possible inclusion in a f
Hi David,
What is the status of STABS support?
Essentially it is in maintenance mode. But this is due to lack of
developers interested in extending STABS support, rather than a policy
of maintenance-only.
Are there any plans to deprecate STABS support?
No, none.
If STABS enhancemen
> What is the status of STABS support?
In terms of GDB, it is no longer actively maintained. But if you
submit patches, I will do my best to review them.
--
Joel
On Thu, Jan 3, 2013 at 5:21 PM, David Taylor wrote:
> What is the status of STABS support?
>
> I know that there is considerably more activity around DWARF than STABS.
> It appears that STABS is largely in maintenance mode. Are there any
> plans to deprecate STABS support? If STABS enhancements
What is the status of STABS support?
I know that there is considerably more activity around DWARF than STABS.
It appears that STABS is largely in maintenance mode. Are there any
plans to deprecate STABS support? If STABS enhancements were made and
posted would they be frowned upon? Or would the
37 matches
Mail list logo
