On 13/02/2017 1:54 PM, Yasumasa Suenaga wrote:
Hi David,
I'm a bit unclear on the problem being fixed - do I take it that
Oracle JDK binaries are not built as DSO's and so do not experience this
problem? Is there a reasonable way to test this (is it covered by any
existing tests) ?
You cannot
Hi David,
> I'm a bit unclear on the problem being fixed - do I take it that Oracle
JDK binaries are not built as DSO's and so do not experience this problem?
Is there a reasonable way to test this (is it covered by any existing
tests) ?
You cannot check this issue with Oracle JDK because it is n
Hi Volker,
On 10/02/2017 11:21 PM, Volker Simonis wrote:
On Fri, Feb 10, 2017 at 10:40 AM, Andrew Haley wrote:
On 10/02/17 03:13, Yasumasa Suenaga wrote:
We can calculate start address of executable (java command) through entry
point.
I updated webrev:
http://cr.openjdk.java.net/~ysuenaga/
On Fri, Feb 10, 2017 at 2:44 PM, Andrew Haley wrote:
> On 10/02/17 13:21, Volker Simonis wrote:
>> @Andrew: as this bug is assigned to you, I'd suggest to change it's
>> status to open, the priority to P3 and target it for 9 (i.e. Fix
>> Version = 9).
>
> OK, done. It should really not be assigne
On 10/02/17 13:21, Volker Simonis wrote:
> @Andrew: as this bug is assigned to you, I'd suggest to change it's
> status to open, the priority to P3 and target it for 9 (i.e. Fix
> Version = 9).
OK, done. It should really not be assigned to me, but the rather
inscrutable JIRA doesn't let me move i
On Fri, Feb 10, 2017 at 10:40 AM, Andrew Haley wrote:
> On 10/02/17 03:13, Yasumasa Suenaga wrote:
>> We can calculate start address of executable (java command) through entry
>> point.
>> I updated webrev:
>>
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.01/
>>
>> This patch can ig
On 10/02/17 03:13, Yasumasa Suenaga wrote:
> We can calculate start address of executable (java command) through entry
> point.
> I updated webrev:
>
> http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.01/
>
> This patch can ignore page size.
Excellent. I think this is safe for JDK 9, b
Hi Andrew,
We can calculate start address of executable (java command) through entry
point.
I updated webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.01/
This patch can ignore page size.
Thanks,
Yasumasa
2017-02-10 7:53 GMT+09:00 Yasumasa Suenaga :
> On 2017/02/10 1:04, A
On 2017/02/10 1:04, Andrew Haley wrote:
On 09/02/17 14:57, Yasumasa Suenaga wrote:
So I think we can use sysconf(3) to get page size.
In OpenJDK code we should use os::vm_page_size() for the physical page
size.
SA is not part of HotSpot (not in libjvm).
Thus SA cannot access HotSpot internal
On 09/02/17 14:57, Yasumasa Suenaga wrote:
> So I think we can use sysconf(3) to get page size.
In OpenJDK code we should use os::vm_page_size() for the physical page
size.
Andrew.
I guess this isn't the physical page size, but some notional 4k page,
which may or may not correspond to the real page size?
I think we should use sysconf(3) with _SC_PAGESIZE or p_align in ELF PHDR.
+// Align page size
+ph->core->dynamic_addr = auxv->a_un.a_val & ~(uin
On 09/02/17 14:40, Yasumasa Suenaga wrote:
> Hi Andrew,
>
> I checked with GDB, readelf and libsaproc debug message.
> I found that we should calculate .dynamic address from entry point in ELF.
>
> I uploaded webrev. This patch works fine on JDK 9 and JDK 10.
>
>http://cr.openjdk.java.net/~y
Hi Andrew,
I checked with GDB, readelf and libsaproc debug message.
I found that we should calculate .dynamic address from entry point in ELF.
I uploaded webrev. This patch works fine on JDK 9 and JDK 10.
http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.00/
Thanks,
Yasumasa
On 201
On 08/02/17 14:21, Yasumasa Suenaga wrote:
> It differs 1 page (0x1000).
> In this case, according to GDB, `java` was loaded 0x563bc6dd7000.
> According to readelf of `java`, offset of dynamic section is 0x1d28.
> So I want to investigate why we found 1 memory page difference.
> (Is it caused by AS
Hi Andrew,
I could reproduce it in my environment.
* libsaproc debug
```
libsaproc DEBUG: address of _DYNAMIC is 0x563bc6dd8d28
```
* Address of .dynamic in GDB
```
0x563bc6dd7d28 - 0x563bc6dd7f68 is .dynamic
```
It differs 1 page (0x1000).
In this case, according to GDB, `jav
Okay, thanks.
The patch will have to be submitted to JDK 9 first and then back-
ported to earlier releases. Unfortunately it doesn't work on JDK 9.
I don't know why: I spent some time looking at it, but I couldn't
figure out what was wrong.
Is there any way you could have a look? This is using
16 matches
Mail list logo
