On 11/25/2013 04:02 PM, Andrew wrote:
----- Original Message -----On 11/23/2013 08:35 PM, Alex Kasko wrote:On 11/23/2013 05:36 PM, Alex Kasko wrote:On 11/23/2013 10:40 AM, Andrew wrote:----- Original Message -----* Andrew <gnu.and...@redhat.com> [2013-11-20 12:13]:Webrev: http://cr.openjdk.java.net/~andrew/openjdk6/20131015/hotspotLooks identical to patches in icedtea6. No objections from me. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681Now they're all pushed, we should consider a b29 release, though let's first hear back on Alex's Windows issues.It was a makefile typo - http://cr.openjdk.java.net/~akasko/jdk6/webrev_hotspot_makefile_typo.00/ Windows builds are in progress now, they should finish in 3 hours - I'll report later.Typo was only the part of the issue. The main issue was the /SAFESEH linking flag on sawindbg.dll causing link error [1]. I was unable to make it work with VS2003 (my knowledge of win32 debug tools seems too low), so I am proposing to remove this flag from i586 windows build (it is not used in amd64 one). Some links with the context of the problem: [2] - [8]. Updated (more clean) typo webrev based on changeset [9] - http://cr.openjdk.java.net/~akasko/jdk6/webrev_hotspot_makefile_typo.01/I think the original patch was preferable; this revised version would add the flag on archs other than x86 AFAICS.
AFAIK it doesn't really matter here because this makefile is windows only and this section (in webrev.01) if specific to VS2010 that cannot be used to build jdk6. I just changed my "original research" fix to the variant from jdk7 (http://hg.openjdk.java.net/hsx/jdk7u/hotspot/file/75c36a461ecd/make/windows/makefiles/compile.make).
Also I do not understand this part in original patch line 215 (http://cr.openjdk.java.net/~andrew/openjdk6/20131015/hotspot/make/windows/makefiles/compile.make.html):
LD_FLAGS = $(SAFESEH_FLAG) $(LD_FLAGS)
SAFESEH_FLAG = /SAFESEH
What is the point in setting SAFESEH_FLAG variable after it was used to
set LD_FLAGS?
Separate webrev for safeseh flag remove - http://cr.openjdk.java.net/~akasko/jdk6/webrev_hotspot_sa_safeseh_disabled.00/ It is actually the rollback of this change [10] from initial patch.This essentially removes the security fix for the serviceability agent. I'm not sure whether that's wise. On the other hand, this issue (8015614) doesn't have a CVE number, so it's just a defense-in-depth fix, ensuring all libraries have safe exception handler tables AFAICS. http://msdn.microsoft.com/en-us/library/9a89h429(v=vs.110).aspx As far as I can tell, the build issue arises because something is being linked against that doesn't have SEH tables. From what I've read, without the flag, the files being built will still have SEH tables if possible, but it can't guarantee it. Omair, what are your thoughts?Another round of windows builds is in progress (problematic i586 hotspot is already passed).Both windows builds finished successfully with these patches.PS: maybe it's better to combine both oneliner changes into single patch. [1] http://cr.openjdk.java.net/~akasko/jdk6/hotspot_sawindbg_safeseh_error.txt [2] https://bugs.openjdk.java.net/browse/JDK-7017110 [3] https://bugs.openjdk.java.net/browse/JDK-7160624 [4] http://msdn.microsoft.com/en-us/library/9a89h429%28v=vs.71%29.aspx [5] http://stackoverflow.com/questions/14710577/error-lnk2026-module-unsafe-for-safeseh-image [6] http://stackoverflow.com/questions/10599940/module-unsafe-for-safeseh-image-c [7] http://stackoverflow.com/questions/1610786/find-windows-dlls-not-compiled-with-safeseh [8] http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-April/005743.html [9] http://hg.openjdk.java.net/hsx/jdk7u/hotspot/diff/75c36a461ecd/make/windows/makefiles/compile.make [10] http://cr.openjdk.java.net/~andrew/openjdk6/20131015/hotspot/make/windows/makefiles/sa.make.udiff.html-- Regards, Alex Kasko
-- Regards, Alex Kasko
smime.p7s
Description: S/MIME Cryptographic Signature
