new gas feature: section name substitution sequence

[Nicolas Pitre]

Hello toolchain people,

I created a patch on top of upstream binutils for a feature I need which
should be universally useful as well. Now I have 3 questions for you:

1) Does it look sane enough?

2) If so, could you integrate it in the Linaro release?

3) Would you be willing to promote it upstream?

Comments appreciated.

Here's the patch:

----- >8
Subject: [PATCH] gas: introduce section name substitution support

When gas is invoked with --sectname-subst, the occurrence of %S in a section
name will be substituted by the name of the current section. For example:

.macro exception_code
.pushsection %S.exception
[exception code here]
.popsection
.endm

.text
[code]
exception_code
[...]

.section .init
[init code]
exception_code
[...]

In the first exception_code invocation the .text.exception section is
created while in the second invocation it is the .init.exception section
that is created. This is useful e.g. to discriminate between anciliary
sections that are tied to .init code and can be discarded at run time when
initialization is over vs anciliary sections tied to .text sections that
need to stay resident.

This would also allow for actually omitting __exit sections from the Linux
kernel binary when modules are configured in even when exit marked code
generates exception table entries.

Signed-off-by: Nicolas Pitre <***@linaro.org>

diff --git a/gas/ChangeLog b/gas/ChangeLog
index 57fc30a..0189bb2 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -1,3 +1,11 @@
[phone] Nicolas Pitre <***@linaro.org>
+
+ * as.c (show_usage): Document --sectname-subst.
+ (parse_args): Add --sectname-subst.
+ * as.h (flag_sectname_subst): New.
+ * config/obj-elf.c (obj_elf_section_name): Add %S substitution.
+ * doc/as.texinfo: Document it.
+
2015-06-03 Matthew Wahab <***@arm.com>

* config/tc-arm.c (arm_archs): Add "armv8.1-a".
diff --git a/gas/as.c b/gas/as.c
index 2a8923f..fecfcd2 100644
--- a/gas/as.c
+++ b/gas/as.c
@@ -284,6 +284,8 @@ Options:\n\
fprintf (stream, _("\
--size-check=[error|warning]\n\
ELF .size directive check (default --size-check=error)\n"));
+ fprintf (stream, _("\
+ --sectname-subst enable section name substitution sequences\n"));
#endif
fprintf (stream, _("\
-f skip whitespace and comment preprocessing\n"));
@@ -447,6 +449,7 @@ parse_args (int * pargc, char *** pargv)
OPTION_EXECSTACK,
OPTION_NOEXECSTACK,
OPTION_SIZE_CHECK,
+ OPTION_SECTNAME_SUBST,
OPTION_ALTERNATE,
OPTION_AL,
OPTION_HASH_TABLE_SIZE,
@@ -481,6 +484,7 @@ parse_args (int * pargc, char *** pargv)
,{"execstack", no_argument, NULL, OPTION_EXECSTACK}
,{"noexecstack", no_argument, NULL, OPTION_NOEXECSTACK}
,{"size-check", required_argument, NULL, OPTION_SIZE_CHECK}
+ ,{"sectname-subst", no_argument, NULL, OPTION_SECTNAME_SUBST}
#endif
,{"fatal-warnings", no_argument, NULL, OPTION_WARN_FATAL}
,{"gdwarf-2", no_argument, NULL, OPTION_GDWARF2}
@@ -848,6 +852,10 @@ This program has absolutely no warranty.\n"));
else
as_fatal (_("Invalid --size-check= option: `%s'"), optarg);
break;
+
+ case OPTION_SECTNAME_SUBST:
+ flag_sectname_subst = 1;
+ break;
#endif
case 'Z':
flag_always_generate_output = 1;
diff --git a/gas/as.h b/gas/as.h
index 6de319e..635b2c5 100644
--- a/gas/as.h
+++ b/gas/as.h
@@ -589,6 +589,9 @@ COMMON enum
size_check_warning
}
flag_size_check;
+
+/* If section name substitution sequences should be honored */
+COMMON int flag_sectname_subst;
#endif

#ifndef DOLLAR_AMBIGU
diff --git a/gas/config/obj-elf.c b/gas/config/obj-elf.c
index 4d7a8a7..78dc6d9 100644
--- a/gas/config/obj-elf.c
+++ b/gas/config/obj-elf.c
@@ -917,6 +917,27 @@ obj_elf_section_name (void)
name = (char *) xmalloc (end - input_line_pointer + 1);
memcpy (name, input_line_pointer, end - input_line_pointer);
name[end - input_line_pointer] = '\0';
+
+ while (flag_sectname_subst)
+ {
+ char *subst = strchr (name, '%');
+ if (subst && subst[1] == 'S')
+ {
+ int oldlen = strlen (name);
+ int substlen = strlen (now_seg->name);
+ int newlen = oldlen - 2 + substlen;
+ char *newname = (char *) xmalloc (newlen + 1);
+ int headlen = subst - name;
+ memcpy (newname, name, headlen);
+ strcpy (newname + headlen, now_seg->name);
+ strcat (newname + headlen, subst + 2);
+ xfree (name);
+ name = newname;
+ }
+ else
+ break;
+ }
+
#ifdef tc_canonicalize_section_name
name = tc_canonicalize_section_name (name);
#endif
diff --git a/gas/doc/as.texinfo b/gas/doc/as.texinfo
index 5710e1c..be13b6a 100644
--- a/gas/doc/as.texinfo
+++ b/gas/doc/as.texinfo
@@ -6259,6 +6259,36 @@ For ELF targets, the @code{.section} directive is used like this:
.section @var{name} [, "@var{flags}"[, @@@var{type}[,@var{flag_specific_arguments}]]]
@end smallexample

+@cindex --sectname-subst
+If the @samp{--sectname-subst} command-line option is provided, the @var{name}
+argument may contain a substitution sequence. Only @code{%S} is supported
+at the moment, and substitutes the current section name. For example:
+
+@smallexample
+.macro exception_code
+.section %S.exception
+[exception code here]
+.previous
+.endm
+
+.text
+[code]
+exception_code
+[...]
+
+.section .init
+[init code]
+exception_code
+[...]
+@end smallexample
+
+The two @code{exception_code} invocations above would create the
+@code{.text.exception} and @code{.init.exception} sections respectively.
+This is useful e.g. to discriminate between anciliary sections that are
+tied to setup code to be discarded after use from anciliary sections that
+need to stay resident without having to define two @code{exception_code}
+macros just for that purpose.
+
The optional @var{flags} argument is a quoted string which may contain any
combination of the following characters:
@table @code

Nicolas

[Jim Wilson]

On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre <***@linaro.org> wrote:
> I created a patch on top of upstream binutils for a feature I need which
> should be universally useful as well. Now I have 3 questions for you:
>
> 1) Does it look sane enough?

You added the option docs into the .section docs. It is certainly OK
to talk about it here, but there is also a list of all options in the
docs, and the new option needs to be documented here also. One could
perhaps refer to the other. Otherwise, the patch looks OK, but I have
little experience using macros, so I'm not sure if there might be a
better way to do this. I'm also not sure how the other binutils
maintainers would feel about the design. It would have to be
discussed on the binutils mailing list.

> 2) If so, could you integrate it in the Linaro release?

The normal toolchain process is that patches get added to our releases
only if they are already upstream. Our releases are FSF releases plus
patches backported from mainline, with no local changes except when
absolutely unavoidable. I think that we'd rather delay a release so
we can submit a patch upstream first than make a release on time with
an extra non-FSF patch. So this needs to get into FSF binutils first,
and then we need a business reason to backport it, e.g. a member
explicitly asks us to backport it, or it fixes a bug that a member
reported, or is needed by a major open source project.

> 3) Would you be willing to promote it upstream?

We would need a business reason to promote it upstream, as above.
Otherwise it would be a personal decision, and I don't know if there
are any active binutils developers here that might be interested. It
is probably best to just go through the normal binutils patch
submission process. They tend to be pretty open to patches, and tend
to accept anything that looks like it might be useful, unless there is
already another way to do this making your patch redundant, or if your
patch conflicts with some existing feature, etc.

Jim

[Nicolas Pitre]

On Thu, 4 Jun 2015, Jim Wilson wrote:

> On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre <***@linaro.org> wrote:
> > I created a patch on top of upstream binutils for a feature I need which
> > should be universally useful as well. Now I have 3 questions for you:
> >
> > 1) Does it look sane enough?
>
> You added the option docs into the .section docs. It is certainly OK
> to talk about it here, but there is also a list of all options in the
> docs, and the new option needs to be documented here also. One could
> perhaps refer to the other.

OK.

> Otherwise, the patch looks OK, but I have little experience using
> macros, so I'm not sure if there might be a better way to do this.

I provided a macro based example to simplify things. But my primary use
case involves inline assembly from C code, such as included by the
put_user() macro in the Linux kernel.

> I'm also not sure how the other binutils maintainers would feel about
> the design. It would have to be discussed on the binutils mailing
> list.

Fair enough. Given your other comments I'll follow up on that list.

Thanks for the review.


Nicolas

[Maxim Kuvyrkov]

> On Jun 4, 2015, at 9:33 PM, Jim Wilson <***@linaro.org> wrote:
>
> On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre <***@linaro.org> wrote:
>> I created a patch on top of upstream binutils for a feature I need which
>> should be universally useful as well. Now I have 3 questions for you:
>>
>> 1) Does it look sane enough?
>
> You added the option docs into the .section docs. It is certainly OK
> to talk about it here, but there is also a list of all options in the
> docs, and the new option needs to be documented here also. One could
> perhaps refer to the other. Otherwise, the patch looks OK, but I have
> little experience using macros, so I'm not sure if there might be a
> better way to do this. I'm also not sure how the other binutils
> maintainers would feel about the design. It would have to be
> discussed on the binutils mailing list.
>
>> 2) If so, could you integrate it in the Linaro release?
>
> The normal toolchain process is that patches get added to our releases
> only if they are already upstream. Our releases are FSF releases plus
> patches backported from mainline, with no local changes except when
> absolutely unavoidable. I think that we'd rather delay a release so
> we can submit a patch upstream first than make a release on time with
> an extra non-FSF patch. So this needs to get into FSF binutils first,
> and then we need a business reason to backport it, e.g. a member
> explicitly asks us to backport it, or it fixes a bug that a member
> reported, or is needed by a major open source project.

FWIW, for a patch of this size, "Linaro's kernel engineers need this" is a good-enough business justification :-)

>
>> 3) Would you be willing to promote it upstream?
>
> We would need a business reason to promote it upstream, as above.
> Otherwise it would be a personal decision, and I don't know if there
> are any active binutils developers here that might be interested. It
> is probably best to just go through the normal binutils patch
> submission process. They tend to be pretty open to patches, and tend
> to accept anything that looks like it might be useful, unless there is
> already another way to do this making your patch redundant, or if your
> patch conflicts with some existing feature, etc.

Right, and, please, CC Adhemerval as he is the one looking after Binutils at Linaro.

Thank you,

--
Maxim Kuvyrkov
www.linaro.org

[Pinski, Andrew]

I am just going to say, I don't like this extension at all. It allows for abuse than it is good.

Thanks,
Andrew Pinski

-----Original Message-----
From: linaro-toolchain [mailto:linaro-toolchain-***@lists.linaro.org] On Behalf Of Maxim Kuvyrkov
Sent: Friday, June 5, 2015 5:58 PM
To: Jim Wilson
Cc: Nicolas Pitre; Linaro Toolchain Mailman List
Subject: Re: new gas feature: section name substitution sequence

> On Jun 4, 2015, at 9:33 PM, Jim Wilson <***@linaro.org> wrote:
>
> On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre <***@linaro.org> wrote:
>> I created a patch on top of upstream binutils for a feature I need
>> which should be universally useful as well. Now I have 3 questions for you:
>>
>> 1) Does it look sane enough?
>
> You added the option docs into the .section docs. It is certainly OK
> to talk about it here, but there is also a list of all options in the
> docs, and the new option needs to be documented here also. One could
> perhaps refer to the other. Otherwise, the patch looks OK, but I have
> little experience using macros, so I'm not sure if there might be a
> better way to do this. I'm also not sure how the other binutils
> maintainers would feel about the design. It would have to be
> discussed on the binutils mailing list.
>
>> 2) If so, could you integrate it in the Linaro release?
>
> The normal toolchain process is that patches get added to our releases
> only if they are already upstream. Our releases are FSF releases plus
> patches backported from mainline, with no local changes except when
> absolutely unavoidable. I think that we'd rather delay a release so
> we can submit a patch upstream first than make a release on time with
> an extra non-FSF patch. So this needs to get into FSF binutils first,
> and then we need a business reason to backport it, e.g. a member
> explicitly asks us to backport it, or it fixes a bug that a member
> reported, or is needed by a major open source project.

FWIW, for a patch of this size, "Linaro's kernel engineers need this" is a good-enough business justification :-)

>
>> 3) Would you be willing to promote it upstream?
>
> We would need a business reason to promote it upstream, as above.
> Otherwise it would be a personal decision, and I don't know if there
> are any active binutils developers here that might be interested. It
> is probably best to just go through the normal binutils patch
> submission process. They tend to be pretty open to patches, and tend
> to accept anything that looks like it might be useful, unless there is
> already another way to do this making your patch redundant, or if your
> patch conflicts with some existing feature, etc.

Right, and, please, CC Adhemerval as he is the one looking after Binutils at Linaro.

Thank you,

--
Maxim Kuvyrkov
www.linaro.org

_______________________________________________
linaro-toolchain mailing list
linaro-***@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Pinski, Andrew]

Oh and why can't you use the C preprocessor to do this section renaming?
I know for a fact the kernel uses the preprocessor for assembly code all over the place and I don't see why this would not be so different.

Thanks,
Andrew Pinski

________________________________________
From: linaro-toolchain <linaro-toolchain-***@lists.linaro.org> on behalf of Pinski, Andrew <***@caviumnetworks.com>
Sent: Friday, June 5, 2015 3:05 AM
To: Maxim Kuvyrkov; Jim Wilson
Cc: Nicolas Pitre; Linaro Toolchain Mailman List
Subject: RE: new gas feature: section name substitution sequence

I am just going to say, I don't like this extension at all. It allows for abuse than it is good.

Thanks,
Andrew Pinski

-----Original Message-----
From: linaro-toolchain [mailto:linaro-toolchain-***@lists.linaro.org] On Behalf Of Maxim Kuvyrkov
Sent: Friday, June 5, 2015 5:58 PM
To: Jim Wilson
Cc: Nicolas Pitre; Linaro Toolchain Mailman List
Subject: Re: new gas feature: section name substitution sequence

> On Jun 4, 2015, at 9:33 PM, Jim Wilson <***@linaro.org> wrote:
>
> On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre <***@linaro.org> wrote:
>> I created a patch on top of upstream binutils for a feature I need
>> which should be universally useful as well. Now I have 3 questions for you:
>>
>> 1) Does it look sane enough?
>
> You added the option docs into the .section docs. It is certainly OK
> to talk about it here, but there is also a list of all options in the
> docs, and the new option needs to be documented here also. One could
> perhaps refer to the other. Otherwise, the patch looks OK, but I have
> little experience using macros, so I'm not sure if there might be a
> better way to do this. I'm also not sure how the other binutils
> maintainers would feel about the design. It would have to be
> discussed on the binutils mailing list.
>
>> 2) If so, could you integrate it in the Linaro release?
>
> The normal toolchain process is that patches get added to our releases
> only if they are already upstream. Our releases are FSF releases plus
> patches backported from mainline, with no local changes except when
> absolutely unavoidable. I think that we'd rather delay a release so
> we can submit a patch upstream first than make a release on time with
> an extra non-FSF patch. So this needs to get into FSF binutils first,
> and then we need a business reason to backport it, e.g. a member
> explicitly asks us to backport it, or it fixes a bug that a member
> reported, or is needed by a major open source project.

FWIW, for a patch of this size, "Linaro's kernel engineers need this" is a good-enough business justification :-)

>
>> 3) Would you be willing to promote it upstream?
>
> We would need a business reason to promote it upstream, as above.
> Otherwise it would be a personal decision, and I don't know if there
> are any active binutils developers here that might be interested. It
> is probably best to just go through the normal binutils patch
> submission process. They tend to be pretty open to patches, and tend
> to accept anything that looks like it might be useful, unless there is
> already another way to do this making your patch redundant, or if your
> patch conflicts with some existing feature, etc.

Right, and, please, CC Adhemerval as he is the one looking after Binutils at Linaro.

Thank you,

--
Maxim Kuvyrkov
www.linaro.org

_______________________________________________
linaro-toolchain mailing list
linaro-***@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
_______________________________________________
linaro-toolchain mailing list
linaro-***@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Nicolas Pitre]

On Fri, 5 Jun 2015, Pinski, Andrew wrote:

> I am just going to say, I don't like this extension at all. It allows for abuse than it is good.

What abuses do you forsee? Could you elaborate please?

> Oh and why can't you use the C preprocessor to do this section
> renaming? I know for a fact the kernel uses the preprocessor for
> assembly code all over the place and I don't see why this would not be
> so different.

I did try, obviously.

Take for example this construct:

#define __get_user_asm_byte(x, addr, err) \
__asm__ __volatile__( \
"1: ldrbt %1,[%2],#0\n" \
"2:\n" \
" .pushsection .text.fixup,\"ax\"\n" \
" .align 2\n" \
"3: mov %0, %3\n" \
" mov %1, #0\n" \
" b 2b\n" \
" .popsection\n" \
" .pushsection __ex_table,\"a\"\n" \
" .align 3\n" \
" .long 1b, 3b\n" \
" .popsection" \
: "+r" (err), "=&r" (x) \
: "r" (addr), "i" (-EFAULT) \
: "cc")

Now this code can be used by functions placed either in the .text
section, the .init.text section, or the .exit.text section. If this is
compiled into the kernel instead of being configured as a module, then
we want to be able to discard at run time any .init.text content and
avoid linking in the .exit.text sections altogether. But if the
.exit.text section is omitted, then you'll get a symbol reference error
because both the .text.fixup and __ex_table sections hold references to
some code in .exit.text. The only way to solve this is to have a
separate section for .exit.text induced fixup code and exception table
entries so they can be discarded at the linker level along with the
.exit.text section.

Now the section type could be passed as an argument to the
__get_user_asm_byte() macro you might suggest. But we can't always know
the actual section in use. For example there are many of those macros
used within larger inline functions (or sometimes it is gcc who inlines
stuff on its own). Those functions are used either from .text, .init or
.exit code at the moment. Attempting to pass the section information
across many levels quickly becomes unwieldly and a maintenance
nightmare. It works only when constant propagation is applied, and if
for some reason gcc decides not to inline things then the section
identifier is no longer a constant to the leaf function.

In the course of my work on kernel tinification, I'm also contempling
the use of -ffunction-sections and -fdata-sections with gcc, in
conjonction with ld's -gc-sections which would emplify this issue to all
functions. Here I tried to use __func__ and pass it to the the
assembler, but __func__ acts like a string pointer and terefore can't be
used to form an anciliary section name at the assembler level. And even
if it worked, once again function inlining makes it wrong because
__func__ produces a string corresponding to the local function whereas
the actual section name would refer to the outer function where the
inlining occurred, and if the section corresponding to the inlined
function is actually in another instance then the whole section may no
longer be garbage-collected.

So... my conclusion is that, to solve those issues in the simplest and
the most robust way, it should be implemented at the assembler level,
hence the patch I'm now proposing. If you do think about a better way
to achieve the same thing please tell me -- I'll be highly interested.

Thanks


Nicolas

[Nicolas Pitre]

On Thu, 4 Jun 2015, Jim Wilson wrote:

> On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre <***@linaro.org> wrote:
> > I created a patch on top of upstream binutils for a feature I need which
> > should be universally useful as well. Now I have 3 questions for you:
> >
> > 1) Does it look sane enough?
>
> You added the option docs into the .section docs. It is certainly OK
> to talk about it here, but there is also a list of all options in the
> docs, and the new option needs to be documented here also. One could
> perhaps refer to the other.

Unless I'm missing something obvious, I can't find any section where all
options are documented together. There is the "Invoking" section but it
contains very few options and only the most generic ones. All the
others are documented here and there in the manual with a reference to
them added to the index as I did.

Did you have something more precise in mind?

Thanks


Nicolas

[Jim Wilson]

On Mon, Jun 8, 2015 at 11:36 AM, Nicolas Pitre <***@linaro.org> wrote:
> Unless I'm missing something obvious, I can't find any section where all
> options are documented together. There is the "Invoking" section but it
> contains very few options and only the most generic ones. All the
> others are documented here and there in the manual with a reference to
> them added to the index as I did.

I only saw one documentation hunk in your patch, and that was in the
middle of the .section pseudo-op description. An option should be
mentioned in the overview section, and then for target independent
options a longer description in the invoking section if necessary.
Target dependent options get documented in the target dependent parts
of the manual. Putting longer descriptions elsewhere may be
appropriate, and your docs in the .section psuedo-op section seemed
OK, but not also without a mention in the overview which I didn't see.

Jim

[Nicolas Pitre]

On Mon, 8 Jun 2015, Jim Wilson wrote:

> On Mon, Jun 8, 2015 at 11:36 AM, Nicolas Pitre <***@linaro.org> wrote:
> > Unless I'm missing something obvious, I can't find any section where all
> > options are documented together. There is the "Invoking" section but it
> > contains very few options and only the most generic ones. All the
> > others are documented here and there in the manual with a reference to
> > them added to the index as I did.
>
> I only saw one documentation hunk in your patch, and that was in the
> middle of the .section pseudo-op description. An option should be
> mentioned in the overview section, and then for target independent
> options a longer description in the invoking section if necessary.

Doh! OK sorry for the noise. I did miss the obvious. I initially
overlooked the overview section, thinking it was only introductory
material.

Thanks


Nicolas

[Nicolas Pitre]

On Thu, 4 Jun 2015, Jim Wilson wrote:

> The normal toolchain process is that patches get added to our releases
> only if they are already upstream. Our releases are FSF releases plus
> patches backported from mainline, with no local changes except when
> absolutely unavoidable.

It is commit 451133cefa upstream.

Please consider merging for the next toolchain release. I don't expect
major conflicts if any.


Nicolas

[Maxim Kuvyrkov]

> On Jun 17, 2015, at 3:15 AM, Nicolas Pitre <***@linaro.org> wrote:
>
> On Thu, 4 Jun 2015, Jim Wilson wrote:
>
>> The normal toolchain process is that patches get added to our releases
>> only if they are already upstream. Our releases are FSF releases plus
>> patches backported from mainline, with no local changes except when
>> absolutely unavoidable.
>
> It is commit 451133cefa upstream.
>
> Please consider merging for the next toolchain release. I don't expect
> major conflicts if any.

Hi Adhemerval,

FAOD, are you planning to merge this feature into linaro's 2.25 or 2.24 branch?

My [very light] preference is to merge it to 2.25, but not 2.24.

Thanks,

--
Maxim Kuvyrkov
www.linaro.org

[Adhemerval Zanella]

On 18-06-2015 05:44, Maxim Kuvyrkov wrote:
>> On Jun 17, 2015, at 3:15 AM, Nicolas Pitre <***@linaro.org> wrote:
>>
>> On Thu, 4 Jun 2015, Jim Wilson wrote:
>>
>>> The normal toolchain process is that patches get added to our releases
>>> only if they are already upstream. Our releases are FSF releases plus
>>> patches backported from mainline, with no local changes except when
>>> absolutely unavoidable.
>>
>> It is commit 451133cefa upstream.
>>
>> Please consider merging for the next toolchain release. I don't expect
>> major conflicts if any.
>
> Hi Adhemerval,
>
> FAOD, are you planning to merge this feature into linaro's 2.25 or 2.24 branch?
>
> My [very light] preference is to merge it to 2.25, but not 2.24.
>
> Thanks,
>

Do we need it to 2.24? Is this patch preventing current kernel builds for older
binutils releases?

> --
> Maxim Kuvyrkov
> www.linaro.org
>

[Nicolas Pitre]

On Thu, 18 Jun 2015, Adhemerval Zanella wrote:

>
>
> On 18-06-2015 05:44, Maxim Kuvyrkov wrote:
> >> On Jun 17, 2015, at 3:15 AM, Nicolas Pitre <***@linaro.org> wrote:
> >>
> >> On Thu, 4 Jun 2015, Jim Wilson wrote:
> >>
> >>> The normal toolchain process is that patches get added to our releases
> >>> only if they are already upstream. Our releases are FSF releases plus
> >>> patches backported from mainline, with no local changes except when
> >>> absolutely unavoidable.
> >>
> >> It is commit 451133cefa upstream.
> >>
> >> Please consider merging for the next toolchain release. I don't expect
> >> major conflicts if any.
> >
> > Hi Adhemerval,
> >
> > FAOD, are you planning to merge this feature into linaro's 2.25 or 2.24 branch?
> >
> > My [very light] preference is to merge it to 2.25, but not 2.24.
> >
> > Thanks,
> >
>
> Do we need it to 2.24? Is this patch preventing current kernel builds for older
> binutils releases?

Current kernels are fine without it. My work on kernel tinification
requires it though. Depending on when this work will be ready for wider
consumption, it would be nice if our binutils already carried the
necessary support.

I don't know what the 2.24 vs 2.25 release timeline is, but if 2.25 is
released, say, before next Connect then it should be good enough.


Nicolas

[Adhemerval Zanella]

On 18-06-2015 11:26, Nicolas Pitre wrote:
> On Thu, 18 Jun 2015, Adhemerval Zanella wrote:
>
>>
>>
>> On 18-06-2015 05:44, Maxim Kuvyrkov wrote:
>>>> On Jun 17, 2015, at 3:15 AM, Nicolas Pitre <***@linaro.org> wrote:
>>>>
>>>> On Thu, 4 Jun 2015, Jim Wilson wrote:
>>>>
>>>>> The normal toolchain process is that patches get added to our releases
>>>>> only if they are already upstream. Our releases are FSF releases plus
>>>>> patches backported from mainline, with no local changes except when
>>>>> absolutely unavoidable.
>>>>
>>>> It is commit 451133cefa upstream.
>>>>
>>>> Please consider merging for the next toolchain release. I don't expect
>>>> major conflicts if any.
>>>
>>> Hi Adhemerval,
>>>
>>> FAOD, are you planning to merge this feature into linaro's 2.25 or 2.24 branch?
>>>
>>> My [very light] preference is to merge it to 2.25, but not 2.24.
>>>
>>> Thanks,
>>>
>>
>> Do we need it to 2.24? Is this patch preventing current kernel builds for older
>> binutils releases?
>
> Current kernels are fine without it. My work on kernel tinification
> requires it though. Depending on when this work will be ready for wider
> consumption, it would be nice if our binutils already carried the
> necessary support.
>
> I don't know what the 2.24 vs 2.25 release timeline is, but if 2.25 is
> released, say, before next Connect then it should be good enough.
>
>

Binutils 2.24 was officially released 2013/12 and Binutils 2.25 at 2014/12.
Current distros uses versions from 2.23 (RHEL7/CentOS7), 2.24 (Ubuntu 14),
or 2.25 (Debian Jessie) and I think next Linaro toolchain will use 2.25.
I would prefer to focus on 2.25, since 2.24 is reaching two years old, however
since this modification seems to be very constrained, I do not see much work
being required to backport to 2.24.

> Nicolas
>

[Nicolas Pitre]

On Thu, 18 Jun 2015, Adhemerval Zanella wrote:

>
>
> On 18-06-2015 11:26, Nicolas Pitre wrote:
> > On Thu, 18 Jun 2015, Adhemerval Zanella wrote:
> >
> >>
> >>
> >> On 18-06-2015 05:44, Maxim Kuvyrkov wrote:
> >>>> On Jun 17, 2015, at 3:15 AM, Nicolas Pitre <***@linaro.org> wrote:
> >>>>
> >>>> On Thu, 4 Jun 2015, Jim Wilson wrote:
> >>>>
> >>>>> The normal toolchain process is that patches get added to our releases
> >>>>> only if they are already upstream. Our releases are FSF releases plus
> >>>>> patches backported from mainline, with no local changes except when
> >>>>> absolutely unavoidable.
> >>>>
> >>>> It is commit 451133cefa upstream.
> >>>>
> >>>> Please consider merging for the next toolchain release. I don't expect
> >>>> major conflicts if any.
> >>>
> >>> Hi Adhemerval,
> >>>
> >>> FAOD, are you planning to merge this feature into linaro's 2.25 or 2.24 branch?
> >>>
> >>> My [very light] preference is to merge it to 2.25, but not 2.24.
> >>>
> >>> Thanks,
> >>>
> >>
> >> Do we need it to 2.24? Is this patch preventing current kernel builds for older
> >> binutils releases?
> >
> > Current kernels are fine without it. My work on kernel tinification
> > requires it though. Depending on when this work will be ready for wider
> > consumption, it would be nice if our binutils already carried the
> > necessary support.
> >
> > I don't know what the 2.24 vs 2.25 release timeline is, but if 2.25 is
> > released, say, before next Connect then it should be good enough.
> >
> >
>
> Binutils 2.24 was officially released 2013/12 and Binutils 2.25 at 2014/12.
> Current distros uses versions from 2.23 (RHEL7/CentOS7), 2.24 (Ubuntu 14),
> or 2.25 (Debian Jessie) and I think next Linaro toolchain will use 2.25.
> I would prefer to focus on 2.25, since 2.24 is reaching two years old, however
> since this modification seems to be very constrained, I do not see much work
> being required to backport to 2.24.

Well... All I really care about is for this patch to be available in
next Linaro toolchain release, or next month's. The actual version
number is immaterial to me.


Nicolas

[Maxim Kuvyrkov]

> On Jun 18, 2015, at 6:41 PM, Nicolas Pitre <***@linaro.org> wrote:
>
> On Thu, 18 Jun 2015, Adhemerval Zanella wrote:
>
>>
>>
>> On 18-06-2015 11:26, Nicolas Pitre wrote:
>>> On Thu, 18 Jun 2015, Adhemerval Zanella wrote:
>>>
>>>>
>>>>
>>>> On 18-06-2015 05:44, Maxim Kuvyrkov wrote:
>>>>>> On Jun 17, 2015, at 3:15 AM, Nicolas Pitre <***@linaro.org> wrote:
>>>>>>
>>>>>> On Thu, 4 Jun 2015, Jim Wilson wrote:
>>>>>>
>>>>>>> The normal toolchain process is that patches get added to our releases
>>>>>>> only if they are already upstream. Our releases are FSF releases plus
>>>>>>> patches backported from mainline, with no local changes except when
>>>>>>> absolutely unavoidable.
>>>>>>
>>>>>> It is commit 451133cefa upstream.
>>>>>>
>>>>>> Please consider merging for the next toolchain release. I don't expect
>>>>>> major conflicts if any.
>>>>>
>>>>> Hi Adhemerval,
>>>>>
>>>>> FAOD, are you planning to merge this feature into linaro's 2.25 or 2.24 branch?
>>>>>
>>>>> My [very light] preference is to merge it to 2.25, but not 2.24.
>>>>>
>>>>> Thanks,
>>>>>
>>>>
>>>> Do we need it to 2.24? Is this patch preventing current kernel builds for older
>>>> binutils releases?
>>>
>>> Current kernels are fine without it. My work on kernel tinification
>>> requires it though. Depending on when this work will be ready for wider
>>> consumption, it would be nice if our binutils already carried the
>>> necessary support.
>>>
>>> I don't know what the 2.24 vs 2.25 release timeline is, but if 2.25 is
>>> released, say, before next Connect then it should be good enough.
>>>
>>>
>>
>> Binutils 2.24 was officially released 2013/12 and Binutils 2.25 at 2014/12.
>> Current distros uses versions from 2.23 (RHEL7/CentOS7), 2.24 (Ubuntu 14),
>> or 2.25 (Debian Jessie) and I think next Linaro toolchain will use 2.25.
>> I would prefer to focus on 2.25, since 2.24 is reaching two years old, however
>> since this modification seems to be very constrained, I do not see much work
>> being required to backport to 2.24.
>
> Well... All I really care about is for this patch to be available in
> next Linaro toolchain release, or next month's. The actual version
> number is immaterial to me.

Let's stick with 2.25 then. It should be released within 1-2 month timeframe.

--
Maxim Kuvyrkov
www.linaro.org

[Adhemerval Zanella]

On 19-06-2015 12:00, Maxim Kuvyrkov wrote:
>> On Jun 18, 2015, at 6:41 PM, Nicolas Pitre <***@linaro.org> wrote:
>>
>> On Thu, 18 Jun 2015, Adhemerval Zanella wrote:
>>
>>>
>>>
>>> On 18-06-2015 11:26, Nicolas Pitre wrote:
>>>> On Thu, 18 Jun 2015, Adhemerval Zanella wrote:
>>>>
>>>>>
>>>>>
>>>>> On 18-06-2015 05:44, Maxim Kuvyrkov wrote:
>>>>>>> On Jun 17, 2015, at 3:15 AM, Nicolas Pitre <***@linaro.org> wrote:
>>>>>>>
>>>>>>> On Thu, 4 Jun 2015, Jim Wilson wrote:
>>>>>>>
>>>>>>>> The normal toolchain process is that patches get added to our releases
>>>>>>>> only if they are already upstream. Our releases are FSF releases plus
>>>>>>>> patches backported from mainline, with no local changes except when
>>>>>>>> absolutely unavoidable.
>>>>>>>
>>>>>>> It is commit 451133cefa upstream.
>>>>>>>
>>>>>>> Please consider merging for the next toolchain release. I don't expect
>>>>>>> major conflicts if any.
>>>>>>
>>>>>> Hi Adhemerval,
>>>>>>
>>>>>> FAOD, are you planning to merge this feature into linaro's 2.25 or 2.24 branch?
>>>>>>
>>>>>> My [very light] preference is to merge it to 2.25, but not 2.24.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>
>>>>> Do we need it to 2.24? Is this patch preventing current kernel builds for older
>>>>> binutils releases?
>>>>
>>>> Current kernels are fine without it. My work on kernel tinification
>>>> requires it though. Depending on when this work will be ready for wider
>>>> consumption, it would be nice if our binutils already carried the
>>>> necessary support.
>>>>
>>>> I don't know what the 2.24 vs 2.25 release timeline is, but if 2.25 is
>>>> released, say, before next Connect then it should be good enough.
>>>>
>>>>
>>>
>>> Binutils 2.24 was officially released 2013/12 and Binutils 2.25 at 2014/12.
>>> Current distros uses versions from 2.23 (RHEL7/CentOS7), 2.24 (Ubuntu 14),
>>> or 2.25 (Debian Jessie) and I think next Linaro toolchain will use 2.25.
>>> I would prefer to focus on 2.25, since 2.24 is reaching two years old, however
>>> since this modification seems to be very constrained, I do not see much work
>>> being required to backport to 2.24.
>>
>> Well... All I really care about is for this patch to be available in
>> next Linaro toolchain release, or next month's. The actual version
>> number is immaterial to me.
>
> Let's stick with 2.25 then. It should be released within 1-2 month timeframe.
>

The patch is self-contained and trigger no regression in my testing. I updated
both linaro 2.24 and 2.25 tree.

> --
> Maxim Kuvyrkov
> www.linaro.org
>