Re: Better communication about spectre/meltdown
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
Reply to: