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 nico@linaro.org
diff --git a/gas/ChangeLog b/gas/ChangeLog index 57fc30a..0189bb2 100644 --- a/gas/ChangeLog +++ b/gas/ChangeLog @@ -1,3 +1,11 @@ +2015-06-03 Nicolas Pitre nico@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 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
On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre 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:
- 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.
- 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.
- 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
On Thu, 4 Jun 2015, Jim Wilson wrote:
On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre 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:
- 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
On Jun 4, 2015, at 9:33 PM, Jim Wilson jim.wilson@linaro.org wrote:
On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre 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:
- 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.
- 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 :-)
- 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
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-bounces@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 jim.wilson@linaro.org wrote:
On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre 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:
- 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.
- 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 :-)
- 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-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
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-bounces@lists.linaro.org on behalf of Pinski, Andrew Andrew.Pinski@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-bounces@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 jim.wilson@linaro.org wrote:
On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre 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:
- 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.
- 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 :-)
- 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-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
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
On Thu, 4 Jun 2015, Jim Wilson wrote:
On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre 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:
- 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
On Mon, Jun 8, 2015 at 11:36 AM, Nicolas Pitre 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
On Mon, 8 Jun 2015, Jim Wilson wrote:
On Mon, Jun 8, 2015 at 11:36 AM, Nicolas Pitre 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
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
On Jun 17, 2015, at 3:15 AM, Nicolas Pitre 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
On 18-06-2015 05:44, Maxim Kuvyrkov wrote:
On Jun 17, 2015, at 3:15 AM, Nicolas Pitre 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
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 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
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 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
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 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
On Jun 18, 2015, at 6:41 PM, Nicolas Pitre 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 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
On 19-06-2015 12:00, Maxim Kuvyrkov wrote:
On Jun 18, 2015, at 6:41 PM, Nicolas Pitre 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 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
linaro-toolchain@lists.linaro.org