Re: RFR 8209064: Make intellij support more robust after changes for 2018.2

[Magnus Ihse Bursie]

Hi Maurizio!

Even if this only incidentally relates to the build, please always 
include build-dev when making changes in the "make" directory.


As far as I can understand, your changes looks good. One question: the 
build.xml was previously stored as a "template", and copied to the 
output directory. Now it's left in the source tree. I assume that there 
was no actual transformations or changes made to the template before? So 
that the scripts do not modify the source tree version, that is.


/Magnus

On 2018-08-07 13:21, Maurizio Cimadamore wrote:

Hi,
last week I submitted an 'emergency' patch to fix intellij project 
support after 2018.2 changes. The goal of these changes was to move 
the build.xml ant file out of the .idea folder, as the IDE no longer 
supported DOM indexing in such folders (as a result of 
https://youtrack.jetbrains.com/issue/IDEA-189915). As a workaround, I 
tweaked the scripts to copy build.xml in the build folder.


Thinking more about this issue, there's a more robust fix possible, 
which doesn't involve moving files to the build folder (which could be 
potentially unreliable, depending on how people build the JDK). In 
fact, the best solution is to leave build.xml where it is, and fix the 
remaining configuration files to point at it. This allows to revert 
all changes in the scripts that set up the project configuration 
(bin/idea.sh for JDK, and make/langtools/build.xml for langtools).


For the langtools project a bit more changes were necessary, given 
that in langtools we did not have a 'template' folder - and all 
intellij files were dumped onto the same path. So I had to move the 
configuration langtools files (all but build.xml) under a new template 
folder (located under make/langtools/intellij/make) and place 
build.xml outside it. Then tweak the build.xml script to work off this 
new template folder. These are all small conceptual changes, but the 
impact on the webrev is quite biggie (because of file renaming etc.).


I also took the chance to fix some issues with the JDK project ANT 
configuration (see changes in make/idea/template/workspace.xml), as 
the last changes did not update the location of the ant file used here 
- as a result no ant target entries were showing up under the Build menu.


Webrev here:

http://cr.openjdk.java.net/~mcimadamore/8209064/

Cheers
Maurizio

Re: RFR 8208183: update HSDIS plugin license to UPL

[Magnus Ihse Bursie]

Now that hsdis has a more permissive license, would it make sense to 
include the build of hsdis in the rest of the OpenJDK build system, 
instead of having a separate Makefile?


/Magnus

On 2018-07-25 14:59, David Buck wrote:

Hi!

Please approve this license change for the HSDIS plugin source code. 
This change replaces the GPL2 license text with Oracle's Universal 
Permissive License v 1.0. [0]


bug report: https://bugs.openjdk.java.net/browse/JDK-8208183

webrev: http://cr.openjdk.java.net/~dbuck/jdk8188071/

Cheers,
-Buck

[0] https://oss.oracle.com/licenses/upl/

Re: RFR 8208183: update HSDIS plugin license to UPL

[Aleksey Shipilev]

On 08/21/2018 11:58 AM, Magnus Ihse Bursie wrote:
> Now that hsdis has a more permissive license, would it make sense to include 
> the build of hsdis in
> the rest of the OpenJDK build system, instead of having a separate Makefile?

Yes, please. And it would be absolutely fantastic to actually build it and ship 
it in default
OpenJDK images :)

-Aleksey

Re: RFR 8208183: update HSDIS plugin license to UPL

[Magnus Ihse Bursie]

Yes, please. And it would be absolutely fantastic to actually build it and ship 
it in default
OpenJDK images :)


Am I correct in understanding that there are no more legal barriers 
towards doing such a thing anymore?


I can easily add a new make target to build hsdis.

Adding a new binary to the OpenJDK images will require a CSR. This in 
turn will likely require that there are proper tests that can be run (I 
have no idea of the current status of hsdis testing). I can't help you 
with either of these two.


/Magnus

Re: RFR 8208183: update HSDIS plugin license to UPL

[Magnus Ihse Bursie]

On 2018-08-21 12:14, Magnus Ihse Bursie wrote:


Yes, please. And it would be absolutely fantastic to actually build 
it and ship it in default

OpenJDK images :)


Am I correct in understanding that there are no more legal barriers 
towards doing such a thing anymore?


I can easily add a new make target to build hsdis.


I opened https://bugs.openjdk.java.net/browse/JDK-8209784 for this.

/Magnus



Adding a new binary to the OpenJDK images will require a CSR. This in 
turn will likely require that there are proper tests that can be run 
(I have no idea of the current status of hsdis testing). I can't help 
you with either of these two.


/Magnus

Re: RFR 8208183: update HSDIS plugin license to UPL

[Aleksey Shipilev]

On 08/21/2018 12:14 PM, Magnus Ihse Bursie wrote:
>> Yes, please. And it would be absolutely fantastic to actually build it and 
>> ship it in default
>> OpenJDK images :)
> 
> Am I correct in understanding that there are no more legal barriers towards 
> doing such a thing anymore?
> 
> I can easily add a new make target to build hsdis.
> 
> Adding a new binary to the OpenJDK images will require a CSR. This in turn 
> will likely require that
> there are proper tests that can be run (I have no idea of the current status 
> of hsdis testing). I
> can't help you with either of these two.

I wonder if CSR is required only for new enabled-by-default binaries?

There are different degrees of convenience. Having it built and shipped by 
default would be the most
convenient. Having the configure/build option to include hsdis into image, not 
enabled by default,
is fine too, as we can enable it for our builds. Having the separate build 
target is also fine, as
we can add the post-build shell command to copy it in place.

Let's do whatever is simpler from those options.

Thanks,
-Aleksey

Where to find the 3rd party libraries used by --with-graalunit-lib

[Zhongwei Yao]

Hi, all,

To run Graal unit test included in OpenJDK's jtreg tests, I need to add 
"-with-graalunit-lib" to specify the graalunit-lib path. But I can't find where 
I can get such libs. Could you point me to where or how to get them? Thanks!

--
Best regards,
Zhongwei

Re: Linux + Clang + execstack

[Magnus Ihse Bursie]

On 2018-08-21 02:03, David Holmes wrote:

On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
On Mon, Aug 20, 2018 at 4:18 PM David Holmes > wrote:


    Hi Arthur,

    cc'ing build-dev as this is currently a build issue.

    On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
 > Hi,
 >
 > At Google we're trying to build hotspot on Linux with clang. One
    thing that
 > happens is that the resulting libjvm.so is stack executable. When
    running
 > hotspot we get warnings about the stack being executable.
 >
 > Compiling an assembly file into the final .so results in the
    stack being
 > executable. In this case the file is linux_x86_64.s. This doesn't
    happen
 > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot
    linker flag
 > with gcc in flags-ldflags.m4. When using clang that linker 
flag isn't

 > passed.
 >
 > Doing something like the solution in
 > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
 > fixes the problem without the use of linker flags.

    You mean the source code directives for the linker?

Sorry, I wasn't specific enough, I meant the flags for the assembler.
#if defined(__linux__) && defined(__ELF__)
.section        .note.GNU-stack, "", %progbits
#endif


    I think I prefer to see this handled explicitly in the build as is
    currently done. Can we just adjust 
./make/autoconf/flags-ldflags.m4 to

    pass the linker flags for gcc and clang?

I don't mind this solution, but it seems like the right thing to do 
is to fix things at the source level and remove extra unnecessary 
linker flags.


Personally I see this as source code pollution. The concept of 
executable stacks has nothing to do with what is being expressed by 
the source code, or the language used for it.


Just my 2c. I'll defer to build folk ... though they are still on 
vacation at the moment.


I agree with David. The executable stack is a build option. Even if you 
change the source code so the compiler/assember does the right thing, we 
would still want to keep the compiler option. (Otherwise one day you'll 
end up with executable stacks due to someone adding a new asm file and 
forgetting the "magic incantation".)


And, since we will keep the compiler option, there seems little point in 
also adding this stuff to the asm files.


To address your concerns on clang: we should reasonably be giving the 
same options to clang. There is no good reason, except for oversight, 
that this is not done already. (Cleaning up and unifying the compiler 
flags is an ongoing, but slowly moving, process.) So the correct fix is 
to update flags-ldflags.m4.


/Magnus





I removed "-Wl,-z,noexecstack" from the flags after adding the above 
assembler flags and libjvm.so is still correctly not stack 
executable. I don't really mind either way though. Maybe it's good to 
have an extra safeguard in the linker flags.



 > The jtreg test 
test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java

 > checks for the stack being executable.
 >
 > Any thoughts? If there are no objections, I can propose a patch
    that works
 > for both gcc and clang on Linux. Also, I'm not sure how/if macOS
    handles
 > this problem given that it uses clang.

    We don't seem to handle it at all on OS X. Does OS X prevent 
executable

    stacks itself?

A quick search, according to Wikipedia 
(https://en.wikipedia.org/wiki/Executable_space_protection#macOS), 
64-bit executables on macOS aren't stack or heap executable. Not sure 
if that information is accurate though.


Seems to be:

https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html 



"macOS and iOS provide two features that can make it harder to exploit 
stack and buffer overflows: address space layout randomization (ASLR) 
and a non-executable stack and heap."


Cheers,
David



    David

Internal error: Invalid feature tested: fprof

[Petr Sumbera]

Hi,

I'm building JDK 10 for Solaris and I'm getting following error:

gmake[4]: Leaving directory 
'/builds/psumbera/userland-openjdk/components/openjdk-10/hotspot/make'
lib/JvmFeatures.gmk:91: *** Internal error: Invalid feature tested: 
fprof.  Stop.

gmake[3]: *** [make/Main.gmk:263: hotspot-server-libs] Error 2
gmake[3]: *** Waiting for unfinished jobs

Any idea what could be possible wrong?

Thanks,

Petr

Re: RFR 8208183: update HSDIS plugin license to UPL

[Volker Simonis]

On Tue, Aug 21, 2018 at 12:14 PM, Magnus Ihse Bursie
 wrote:
>
>> Yes, please. And it would be absolutely fantastic to actually build it and
>> ship it in default
>> OpenJDK images :)
>
>
> Am I correct in understanding that there are no more legal barriers towards
> doing such a thing anymore?
>
> I can easily add a new make target to build hsdis.
>
> Adding a new binary to the OpenJDK images will require a CSR.

Do we really need a CSR for hsdis? hsdis is a shared library/DLL and
not a "binary" which can be called by the user or executed
stand-alone. The functionality offered by hsdis is only accessible by
already existing command line parameters (like -XX:+PrintAssembly).

The CSR FAQ [1] only mentions (among others):

- Adding or removing a command in $JDK/bin
- Adding, removing, or changing a command line option

which both don't seem to be applicable to hsdis.

Regards,
Volker

PS: and just to be clear - I'm all for having hsdis in the default images :)

[1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs

> This in turn
> will likely require that there are proper tests that can be run (I have no
> idea of the current status of hsdis testing). I can't help you with either
> of these two.
>
> /Magnus

[Newbie question] Strange errors trying to build the JDK

[Zambonifofex]

Hello, everyone.

I am new to collaborating to the JDK, so sorry if this question is too
newbie‐ish.

I have recently been affected by a minor bug in the ‘java.desktop’
module on Linux. I figured I’d try to fix it by myself, so I followed
the steps in the “How to Contribute” page, the “Building” page, as
well as some more that I could find online.

The bug number is ‘7162479’. The bug is that it calling
‘setLocationByPlatform(true)’ on a ‘JFrame’ will not work if
‘setResizable(false)’ has been called on the same ‘JFrame’.

When I tried to build the JDK with ‘make images’, after getting a
couple errors related to the changes I made and fixing them, I started
to face a strange error that was not related to the changes I made at
all.

Here is the log I get when trying to run ‘make images’ currently, as
well as the output of ‘hg id’, if that’s of any help (where
‘/home/zambonifofex/jdk $’ is the prompt):

/home/zambonifofex/jdk/ $ hg id
2e91d927e00c+ tip
/home/zambonifofex/jdk/ $ make images
Building target 'images' in configuration
'linux-x86_64-normal-server-release'
lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
failed
make[3]: ***
[/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects]
Error 1
make[3]: *** Deleting file
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
make[2]: *** [hotspot-server-libs] Error 1
make[2]: *** Waiting for unfinished jobs

ERROR: Build failed for target 'images' in configuration
'linux-x86_64-normal-server-release' (exit code 2)

=== Make failed targets repeated here ===
lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
failed
make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
=== End of repeated output ===

Hint: Try searching the build log for the name of the first failed target.
Hint: See doc/building.html#troubleshooting for assistance.

/home/zambonifofex/jdk/make/Init.gmk:300: recipe for target 'main' failed
make[1]: *** [main] Error 1
/home/zambonifofex/jdk/make/Init.gmk:186: recipe for target 'images' failed
make: *** [images] Error 2
/home/zambonifofex/jdk/ $

Any help would be appreciated. Thanks in advance.

Re: RFR 8208183: update HSDIS plugin license to UPL

[Andrew Haley]

On 08/21/2018 11:14 AM, Magnus Ihse Bursie wrote:
> Am I correct in understanding that there are no more legal barriers 
> towards doing such a thing anymore?

You'd still be linking GPLv2-only code (libjvm) against GPLv3-or-later
code (binutils).  IANAL, but I suspect you can't get around the GPLv3
that easily.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Internal error: Invalid feature tested: fprof

[Magnus Ihse Bursie]

What version of bash and Gnu make do you have? What is your configure command 
line?

/Magnus

> 21 aug. 2018 kl. 16:03 skrev Petr Sumbera :
> 
> Hi,
> 
> I'm building JDK 10 for Solaris and I'm getting following error:
> 
> gmake[4]: Leaving directory 
> '/builds/psumbera/userland-openjdk/components/openjdk-10/hotspot/make'
> lib/JvmFeatures.gmk:91: *** Internal error: Invalid feature tested: fprof.  
> Stop.
> gmake[3]: *** [make/Main.gmk:263: hotspot-server-libs] Error 2
> gmake[3]: *** Waiting for unfinished jobs
> 
> Any idea what could be possible wrong?
> 
> Thanks,
> 
> Petr

Re: RFR 8208183: update HSDIS plugin license to UPL

[John Rose]

On Aug 21, 2018, at 9:41 AM, Andrew Haley  wrote:
> 
> On 08/21/2018 11:14 AM, Magnus Ihse Bursie wrote:
>> Am I correct in understanding that there are no more legal barriers 
>> towards doing such a thing anymore?
> 
> You'd still be linking GPLv2-only code (libjvm) against GPLv3-or-later
> code (binutils).  IANAL, but I suspect you can't get around the GPLv3
> that easily.


IANAL2 but bringing in a new set of source code into the OpenJDK build
always requires care with IP issues, which AFAIK need to be triple checked
by real Ls.

That said, the GPL (per se) isn't necessarily an issue here, if one were
to select a disassembly engine that isn't under GPL.  Please see:

  https://bugs.openjdk.java.net/browse/JDK-8188073

for a tracking bug for the option of integrating the Capstone library
as a plugin.  Perhaps the Capstone builds could include an artifact
for the JVM?  (Just thinking out loud here.)

— John

Re: RFR 8208183: update HSDIS plugin license to UPL

[mark . reinhold]

2018/8/21 11:11:00 -0700, john.r.r...@oracle.com:
> On Aug 21, 2018, at 9:41 AM, Andrew Haley  wrote:
>> On 08/21/2018 11:14 AM, Magnus Ihse Bursie wrote:
>>> Am I correct in understanding that there are no more legal barriers 
>>> towards doing such a thing anymore?
>> 
>> You'd still be linking GPLv2-only code (libjvm) against GPLv3-or-later
>> code (binutils).  IANAL, but I suspect you can't get around the GPLv3
>> that easily.
> 
> IANAL2 but bringing in a new set of source code into the OpenJDK build
> always requires care with IP issues, which AFAIK need to be triple checked
> by real Ls.

Indeed.

Magnus -- I suggest you hold off on this until interested contributors
can check with their legal teams.  (I’ll help you with Oracle’s legal
team.)

- Mark

RFR: JDK 11 P1: 8209806: API docs should be updated to refer to javase11

[Jonathan Gibbons]

Please review a simple high priority fix for JDK 11 that updates the 
link in the bottom of each page of the generated API docs.


Instead of simply changing "10" to "11", the fix is to use the macro 
$(VERSION_NUMBER) instead, in line with other URLs nearby in the same 
makefile, and in the ExtLink taglet [1]


JBS: https://bugs.openjdk.java.net/browse/JDK-8209806
Webrev: http://cr.openjdk.java.net/~jjg/8209806/webrev.00/index.html

[1]: 
http://hg.openjdk.java.net/jdk/jdk11/file/ed52ea83f830/make/jdk/src/classes/build/tools/taglet/ExtLink.java#l66


-- Jon

Re: RFR: JDK 11 P1: 8209806: API docs should be updated to refer to javase11

[joe darcy]

+1

-Joe


On 8/21/2018 11:58 AM, Jonathan Gibbons wrote:
Please review a simple high priority fix for JDK 11 that updates the 
link in the bottom of each page of the generated API docs.


Instead of simply changing "10" to "11", the fix is to use the macro 
$(VERSION_NUMBER) instead, in line with other URLs nearby in the same 
makefile, and in the ExtLink taglet [1]


JBS: https://bugs.openjdk.java.net/browse/JDK-8209806
Webrev: http://cr.openjdk.java.net/~jjg/8209806/webrev.00/index.html

[1]: 
http://hg.openjdk.java.net/jdk/jdk11/file/ed52ea83f830/make/jdk/src/classes/build/tools/taglet/ExtLink.java#l66


-- Jon

RE: RFR: JDK 11 P1: 8209806: API docs should be updated to refer to javase11

[Iris Clark]

Looks good to me.

iris

-Original Message-
From: Jonathan Gibbons 
Sent: Tuesday, August 21, 2018 11:58 AM
To: build-dev@openjdk.java.net
Subject: RFR: JDK 11 P1: 8209806: API docs should be updated to refer to 
javase11

Please review a simple high priority fix for JDK 11 that updates the link in 
the bottom of each page of the generated API docs.

Instead of simply changing "10" to "11", the fix is to use the macro
$(VERSION_NUMBER) instead, in line with other URLs nearby in the same makefile, 
and in the ExtLink taglet [1]

JBS: https://bugs.openjdk.java.net/browse/JDK-8209806
Webrev: http://cr.openjdk.java.net/~jjg/8209806/webrev.00/index.html

[1]: 
http://hg.openjdk.java.net/jdk/jdk11/file/ed52ea83f830/make/jdk/src/classes/build/tools/taglet/ExtLink.java#l66

-- Jon

Re: RFR: JDK 11 P1: 8209806: API docs should be updated to refer to javase11

[Lance Andersen]

looks fine Jon
> On Aug 21, 2018, at 2:58 PM, Jonathan Gibbons  
> wrote:
> 
> Please review a simple high priority fix for JDK 11 that updates the link in 
> the bottom of each page of the generated API docs.
> 
> Instead of simply changing "10" to "11", the fix is to use the macro 
> $(VERSION_NUMBER) instead, in line with other URLs nearby in the same 
> makefile, and in the ExtLink taglet [1]
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8209806
> Webrev: http://cr.openjdk.java.net/~jjg/8209806/webrev.00/index.html
> 
> [1]: 
> http://hg.openjdk.java.net/jdk/jdk11/file/ed52ea83f830/make/jdk/src/classes/build/tools/taglet/ExtLink.java#l66
> 
> -- Jon

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR: JDK 11 P1: 8209806: API docs should be updated to refer to javase11

[Tim Bell]

Jon:

Looks good to me as well.

Tim


On 08/21/18 12:00, Lance Andersen wrote:

looks fine Jon

On Aug 21, 2018, at 2:58 PM, Jonathan Gibbons  
wrote:

Please review a simple high priority fix for JDK 11 that updates the link in 
the bottom of each page of the generated API docs.

Instead of simply changing "10" to "11", the fix is to use the macro 
$(VERSION_NUMBER) instead, in line with other URLs nearby in the same makefile, and in the ExtLink 
taglet [1]

JBS: https://bugs.openjdk.java.net/browse/JDK-8209806
Webrev: http://cr.openjdk.java.net/~jjg/8209806/webrev.00/index.html

[1]: 
http://hg.openjdk.java.net/jdk/jdk11/file/ed52ea83f830/make/jdk/src/classes/build/tools/taglet/ExtLink.java#l66

-- Jon


  
   

  Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 

Re: Linux + Clang + execstack

[Arthur Eubanks]

Adding the linker flag sounds good.

Opened JDK-8209817.

webrev coming soon.

On Tue, Aug 21, 2018 at 4:14 AM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2018-08-21 02:03, David Holmes wrote:
> > On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
> >> On Mon, Aug 20, 2018 at 4:18 PM David Holmes  >> > wrote:
> >>
> >> Hi Arthur,
> >>
> >> cc'ing build-dev as this is currently a build issue.
> >>
> >> On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
> >>  > Hi,
> >>  >
> >>  > At Google we're trying to build hotspot on Linux with clang. One
> >> thing that
> >>  > happens is that the resulting libjvm.so is stack executable. When
> >> running
> >>  > hotspot we get warnings about the stack being executable.
> >>  >
> >>  > Compiling an assembly file into the final .so results in the
> >> stack being
> >>  > executable. In this case the file is linux_x86_64.s. This doesn't
> >> happen
> >>  > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot
> >> linker flag
> >>  > with gcc in flags-ldflags.m4. When using clang that linker
> >> flag isn't
> >>  > passed.
> >>  >
> >>  > Doing something like the solution in
> >>  > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
> >>  > fixes the problem without the use of linker flags.
> >>
> >> You mean the source code directives for the linker?
> >>
> >> Sorry, I wasn't specific enough, I meant the flags for the assembler.
> >> #if defined(__linux__) && defined(__ELF__)
> >> .section.note.GNU-stack, "", %progbits
> >> #endif
> >>
> >>
> >> I think I prefer to see this handled explicitly in the build as is
> >> currently done. Can we just adjust
> >> ./make/autoconf/flags-ldflags.m4 to
> >> pass the linker flags for gcc and clang?
> >>
> >> I don't mind this solution, but it seems like the right thing to do
> >> is to fix things at the source level and remove extra unnecessary
> >> linker flags.
> >
> > Personally I see this as source code pollution. The concept of
> > executable stacks has nothing to do with what is being expressed by
> > the source code, or the language used for it.
> >
> > Just my 2c. I'll defer to build folk ... though they are still on
> > vacation at the moment.
>
> I agree with David. The executable stack is a build option. Even if you
> change the source code so the compiler/assember does the right thing, we
> would still want to keep the compiler option. (Otherwise one day you'll
> end up with executable stacks due to someone adding a new asm file and
> forgetting the "magic incantation".)
>
> And, since we will keep the compiler option, there seems little point in
> also adding this stuff to the asm files.
>
> To address your concerns on clang: we should reasonably be giving the
> same options to clang. There is no good reason, except for oversight,
> that this is not done already. (Cleaning up and unifying the compiler
> flags is an ongoing, but slowly moving, process.) So the correct fix is
> to update flags-ldflags.m4.
>
> /Magnus
>
>
>
> >
> >> I removed "-Wl,-z,noexecstack" from the flags after adding the above
> >> assembler flags and libjvm.so is still correctly not stack
> >> executable. I don't really mind either way though. Maybe it's good to
> >> have an extra safeguard in the linker flags.
> >>
> >>
> >>  > The jtreg test
> >> test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java
> >>  > checks for the stack being executable.
> >>  >
> >>  > Any thoughts? If there are no objections, I can propose a patch
> >> that works
> >>  > for both gcc and clang on Linux. Also, I'm not sure how/if macOS
> >> handles
> >>  > this problem given that it uses clang.
> >>
> >> We don't seem to handle it at all on OS X. Does OS X prevent
> >> executable
> >> stacks itself?
> >>
> >> A quick search, according to Wikipedia
> >> (https://en.wikipedia.org/wiki/Executable_space_protection#macOS),
> >> 64-bit executables on macOS aren't stack or heap executable. Not sure
> >> if that information is accurate though.
> >
> > Seems to be:
> >
> >
> https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html
> >
> >
> > "macOS and iOS provide two features that can make it harder to exploit
> > stack and buffer overflows: address space layout randomization (ASLR)
> > and a non-executable stack and heap."
> >
> > Cheers,
> > David
> >
> >>
> >> David
> >>
>
>

Re: [Newbie question] Strange errors trying to build the JDK

[David Holmes]

Hi,

You need to search further up the build log to try and find the actual 
error that occurred when building hotspot.


Run "make hotspot" and it should be easier to see.

David

On 20/08/2018 11:53 AM, Zambonifofex wrote:

Hello, everyone.

I am new to collaborating to the JDK, so sorry if this question is too
newbie‐ish.

I have recently been affected by a minor bug in the ‘java.desktop’
module on Linux. I figured I’d try to fix it by myself, so I followed
the steps in the “How to Contribute” page, the “Building” page, as
well as some more that I could find online.

The bug number is ‘7162479’. The bug is that it calling
‘setLocationByPlatform(true)’ on a ‘JFrame’ will not work if
‘setResizable(false)’ has been called on the same ‘JFrame’.

When I tried to build the JDK with ‘make images’, after getting a
couple errors related to the changes I made and fixing them, I started
to face a strange error that was not related to the changes I made at
all.

Here is the log I get when trying to run ‘make images’ currently, as
well as the output of ‘hg id’, if that’s of any help (where
‘/home/zambonifofex/jdk $’ is the prompt):

 /home/zambonifofex/jdk/ $ hg id
 2e91d927e00c+ tip
 /home/zambonifofex/jdk/ $ make images
 Building target 'images' in configuration
'linux-x86_64-normal-server-release'
 lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
failed
 make[3]: ***
[/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects]
Error 1
 make[3]: *** Deleting file
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
 make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
 make[2]: *** [hotspot-server-libs] Error 1
 make[2]: *** Waiting for unfinished jobs

 ERROR: Build failed for target 'images' in configuration
'linux-x86_64-normal-server-release' (exit code 2)

 === Make failed targets repeated here ===
 lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
failed
 make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
 === End of repeated output ===

 Hint: Try searching the build log for the name of the first failed target.
 Hint: See doc/building.html#troubleshooting for assistance.

 /home/zambonifofex/jdk/make/Init.gmk:300: recipe for target 'main' failed
 make[1]: *** [main] Error 1
 /home/zambonifofex/jdk/make/Init.gmk:186: recipe for target 'images' failed
 make: *** [images] Error 2
 /home/zambonifofex/jdk/ $

Any help would be appreciated. Thanks in advance.

Re: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests

[Igor Ignatyev]

http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/index.html 
 is a new 
version of patch, which moves only vmTestbase tests.

Thanks,
-- Igor 

> On Aug 20, 2018, at 11:07 PM, Igor Ignatyev  wrote:
> 
>>> It has been discussed (not widely enough and I accept that) in 8209547 and 
>>> the related email thread b/w JC(cc'ed) and myself.
>>> as I said, I might went a way too far, so I'll revert changes in the 
>>> non-vmTestbase tests and made appropriate changes in makefiles. what do you 
>>> think?
>> 
>> I think I need to see what you mean exactly :)
> sure, it will take some time for me to do that, hopefully will upload new 
> webrevs tomorrow morning PT. but the basic idea is to leave files in 
> test/hotspot/jtreg/compiler, runtime, gc, native_sanity, serviceability, 
> testlibrary as .c files, exactly as they were before, and restore 
> corresponding filenames in make/test/JtregNativeHotspot.gmk.

Re: [Newbie question] Strange errors trying to build the JDK

[Gustavo Romero]

Hi,

On 08/21/2018 08:00 PM, David Holmes wrote:

Hi,

You need to search further up the build log to try and find the actual error 
that occurred when building hotspot.

Run "make hotspot" and it should be easier to see.


In addition to David's suggestion you can also add before the command 
LOG=trace, like:

$ LOG=trace make hotspot

to spot the executed commands in the build process.


Regards,
Gustavo


David

On 20/08/2018 11:53 AM, Zambonifofex wrote:

Hello, everyone.

I am new to collaborating to the JDK, so sorry if this question is too
newbie‐ish.

I have recently been affected by a minor bug in the ‘java.desktop’
module on Linux. I figured I’d try to fix it by myself, so I followed
the steps in the “How to Contribute” page, the “Building” page, as
well as some more that I could find online.

The bug number is ‘7162479’. The bug is that it calling
‘setLocationByPlatform(true)’ on a ‘JFrame’ will not work if
‘setResizable(false)’ has been called on the same ‘JFrame’.

When I tried to build the JDK with ‘make images’, after getting a
couple errors related to the changes I made and fixing them, I started
to face a strange error that was not related to the changes I made at
all.

Here is the log I get when trying to run ‘make images’ currently, as
well as the output of ‘hg id’, if that’s of any help (where
‘/home/zambonifofex/jdk $’ is the prompt):

 /home/zambonifofex/jdk/ $ hg id
 2e91d927e00c+ tip
 /home/zambonifofex/jdk/ $ make images
 Building target 'images' in configuration
'linux-x86_64-normal-server-release'
 lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
failed
 make[3]: ***
[/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects]
Error 1
 make[3]: *** Deleting file
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
 make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
 make[2]: *** [hotspot-server-libs] Error 1
 make[2]: *** Waiting for unfinished jobs

 ERROR: Build failed for target 'images' in configuration
'linux-x86_64-normal-server-release' (exit code 2)

 === Make failed targets repeated here ===
 lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
failed
 make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
 === End of repeated output ===

 Hint: Try searching the build log for the name of the first failed target.
 Hint: See doc/building.html#troubleshooting for assistance.

 /home/zambonifofex/jdk/make/Init.gmk:300: recipe for target 'main' failed
 make[1]: *** [main] Error 1
 /home/zambonifofex/jdk/make/Init.gmk:186: recipe for target 'images' failed
 make: *** [images] Error 2
 /home/zambonifofex/jdk/ $

Any help would be appreciated. Thanks in advance.

Re: [Newbie question] Strange errors trying to build the JDK

[Ioi Lam]

I am not sure if this is documented anywhere. Try searching for "Error 
2". It usually will tell you where the error is.


Thanks
- Ioi


On 8/21/18 4:51 PM, Gustavo Romero wrote:

Hi,

On 08/21/2018 08:00 PM, David Holmes wrote:

Hi,

You need to search further up the build log to try and find the 
actual error that occurred when building hotspot.


Run "make hotspot" and it should be easier to see.


In addition to David's suggestion you can also add before the command 
LOG=trace, like:


$ LOG=trace make hotspot

to spot the executed commands in the build process.


Regards,
Gustavo


David

On 20/08/2018 11:53 AM, Zambonifofex wrote:

Hello, everyone.

I am new to collaborating to the JDK, so sorry if this question is too
newbie‐ish.

I have recently been affected by a minor bug in the ‘java.desktop’
module on Linux. I figured I’d try to fix it by myself, so I followed
the steps in the “How to Contribute” page, the “Building” page, as
well as some more that I could find online.

The bug number is ‘7162479’. The bug is that it calling
‘setLocationByPlatform(true)’ on a ‘JFrame’ will not work if
‘setResizable(false)’ has been called on the same ‘JFrame’.

When I tried to build the JDK with ‘make images’, after getting a
couple errors related to the changes I made and fixing them, I started
to face a strange error that was not related to the changes I made at
all.

Here is the log I get when trying to run ‘make images’ currently, as
well as the output of ‘hg id’, if that’s of any help (where
‘/home/zambonifofex/jdk $’ is the prompt):

 /home/zambonifofex/jdk/ $ hg id
 2e91d927e00c+ tip
 /home/zambonifofex/jdk/ $ make images
 Building target 'images' in configuration
'linux-x86_64-normal-server-release'
 lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects' 


failed
 make[3]: ***
[/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects] 


Error 1
 make[3]: *** Deleting file
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects' 


 make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
 make[2]: *** [hotspot-server-libs] Error 1
 make[2]: *** Waiting for unfinished jobs

 ERROR: Build failed for target 'images' in configuration
'linux-x86_64-normal-server-release' (exit code 2)

 === Make failed targets repeated here ===
 lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects' 


failed
 make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
 === End of repeated output ===

 Hint: Try searching the build log for the name of the first 
failed target.

 Hint: See doc/building.html#troubleshooting for assistance.

 /home/zambonifofex/jdk/make/Init.gmk:300: recipe for target 
'main' failed

 make[1]: *** [main] Error 1
 /home/zambonifofex/jdk/make/Init.gmk:186: recipe for target 
'images' failed

 make: *** [images] Error 2
 /home/zambonifofex/jdk/ $

Any help would be appreciated. Thanks in advance.

Re: Internal error: Invalid feature tested: fprof

[David Holmes]

Hi Petr,

On 22/08/2018 12:03 AM, Petr Sumbera wrote:

Hi,

I'm building JDK 10 for Solaris and I'm getting following error:

gmake[4]: Leaving directory 
'/builds/psumbera/userland-openjdk/components/openjdk-10/hotspot/make'
lib/JvmFeatures.gmk:91: *** Internal error: Invalid feature tested: 
fprof.  Stop.


fprof was removed during JDK 10 development. Are you using an old script 
to call configure?


David
-



gmake[3]: *** [make/Main.gmk:263: hotspot-server-libs] Error 2
gmake[3]: *** Waiting for unfinished jobs

Any idea what could be possible wrong?

Thanks,

Petr

Re: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests

[David Holmes]

Hi Igor,

On 22/08/2018 9:04 AM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/index.html 
 is 
a new version of patch, which moves only vmTestbase tests.


This seems okay in principle. I didn't verify all the mechanical changes 
individually.


make/common/TestFilesCompilation.gmk

I suspect you can just find all .c and .cpp files and process them 
together, rather than duplicate all the logic. But I'll leave that to 
Magnus to comment on.


make/test/JtregNativeHotspot.gmk

+ BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS := -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS


Just a note that defining these is obsolete once we use C11/C++11 - 
which I think is an intent for JDK 12 if possible.


---

 test/hotspot/jtreg/vmTestbase/gc/g1/unloading/libdefine.cpp

  #ifdef __cplusplus
! #define JNI_ENV_ARG(x, y) y
  #define JNI_ENV_PTR(x) x
  #else
  #define JNI_ENV_ARG(x, y) x , y
  #define JNI_ENV_PTR(x) (*x)
  #endif

If this is now a C++ source file why do you a still have the code that 
allows for either C or C++? Is this stuff that will be cleaned up in the 
later RFE?


---

The switch to C++ means a lot of code now needs:

+ #ifdef __cplusplus
+ extern "C" {
+ #endif

I still have to wonder whether it better to leave these as C tests and 
only convert to C++ as and when needed ... seems like so much work.


Anyway I'm off on vacation after today so I'll leave it to others to 
take this up.


Thanks,
David


Thanks,
-- Igor

On Aug 20, 2018, at 11:07 PM, Igor Ignatyev > wrote:


It has been discussed (not widely enough and I accept that) in 
8209547 and the related email thread b/w JC(cc'ed) and myself.
as I said, I might went a way too far, so I'll revert changes in the 
non-vmTestbase tests and made appropriate changes in makefiles. what 
do you think?


I think I need to see what you mean exactly :)
sure, it will take some time for me to do that, hopefully will upload 
new webrevs tomorrow morning PT. but the basic idea is to leave files 
in test/hotspot/jtreg/compiler, runtime, gc, native_sanity, 
serviceability, testlibrary as .c files, exactly as they were before, 
and restore corresponding filenames in make/test/JtregNativeHotspot.gmk.

Re: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests

[Igor Ignatyev]

Hi David,

thanks for looking at the webrev and all your comments. my answers are inlined.

enjoy your vacation!

-- Igor 

> On Aug 21, 2018, at 9:28 PM, David Holmes  wrote:
> 
> Hi Igor,
> 
> On 22/08/2018 9:04 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/index.html 
>>  is a 
>> new version of patch, which moves only vmTestbase tests.
> 
> This seems okay in principle. I didn't verify all the mechanical changes 
> individually.
> 
> make/common/TestFilesCompilation.gmk
> 
> I suspect you can just find all .c and .cpp files and process them together, 
> rather than duplicate all the logic. But I'll leave that to Magnus to comment 
> on.
I had to duplicate this foreach cycle to specify a correct TOOLCHAIN, w/o it 
linking fails on linux-slowdebug. 
> 
> make/test/JtregNativeHotspot.gmk
> 
> + BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS := -D__STDC_FORMAT_MACROS 
> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
> 
> Just a note that defining these is obsolete once we use C11/C++11 - which I 
> think is an intent for JDK 12 if possible.
initially I wanted to use  instead of  + 
-D__STDC_FORMAT_MACROS, but solaris studio apparently doesn't have cinttypes 
header file.

hotspot makefiles also use -D__STDC_, so I hope both places will be fixed 
together.

> 
> test/hotspot/jtreg/vmTestbase/gc/g1/unloading/libdefine.cpp
> 
>  #ifdef __cplusplus
> ! #define JNI_ENV_ARG(x, y) y
>  #define JNI_ENV_PTR(x) x
>  #else
>  #define JNI_ENV_ARG(x, y) x , y
>  #define JNI_ENV_PTR(x) (*x)
>  #endif
> 
> If this is now a C++ source file why do you a still have the code that allows 
> for either C or C++? Is this stuff that will be cleaned up in the later RFE?
yes, 8209547 will clean up JNI_ENV_ARG macros.

> 
> ---
> 
> The switch to C++ means a lot of code now needs:
> 
> + #ifdef __cplusplus
> + extern "C" {
> + #endif

that's true, and this patch adds 'extern "C"' very conservatively (basically to 
everywhere). this, if needed, can be cleaned up later.

> 
> I still have to wonder whether it better to leave these as C tests and only 
> convert to C++ as and when needed ... seems like so much work.
> 
> Anyway I'm off on vacation after today so I'll leave it to others to take 
> this up.
> 
> Thanks,
> David
> 
>> Thanks,
>> -- Igor
>>> On Aug 20, 2018, at 11:07 PM, Igor Ignatyev >> > wrote:
>>> 
> It has been discussed (not widely enough and I accept that) in 8209547 
> and the related email thread b/w JC(cc'ed) and myself.
> as I said, I might went a way too far, so I'll revert changes in the 
> non-vmTestbase tests and made appropriate changes in makefiles. what do 
> you think?
 
 I think I need to see what you mean exactly :)
>>> sure, it will take some time for me to do that, hopefully will upload new 
>>> webrevs tomorrow morning PT. but the basic idea is to leave files in 
>>> test/hotspot/jtreg/compiler, runtime, gc, native_sanity, serviceability, 
>>> testlibrary as .c files, exactly as they were before, and restore 
>>> corresponding filenames in make/test/JtregNativeHotspot.gmk.

Re: [Newbie question] Strange errors trying to build the JDK

[David Holmes]

Interesting - there is no actual error report in the log. Only this:

lib/JvmMapfile.gmk:141: recipe for target 
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects' 
failed


Looking at the gmk file we have:

$(JVM_OUTPUTDIR)/symbols-objects: $(BUILD_LIBJVM_ALL_OBJS)
$(call LogInfo, Generating symbol list from object files)
$(CD) $(JVM_OUTPUTDIR)/objs && \
	  $(DUMP_SYMBOLS_CMD) | $(NAWK) $(FILTER_SYMBOLS_AWK_SCRIPT) | $(SORT) 
-u > $@


I'd have to suspect one of the command variables is not set. I suspect 
the actual error text may be redirected to the symbols-objects file, but 
unfortunately that has been deleted by 'make'.


Check the generated spec.gmk file for the value of DUMP_SYMBOLS_CMD and 
NAWK.


David

On 22/08/2018 1:45 PM, Zambonifofex wrote:

Hello.

I’ve run the following commands (using the Fish shell):

 /home/zambonifofex/jdk/ $ make hotspot > ~/log.txt ^&1
 /home/zambonifofex/jdk/ $ env LOG=trace make hotspot > ~/log-trace.txt ^&1
 /home/zambonifofex/jdk/ $

I’ll attach the generated files in this email.

Thanks once again.
On Tue, Aug 21, 2018 at 8:51 PM Gustavo Romero
 wrote:


Hi,

On 08/21/2018 08:00 PM, David Holmes wrote:

Hi,

You need to search further up the build log to try and find the actual error 
that occurred when building hotspot.

Run "make hotspot" and it should be easier to see.


In addition to David's suggestion you can also add before the command 
LOG=trace, like:

$ LOG=trace make hotspot

to spot the executed commands in the build process.


Regards,
Gustavo


David

On 20/08/2018 11:53 AM, Zambonifofex wrote:

Hello, everyone.

I am new to collaborating to the JDK, so sorry if this question is too
newbie‐ish.

I have recently been affected by a minor bug in the ‘java.desktop’
module on Linux. I figured I’d try to fix it by myself, so I followed
the steps in the “How to Contribute” page, the “Building” page, as
well as some more that I could find online.

The bug number is ‘7162479’. The bug is that it calling
‘setLocationByPlatform(true)’ on a ‘JFrame’ will not work if
‘setResizable(false)’ has been called on the same ‘JFrame’.

When I tried to build the JDK with ‘make images’, after getting a
couple errors related to the changes I made and fixing them, I started
to face a strange error that was not related to the changes I made at
all.

Here is the log I get when trying to run ‘make images’ currently, as
well as the output of ‘hg id’, if that’s of any help (where
‘/home/zambonifofex/jdk $’ is the prompt):

  /home/zambonifofex/jdk/ $ hg id
  2e91d927e00c+ tip
  /home/zambonifofex/jdk/ $ make images
  Building target 'images' in configuration
'linux-x86_64-normal-server-release'
  lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
failed
  make[3]: ***
[/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects]
Error 1
  make[3]: *** Deleting file
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
  make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
  make[2]: *** [hotspot-server-libs] Error 1
  make[2]: *** Waiting for unfinished jobs

  ERROR: Build failed for target 'images' in configuration
'linux-x86_64-normal-server-release' (exit code 2)

  === Make failed targets repeated here ===
  lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
failed
  make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
  === End of repeated output ===

  Hint: Try searching the build log for the name of the first failed target.
  Hint: See doc/building.html#troubleshooting for assistance.

  /home/zambonifofex/jdk/make/Init.gmk:300: recipe for target 'main' failed
  make[1]: *** [main] Error 1
  /home/zambonifofex/jdk/make/Init.gmk:186: recipe for target 'images' 
failed
  make: *** [images] Error 2
  /home/zambonifofex/jdk/ $

Any help would be appreciated. Thanks in advance.