On Thu, Jun 26, 2014 at 6:32 AM, Rainer Orth
wrote:
> Eric Christopher 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
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:
https://gcc.gnu.org/ml/gcc-patches/2014-0
Eric Christopher 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 and assu
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, t
>> 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.
>
On Jun 4, 2014, at 1:54 AM, Rainer Orth wrote:
> Mike Stump writes:
>> On Jun 3, 2014, at 3:40 AM, Rainer Orth
>> 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
Mike Stump writes:
> On Jun 3, 2014, at 3:40 AM, Rainer Orth 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
On Jun 3, 2014, at 3:40 AM, Rainer Orth 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 an option for this? If the
Rainer Orth writes:
> "Joseph S. Myers" 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 included the
> patch in a x86_64-apple-darwin11.4.
> 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" writes:
> On Thu, 22 May 2014, Rainer Orth wrote:
>
>> "Joseph S. Myers" 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): Handl
On Thu, 22 May 2014, Rainer Orth wrote:
> "Joseph S. Myers" 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 tha
"Joseph S. Myers" 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 specs, why can
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 (wi
"Joseph S. Myers" 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 mean for the option
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 cas
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 wi
"Joseph S. Myers" 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 there are s
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_SPE
"Joseph S. Myers" writes:
> On Thu, 11 Apr 2013, Rainer Orth wrote:
>
>> +gz=
>> +Common Driver JoinedOrMissing
>> +-gz=Generate compressed debug sections in format
>
> Although handled entirely in specs, I think it's best to use the Enum .opt
> facility to list the valid arguments to t
On Thu, 11 Apr 2013, Rainer Orth wrote:
> +gz=
> +Common Driver JoinedOrMissing
> +-gz= Generate compressed debug sections in 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 machinery
Andi Kleen writes:
> Rainer Orth 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_* -> .zdebug
Rainer Orth 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_* -> .zdebug_*), but consultation with t
24 matches
Mail list logo
