Hi all, Please see my rather long-winded summary of the current state of the gcc-4.6/gcc-4.7 update. The bottom line is that I am looking for opions and/or guidance for how to proceed.
On Thu, Feb 15, 2018 at 08:56:42PM +0100, Moritz Muehlenhoff wrote: > On Thu, Feb 15, 2018 at 12:33:12PM +0100, Raphael Hertzog wrote: > > On IRC I learned that Moritz Muehlenhoff (jmm) started the work of > > bakcporting retpoline to gcc-4.9 for jessie. We need to do the same > > for gcc-4.6 (and maybe gcc-4.7) in wheezy. gcc-4.6 is used for the > > kernel build so that's the important target really. > > Or rather introduce gcc-4.9 as a new source package to wheezy LTS > which can then be used for the kernel build (once 3.2.x has > retpoline backported). > > For the architectures supported in LTS the compiler difference > between 4.6 and 4.9 should not matter. > So, here as update on the current state of gcc-4.6/gcc-4.7. Basically, jmm's patches to gcc-4.9 were not a perfect fit for gcc-4.6, but it was not terribly difficult to figure out how to get them to apply with some changes. Some components had been removed/refactored between 4.6 and 4.9 and it was somewhat time consuming. In a few cases I had to examine old upstream changes to a particular section of code in order to determine how best to backport a given hunk to fit the structure of gcc-4.6. What was more surprising than anything, and what now appears to be the biggest obstacle, is that the option parsing in gcc-4.9 has significant differences from the option parsing in gcc-4.6. In particular, the new -mindirect-branch= and -mfunction-return= options make use of a feature in gcc's option parser (by far the most sophisticated option parser I have seen) that allows it to automagically parse a string passed as a command-line option into some value of an enum. As best I can determine, that feature was introduced for gcc-4.7. As a result, the way I have the patches currently applied, the build fails early on in an area of the option parsing code. After examining other command-line options that map a string value to an enum constant and how they are implemented in gcc-4.6 I have determined that the way forward likely involves one of two things: - Backport the string-to-enum mapping feature for option parsing (the upstream change that introduced it appears to be ~200 lines of diff) - Implement option parsing code for the two new options that resembles the existing code for parsing other options in gcc-4.6 I am hesitant to backport upstream's string-to-enum mapping option parsing change as it may be that the change is not completely contained in the one interesting commit that I found. I would hate to start down that path only to end up needing to pull in more and more changes. Implementing 4.6-style option parsing for the new options would introduce risk in a different way. Instead of backporting upstream's proven code for option parsing, this would require developing new code that may or may not be completely correct. Of course, at this point gcc-4.9 has been patched, tested, and released, so I feel it is prudent to suggest that reconsideration of that as one of the options for how to proceed. Please note that I have not yet examined gcc-4.7, but I suspect that based on the option parsing being the biggest problem I have encoutnerd that backporting the patches to gcc-4.7 will be considerably easier than it has been for gcc-4.6. Of course, if anyone out there feels like they can take this over from me and have a clear path to the goal, I am more than happy to turn this over. I will provide a detailed summary of the changes I made to jmm's patches and any other relevant bits of information. Regards, -Roberto -- Roberto C. Sánchez