Il 26/06/2014 15:16, Rainer Orth ha scritto:
Hi Gerald,
sorry for the delay, I've been away for a couple of days.
On Tue, 3 Jun 2014, Rainer Orth wrote:
It's been another week, and I still need approval for the build, doc,
and Darwin changes:
On Thu, Jun 26, 2014 at 6:32 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Eric Christopher echri...@gmail.com writes:
If it is just to reach compatibility with the debugger, then I’d rather
either just mandate a certain debugger or autoconf for what the current
debugger supports. As
Hi Gerald,
sorry for the delay, I've been away for a couple of days.
On Tue, 3 Jun 2014, Rainer Orth wrote:
It's been another week, and I still need approval for the build, doc,
and Darwin changes:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01860.html
On the doc side, things are
Eric Christopher echri...@gmail.com writes:
If it is just to reach compatibility with the debugger, then I’d rather
either just mandate a certain debugger or autoconf for what the current
debugger supports. As of late people seem to just break the debugging
experience with non-updated gdbs
Mike Stump mikest...@comcast.net writes:
On Jun 3, 2014, at 3:40 AM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote:
It's been another week, and I still need approval for the build, doc,
and Darwin changes:
So, the darwin bits look trivial enough, if the entire scheme is what
people want
On Jun 4, 2014, at 1:54 AM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote:
Mike Stump mikest...@comcast.net writes:
On Jun 3, 2014, at 3:40 AM, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
It's been another week, and I still need approval for the build, doc,
and Darwin changes:
So,
If it is just to reach compatibility with the debugger, then I’d rather
either just mandate a certain debugger or autoconf for what the current
debugger supports. As of late people seem to just break the debugging
experience with non-updated gdbs and assume that a newer gdb is used.
You
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
Joseph S. Myers jos...@codesourcery.com writes:
[...]
Thanks for the explanation. The driver changes are OK.
Thanks. I still need approval for the doc and build parts, as well as
the Darwin and DJGPP changes. For the latter two, I've
On Jun 3, 2014, at 3:40 AM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote:
It's been another week, and I still need approval for the build, doc,
and Darwin changes:
So, the darwin bits look trivial enough, if the entire scheme is what people
want to do. My question would be, why do we want
On Tue, 3 Jun 2014, Rainer Orth wrote:
It's been another week, and I still need approval for the build, doc,
and Darwin changes:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01860.html
On the doc side, things are fine.
Just a suggestion or two:
+Produce compressed debug sections in
Joseph S. Myers jos...@codesourcery.com writes:
On Thu, 22 May 2014, Rainer Orth wrote:
Joseph S. Myers jos...@codesourcery.com writes:
On Thu, 22 May 2014, Rainer Orth wrote:
* common.opt (compressed_debug_sections): New enum.
(gz, gz=): New options.
* opts.c
Thanks. I still need approval for the doc and build parts, as well
as the Darwin and DJGPP changes. For the latter two, I've included
the
I'll approve the DJGPP change, despite the segv. I suspect it's
unrelated.
Joseph S. Myers jos...@codesourcery.com writes:
[Sorry for dropping the ball on this for so long.]
I still have no idea from your answer how a user is meant to know whether
to use the option when compiling, linking or both, which is what needs to
be clear from invoke.texi.
What does it
On Thu, 22 May 2014, Rainer Orth wrote:
* common.opt (compressed_debug_sections): New enum.
(gz, gz=): New options.
* opts.c (common_handle_option): Handle OPT_gz, OPT_gz_.
Given that the options are completely handled via specs, why can't they
just be Driver options
Joseph S. Myers jos...@codesourcery.com writes:
On Thu, 22 May 2014, Rainer Orth wrote:
* common.opt (compressed_debug_sections): New enum.
(gz, gz=): New options.
* opts.c (common_handle_option): Handle OPT_gz, OPT_gz_.
Given that the options are completely handled via
On Thu, 22 May 2014, Rainer Orth wrote:
Joseph S. Myers jos...@codesourcery.com writes:
On Thu, 22 May 2014, Rainer Orth wrote:
* common.opt (compressed_debug_sections): New enum.
(gz, gz=): New options.
* opts.c (common_handle_option): Handle OPT_gz, OPT_gz_.
Given
Hi Joseph,
I still have no idea from your answer how a user is meant to know whether
to use the option when compiling, linking or both, which is what needs to
be clear from invoke.texi.
What does it mean for the option to be supported for compiling but not
linking? What in that case
I still have no idea from your answer how a user is meant to know whether
to use the option when compiling, linking or both, which is what needs to
be clear from invoke.texi.
What does it mean for the option to be supported for compiling but not
linking? What in that case will the linker do
Joseph S. Myers jos...@codesourcery.com writes:
On Tue, 30 Apr 2013, Rainer Orth wrote:
* gcc.c (LINK_COMPRESS_DEBUG_SPEC, ASM_COMPRESS_DEBUG_SPEC):
Define.
(LINK_COMMAND_SPEC): Invoke LINK_COMPRESS_DEBUG_SPEC.
(asm_options): Invoke ASM_COMPRESS_DEBUG_SPEC.
Note that
On Tue, 30 Apr 2013, Rainer Orth wrote:
* gcc.c (LINK_COMPRESS_DEBUG_SPEC, ASM_COMPRESS_DEBUG_SPEC):
Define.
(LINK_COMMAND_SPEC): Invoke LINK_COMPRESS_DEBUG_SPEC.
(asm_options): Invoke ASM_COMPRESS_DEBUG_SPEC.
Note that there are separate copies of LINK_COMMAND_SPEC
Joseph S. Myers jos...@codesourcery.com writes:
On Thu, 11 Apr 2013, Rainer Orth wrote:
+gz=
+Common Driver JoinedOrMissing
+-gz=formatGenerate compressed debug sections in format format
Although handled entirely in specs, I think it's best to use the Enum .opt
facility to list
On Thu, 11 Apr 2013, Rainer Orth wrote:
+gz=
+Common Driver JoinedOrMissing
+-gz=format Generate compressed debug sections in format format
Although handled entirely in specs, I think it's best to use the Enum .opt
facility to list the valid arguments to this option, so the option
handling
There's some interest inside Oracle to support compressed debug sections
inside their toolchain, both on Solaris and Linux. So far, there's the
GNU style supported by gas, gld, gold, and gdb, which mangles section
names (.debug_* - .zdebug_*), but consultation with the Solaris linker
engineers
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
There's some interest inside Oracle to support compressed debug sections
inside their toolchain, both on Solaris and Linux. So far, there's the
GNU style supported by gas, gld, gold, and gdb, which mangles section
names (.debug_* -
Andi Kleen a...@firstfloor.org writes:
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
There's some interest inside Oracle to support compressed debug sections
inside their toolchain, both on Solaris and Linux. So far, there's the
GNU style supported by gas, gld, gold, and gdb, which
25 matches
Mail list logo
