Messages in this thread | | | From | Arvind Sankar <> | Date | Mon, 13 Jan 2020 12:59:38 -0500 | Subject | Re: [PATCH] x86/tools/relocs: Add _etext and __end_of_kernel_reserve to S_REL |
| |
On Mon, Jan 13, 2020 at 05:38:55PM +0100, Borislav Petkov wrote: > On Mon, Jan 13, 2020 at 11:13:10AM -0500, Arvind Sankar wrote: > > How to reproduce is just "build with old binutils". I don't see it's > > reasonable to include a tutorial on how to build the kernel with a > > toolchain that's not installed in the default PATH, as part of the commit > > message. > > The point is that it should be clear that it should state whether it is > something you trigger with some stock distro which has been shipping > this way or it is something you've customly created. Huge difference. > > So pls make sure that is clear from the commit message. >
How is "breaks with binutils before version 2.23" not clear enough? It will break regardless of whether distro shipped v2.21 or you built v2.21. I'm _not_ creating a custom binutils with my own patches specifically to trigger this issue, it's stock binutils, as stock as you can get it.
Do you really want me to say in the commit message "to reproduce, first compile binutils-2.21 from source, then try to build the kernel with it"? Including this information would make sense only if the problem wasn't with stock binutils, but only with some specific distro's patched version. _Then_ it would make sense to say something like "binutils package v-xxx shipped with OpenSUSE v-yyy was broken, this commit works around it". This is a problem with _any_ binutils-2.21, there's nothing special about how you need to build it.
| |