On Wed, 23 Aug 2006, Karanbir Singh wrote: > Matthew Miller wrote: >> it's "updated to new snapshot, altering about 100,000 lines >> of code". Which is it in this case? >> >> If it's nearer the former, Milan's request that the newer >> compiler be used because it fixes a known and serious >> problem seems quite reasonable. > here is the changelog: Let's see what the changes were .... I think it is undecidable as to the matter of 'reasonableness', in doing a postmortem > * Tue May 23 2006 Jakub Jelinek <jakub at redhat.com> 3.4.6-3 > - -fvar-tracking fixes needed for SystemTap (BZ#2438) - not clear which BZ is referred to, but it is not the Red Hat one; not in the Cygwin one (http://www.cygwin.com/bugzilla/), not in the Gnu one (http://gcc.gnu.org/bugzilla/) > - add workaround for buggy programs that link in their own unwinder > and reexport it (#192814) - probably the Red Hat bugzilla, but bug 192814 is blocked from review by 'mere mortals' in the general public -- This implies a security related matter, which are definitionally important changes > - make all globals in libgcc_eh.a hidden, so that newly (incorrectly) > linked programs can't reexport the unwinder - no bugzilla reference as to why and what 'incorrectly' linked programs are exporting the unwinder, nor why that is dangerous (rather than just wrong -- if only wrong, the problem is in the sources of the misbehaving program, and would seem to be more properly fixed there, unless there ARE security overtones). Is the kernel one of the offenders? -- One cannot say. > - support -fno-frame-base-loclist option to prevent use of > DWARF2 location lists in DW_AT_frame_base value (#191041) - probably the Red Hat bugzilla, but bug 191041 is also blocked from review by 'mere mortals' in the general public One has to suspect that there may be dangerous behaviours being addressed, from the obscure Changelog backreferences. > Matt, the point is - those changes might have implications > down the road - I dont have the gcc knowledge to work out > exactly what those issues might be - and some of them do > seem to have a direct impact on kernel space stuff ? and as we see in this case, and after inspection from the Changelog, and the outlinks it references, that NONE of the underlying reasoning nor cause for the changes for that GCC variant may be inspected, without further study than what we have or can easily access. It would take further study to reach decideability as to 'reasonable', comparing between patched source trees of the GCC versions in question to even see what has changed. As I recall, gcc builds part of its macro expansion set on the fly during the compile, and so one has to snapshot it from time to time as well, to see what is changing. Matt later said: > So, the RHSA-2006:0617-15-based kernel from yesterday is > built with the new gcc, and the whole conversation is pretty > frickin' moot. I want also to point out that just because a person produces a binary variant with a header containing the string 'X', nothing guarantees that the compiler version you THINK produced that X is truly one that a later appearing X variant in fact produced -- one can trivially spoof such values; buildsystems slipstream changes all the time ... we _hope_ is is the same, we hope it is moot, but nothing at all says that the binary update from June was build with the similarly version numbered sources released in August. It need not even be intentional that identical number versions may hold varying content. Personal buildtrees outside of a central buildsystem are the rule, not the exception. >From CentOS' point of view, the most responsible way to proceed, is to have a reproducable course documented, and to follow it. _If_ one had a formal confirmaton on a particular kernel's buildsystem environment (which will not be forthcoming), or access to the specific GCC sources known to have been used for the specific binary kernel variant being compared to, other options might exist. The PNAELV did not choose to timely make available the asserted gcc variant in question. A better approach, the CentOS approach: build using a toolchain, based on the freely reproducable sources actually released, and not expose that million user base to unknown risks with 'likely' used variants without formal provenance. A downstream user/admin wishing to do so, and to be daring, may do so, as they see fit, but in turn only harm themself, if the decision turns out to be ill advised. - Russ Herrold