Sorry for not responding sooner.
Thanks Martin.
Like Joel we have a third party solution to instrumentation. Part of
my objection to the third party solution is freedom. There are
customizations we would like, but not having source we're at the mercy
of the vendor both for whether it gets done
I wish to use GCC based instrumentation on an embedded target. And I
am finding that GCC's libgcov.a is not well suited to my needs.
Ideally, all the application entry points and everthing that knows
about the internals of the implementation would be in separate files
from everything that does i/
Sorry for the late reply. Your message never arrived in my mailbox.
I suspect that corporate email has swallowed it for some stupid
reason. I'm replying to a copy I found in the mailing list archives
at gcc dot gnu dot org. Hopefully I didn't screw up the editing.
From: Richard Biener
Steven Bosscher wrote:
> On Tue, 14 May 2013 10:38:02 -0400, David Taylor wrote:
> > There are other reasons besides the DWARF verboseness, but they are
> > solvable. The verboseness (over 10x increase in the size of the elf
> > file) is a show stopper.
>
> People
Jakub Jelinek wrote:
> On Mon, May 13, 2013 at 10:45:46AM -0400, David Taylor wrote:
> > There are problems when using current STABS debug format for 64 bit
> > targets.
>
> Why are you considering extending STABS at this point?
> STABS support might very well be dropped
o GCC, BINUTILS, and GDB.
David
--
David Taylor
dtay...@emc.com
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 t
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
> >
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
At EMC we have a version of GCC which targets the x86 with a non
standard ABI -- it produces code for 64 bit mode mode, but with types
having the 32 bit ABI sizes. So, ints, longs, and pointers are 32
bits -- that is, it's ILP32 rather than LP64 -- but with the chip in
64 bit mode.
Actually, poin
> Date: Thu, 16 Mar 2006 18:51:59 -0800 (PST)
> From: Alexey Starovoytov <[EMAIL PROTECTED]>
>
> On Thu, 16 Mar 2006, Joel Sherrill wrote:
> It seems everybody agreed that solaris 10+ can be changed to -mcpu=v9 default.
> Great!
> What are the thoughts about Solaris 7,8,9 ?
>
> They don't run on
ith it with-regard-to warning
XYZ, please be quiet" would be very valuable.
Based on Gaby's comments, it sounds like fine-grained control would be
a much bigger project.
David
--
David Taylor
[EMAIL PROTECTED]
> Date: Mon, 9 Jan 2006 11:13:22 -0800
> From: Joe Buck <[EMAIL PROTECTED]>
>
> On Mon, Jan 09, 2006 at 01:46:21PM -0500, David Taylor wrote:
> > For a variety of reasons, we would like to be able to specify
> > individual compilation switches *within* individual fi
s -- from a security perspective. And probably a command line
option to enable / disable support for the pragma at all.
Comments?
David
--
David Taylor
[EMAIL PROTECTED]
> From: Jeffrey A Law <[EMAIL PROTECTED]>
> Date: Wed, 02 Nov 2005 19:17:06 -0700
>
> On Wed, 2005-11-02 at 20:44 -0500, Daniel Jacobowitz wrote:
> > People who use -Wall -Werror are _already_ pissed off about
> > -Wuninitialized. It virtually guarantees that your build will fail on
> > a new re
15 matches
Mail list logo
