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-boun...@lists.linaro.org> on behalf of Pinski, Andrew <andrew.pin...@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-boun...@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.wil...@linaro.org> wrote: > > On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre <nicolas.pi...@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-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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
