gt;
> >> -Original Message-
> >> From: Erik Joelsson
> >> Sent: Freitag, 10. Mai 2019 16:29
> >> To: Baesken, Matthias ; David Holmes
> >> ; 'build-dev@openjdk.java.net' >> d...@openjdk.java.net>
> >> Subject: Re: RFR: 81
, Matthias ; David Holmes
; 'build-dev@openjdk.java.net'
Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds -
was : RE: gcc FORTIFY_SOURCE application security flags
Hello Matthias,
I think just -U_FORTIFY_SOURCE should be enough to unset it, no need to
also set it to
openjdk.java.net' d...@openjdk.java.net>
> Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds -
> was : RE: gcc FORTIFY_SOURCE application security flags
>
> Hello Matthias,
>
> I think just -U_FORTIFY_SOURCE should be enough to unset it, no need to
> also set
gt; 4.6 in jdk/jdk )
Best regards, Matthias
-Original Message-
From: Erik Joelsson
Sent: Donnerstag, 9. Mai 2019 15:18
To: Baesken, Matthias ; David Holmes
; 'build-dev@openjdk.java.net'
Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds -
was : RE: gcc FOR
used gcc's we are always > 4.6 in jdk/jdk )
> >
> > Best regards, Matthias
> >
> >
> >> -Original Message-
> >> From: Erik Joelsson
> >> Sent: Donnerstag, 9. Mai 2019 15:18
> >> To: Baesken, Matthias ; David Holmes
> &g
vid Holmes
; 'build-dev@openjdk.java.net'
Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds -
was : RE: gcc FORTIFY_SOURCE application security flags
Hello,
I just tried this and you are correct. However, it does seem to work if
you instead use -U_FORTIFY_SOURCE.
/E
enjdk.java.net>
> Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds -
> was : RE: gcc FORTIFY_SOURCE application security flags
>
> Hello,
>
> I just tried this and you are correct. However, it does seem to work if
> you instead use -U_FORTIFY_SOURCE.
&
Hello,
I just tried this and you are correct. However, it does seem to work if
you instead use -U_FORTIFY_SOURCE.
/Erik
On 2019-05-09 05:36, Baesken, Matthias wrote:
Hi Erik, while setting -O and -O (with x != y ) in one gcc/g++
command line call works ,
setting together -D_FORT
Hi Erik, while setting -O and -O (with x != y ) in one gcc/g++
command line call works ,
setting together -D_FORTIFY_SOURCE=2 and -D_FORTIFY_SOURCE=0 in one
command line call generates a warning , so I think we cannot do that .
Best regards, Matthias
> Hello Matthias,
>
> O
Hi Matthias,
For some background about the -O2 -ffp-contract=off flags for
sharedRuntimeTrig.cpp and sharedRuntimeTrans.cpp see:
https://bugs.openjdk.java.net/browse/JDK-8210425
My understanding is that if there is a per-file override of the
optimization level, the compilation command will end up
Hello Matthias,
On 2019-05-08 06:27, Baesken, Matthias wrote:
Hello,I looked a bit more into it .
It seems to me , that when -ffp-contract=off is available which is the
case with current gcc versions , we want to optimize the 2 special files (
sharedRuntimeTrig.cpp / sharedRunti
Hello,I looked a bit more into it .
It seems to me , that when -ffp-contract=off is available which is the
case with current gcc versions , we want to optimize the 2 special files (
sharedRuntimeTrig.cpp / sharedRuntimeTrans.cpp ).
see the following comments :
jdk/make/hotspot/li
lag .
> >
> >
> > Best Regards, Matthias
> >
> >
> >
> >> -Original Message-
> >> From: Baesken, Matthias
> >> Sent: Dienstag, 7. Mai 2019 16:55
> >> To: 'Erik Joelsson' ; 'build-
> >> d...@openj
oelsson' ; 'build-
d...@openjdk.java.net'
Cc: 'Kim Barrett' ; Zeller, Arno
Subject: RE: gcc FORTIFY_SOURCE application security flags
Hello, I looked at JDK-8050803 .
There are build issues reported when using the _FORTIFY_SOURCE flag .
However I only noticed one build issue, th
// don't want to fail the test because of this.
>FILE* pfile = posix::FOpen(premature_exit_filepath, "w");
> - fwrite("0", 1, 1, pfile);
> + size_t cnt= fwrite("0", 1, 1, pfile);
> + assert(cnt == (size_t)1);
>fclose(pf
st because of this.
FILE* pfile = posix::FOpen(premature_exit_filepath, "w");
- fwrite("0", 1, 1, pfile);
+ size_t cnt= fwrite("0", 1, 1, pfile);
+ assert(cnt == (size_t)1);
fclose(pfile);
}
}
> -Original Message-
> From: Erik Joe
* Matthias Baesken:
> I would prefer to get a hs_err file, do you know a way to get this in
> context of the gcc flag _FORTIFY_SOURCE ?
__fortify_fail should eventually raise SIGABRT. So if you install a
handler for that signal, you should be able to generate hs_err file.
__fortify_fail is diff
gt;maybe some of you are aware of the gcc FORTIFY_SOURCE application
> security flags.
> > Developers can enable compile and also runtime checks for some string /
> memory related operations with the flag.
> >
> > See details :
> > https://access.redhat.com/blogs/766
> On May 3, 2019, at 11:12 AM, Baesken, Matthias
> wrote:
>
>
>
>
> Hello.
>maybe some of you are aware of the gcc FORTIFY_SOURCE application
> security flags.
> Developers can enable compile and also runtime checks for some string /
> memory related o
Hello Matthias,
We have tried to use it before but later removed it. See
https://bugs.openjdk.java.net/browse/JDK-8050803
/Erik
On 2019-05-03 08:12, Baesken, Matthias wrote:
Hello.
maybe some of you are aware of the gcc FORTIFY_SOURCE application
security flags.
Developers can
Hello.
maybe some of you are aware of the gcc FORTIFY_SOURCE application security
flags.
Developers can enable compile and also runtime checks for some string / memory
related operations with the flag.
See details :
https://access.redhat.com/blogs/766093/posts/1976213
Have you tried
21 matches
Mail list logo
