You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2008/09/04 11:21:36 UTC
Re: [classlib][build][freebsd] Fix Classlib build for FreeBSD 6.3 x86
After seeing your change adding the md5sum for freebsd I tried a build on
freebsd 7.0-RELEASE on x86_64.
I don't see the jlong/void* problems as they are both 64-bit on my machine.
However, it is common in classlib to fix this by doing a double cast although
it is more common to use the classlib defines (IDATA) or (UDATA) than size_t.
I have an almost identical fix for the hysl.c issue but I made one additional
change which I have committed as r691931 to keep the iconv and mbtowc code
consistent.
I fixed the hysock issue with r691184 and r691191 since I came across this
on another platform a short while ago.
I "fixed" the signal issues with the unrelated r691267.
I also needed the following changes which I assume are freebsd6/7 differences.
I'm sure the second is fine but can you check to see if these cause problems
on your 6.3 system?
Index: modules/luni/src/main/native/luni/unix/OSMemoryLinux32.c
===================================================================
--- modules/luni/src/main/native/luni/unix/OSMemoryLinux32.c (revision 691923)
+++ modules/luni/src/main/native/luni/unix/OSMemoryLinux32.c (working copy)
@@ -95,14 +95,20 @@
jboolean result = 0;
IDATA m_addr = (IDATA)addr;
int page_size = getPageSize();
- char* vec = NULL;
+#if defined(FREEBSD)
+#define HY_VEC_T char
+#else
+#define HY_VEC_T unsigned char
+#endif
+ HY_VEC_T* vec = NULL;
int page_count = 0;
int align_offset = m_addr%page_size;//addr should align with the boundary of a page.
m_addr -= align_offset;
size += align_offset;
page_count = (size+page_size-1)/page_size;
- vec = (char *) hymem_allocate_memory(page_count*sizeof(char));
- if(mincore((void *)m_addr, size , (unsigned char *)vec)==0) //or else there is error about the mincore and return false;
+ vec = (HY_VEC_T *) hymem_allocate_memory(page_count*sizeof(char));
+ if(mincore((void *)m_addr, size, vec)==0) //or else there is error about the mincore and return false;
+#undef HY_VEC_T
{
int i;
for(i=0 ;i<page_count;i++)
Index: modules/luni/src/main/native/luni/unix/freebsd/OSResourcesMonitor.c
===================================================================
--- modules/luni/src/main/native/luni/unix/freebsd/OSResourcesMonitor.c (revision 691923)
+++ modules/luni/src/main/native/luni/unix/freebsd/OSResourcesMonitor.c (working copy)
@@ -37,7 +37,7 @@
{
unsigned long free;
unsigned long total;
- int len = sizeof(free);
+ size_t len = sizeof(free);
if (sysctlbyname("vm.stats.vm.v_free_count", &free, &len, NULL, 0) == -1) {
return FALSE;
Additionally, I needed to compile new versions of the icu dependencies for
freebsd7 that will conflict with the 6.3 versions. I think we can handle
the conflict by using the hy.platform defines used to handle the
libstdc++5/libstdc++6 conflict on linux.
I have a few vm fixes too. I'll try to commit these later today.
After building, when I try to run HelloWorld, I have significant problems
with pthread related code. Using libthr.so I get a hang early in the
startup. If I force the use of libkse.so with /etc/libmap.conf then I
get further but it hangs during shutdown. I'll post more details of these
when I get some spare time to look at them again.
I assume you'll see similar problems.
Regards,
Mark.
In message <5c...@mail.gmail.com>,
"Ilya Berezhniuk" writes:
>
> Hi all,
>
> I prepared a patch to fix Harmony build on my FreeBSD 6.3 machine.
>
> Could anyone of classlib gurus review and approve Classlib part of
> this patch [1], as I'm not familiar with Classlib coding rules?
>
> Most of the problems were caused by casting jlong to void*, because
> sizes of these types are different, and -Werror was specified.
> In the patch I used double casting like (void*)(size_t)(jlong value).
>
> [1] https://issues.apache.org/jira/browse/HARMONY-5967
>
> --
> Ilya.
>
Re: [classlib][build][freebsd] Fix Classlib build for FreeBSD 6.3 x86
Posted by Mark Hindess <ma...@googlemail.com>.
In message <5c...@mail.gmail.com>, "Ilya
Berezhniuk" writes:
>
> Mark,
>
> Sorry, I missed your r691951 commit - I think it will fix all my DRLVM
> build problems for FreeBSD/x86_64.
No problem. Knowing that you were working on it too I decided to get
busy committing all my outstanding changes so that we can hopefully
faster progress. I've got everything building and at least starting
to run. I've started another thread (since it's really broader than
classlib now) with details of where I've got to. I'd be very interested
in your thoughts on that. (And also in whether I got the changes for
registers - particularly eflags/flags - right. Some of these really
should probably be refactored into separate files rather than hacking
the linux ones but that can wait.)
-Mark.
Re: [classlib][build][freebsd] Fix Classlib build for FreeBSD 6.3 x86
Posted by Ilya Berezhniuk <il...@gmail.com>.
Mark,
Sorry, I missed your r691951 commit - I think it will fix all my DRLVM
build problems for FreeBSD/x86_64.
2008/9/4 Ilya Berezhniuk <il...@gmail.com>:
> Tim, Mark,
>
> Thanks a lot for your help!
>
> BTW, I'm already started porting to FreeBSD x86_64 (7.0 release), and
> also met mincore problem in OSMemoryLinux32.c; my patch looked like
> ===================================================================
> @@ -35,6 +35,13 @@
> #define MAP_FAILED ((void *) -1)
> #endif
>
> +/* FreeBSD has 'char*' type for 'vec' argument */
> +#if defined(FREEBSD)
> +typedef char* mincore_vec_type_t;
> +#else
> +typedef unsigned char* mincore_vec_type_t;
> +#endif
> +
> #define OS_JNI(func) JNICALL
> Java_org_apache_harmony_luni_platform_OSMemory_##func
>
> JNIEXPORT jboolean JNICALL
> Java_org_apache_harmony_luni_platform_OSMemory_isLittleEndianImpl(JNIEnv
> * env, jclass clazz)
> @@ -102,7 +109,7 @@
> size += align_offset;
> page_count = (size+page_size-1)/page_size;
> vec = (char *) hymem_allocate_memory(page_count*sizeof(char));
> - if(mincore((void *)m_addr, size , (unsigned char *)vec)==0)
> //or else there is error about the mincore and return false;
> + if(mincore((void *)m_addr, size ,
> (mincore_vec_type_t)vec)==0) //or else there is error about the
> mincore and return false;
> {
> int i;
> for(i=0 ;i<page_count;i++)
> ===================================================================
>
> I also had some problems with hysigunix.c and hysignal_context.* that
> disappeared at all now, and still have some problems with DRLVM build.
> Also I was forced to build ICU for x86_64.
>
> I'm going to finish DRLVM changes and suggest a patch for
> FreeBSD/x86_64 (and I'll split it into small patches if it become too
> large).
>
> Thanks,
> Ilya.
>
>
> 2008/9/4 Mark Hindess <ma...@googlemail.com>:
>>
>> In message <48...@gmail.com>, Tim Ellison writes:
>>>
>>> Mark Hindess wrote:
>>> > In message <48...@gmail.com>, Tim Ellison writes:
>>> >> Mark Hindess wrote:
>>> >>> +#if defined(FREEBSD)
>>> >>> +#define HY_VEC_T char
>>> >>> +#else
>>> >>> +#define HY_VEC_T unsigned char
>>> >>> +#endif
>>> >>> + HY_VEC_T* vec = NULL;
>>> >> Am I misreading this? It used to be char* on non-FREEBSD systems, and
>>> >> you needed to change it to be unsigned char* ?
>>> >
>>> > Not exactly. But your confusion is understandable. I should have explaine
>>> d
>>> > this change. I'm fixing two things:
>>> >
>>> > a) vec was a char* but the only place it was used as char* was in the
>>> > cast from the void* returned by hymem_allocate_memory. It was then
>>> > forced to unsigned char*. Logically it made more sense to just
>>> > change vec to unsigned char* and fix the cast.
>>> >
>>> > b) The type of the third parameter to mincore on freebsd needs to be cha
>>> r*.
>>> >
>>> > That should make more sense now?
>>>
>>> Yes, thanks. I had not figured out the 'double step'.
>>>
>>> > (Of course, if I'd committed it I would
>>> > have explained that in the commit message.)
>>>
>>> Of course ;-)
>>
>> I found an old Freebsd 6.2 qemu image and checked the change myself so
>> I've committed it as two trivial changes, rather than one complex change,
>> in r691981 and r691987.
>>
>> -Mark.
>>
>>
>>
>>
>>
>
--
Ilya.
Re: [classlib][build][freebsd] Fix Classlib build for FreeBSD 6.3 x86
Posted by Ilya Berezhniuk <il...@gmail.com>.
Tim, Mark,
Thanks a lot for your help!
BTW, I'm already started porting to FreeBSD x86_64 (7.0 release), and
also met mincore problem in OSMemoryLinux32.c; my patch looked like
===================================================================
@@ -35,6 +35,13 @@
#define MAP_FAILED ((void *) -1)
#endif
+/* FreeBSD has 'char*' type for 'vec' argument */
+#if defined(FREEBSD)
+typedef char* mincore_vec_type_t;
+#else
+typedef unsigned char* mincore_vec_type_t;
+#endif
+
#define OS_JNI(func) JNICALL
Java_org_apache_harmony_luni_platform_OSMemory_##func
JNIEXPORT jboolean JNICALL
Java_org_apache_harmony_luni_platform_OSMemory_isLittleEndianImpl(JNIEnv
* env, jclass clazz)
@@ -102,7 +109,7 @@
size += align_offset;
page_count = (size+page_size-1)/page_size;
vec = (char *) hymem_allocate_memory(page_count*sizeof(char));
- if(mincore((void *)m_addr, size , (unsigned char *)vec)==0)
//or else there is error about the mincore and return false;
+ if(mincore((void *)m_addr, size ,
(mincore_vec_type_t)vec)==0) //or else there is error about the
mincore and return false;
{
int i;
for(i=0 ;i<page_count;i++)
===================================================================
I also had some problems with hysigunix.c and hysignal_context.* that
disappeared at all now, and still have some problems with DRLVM build.
Also I was forced to build ICU for x86_64.
I'm going to finish DRLVM changes and suggest a patch for
FreeBSD/x86_64 (and I'll split it into small patches if it become too
large).
Thanks,
Ilya.
2008/9/4 Mark Hindess <ma...@googlemail.com>:
>
> In message <48...@gmail.com>, Tim Ellison writes:
>>
>> Mark Hindess wrote:
>> > In message <48...@gmail.com>, Tim Ellison writes:
>> >> Mark Hindess wrote:
>> >>> +#if defined(FREEBSD)
>> >>> +#define HY_VEC_T char
>> >>> +#else
>> >>> +#define HY_VEC_T unsigned char
>> >>> +#endif
>> >>> + HY_VEC_T* vec = NULL;
>> >> Am I misreading this? It used to be char* on non-FREEBSD systems, and
>> >> you needed to change it to be unsigned char* ?
>> >
>> > Not exactly. But your confusion is understandable. I should have explaine
>> d
>> > this change. I'm fixing two things:
>> >
>> > a) vec was a char* but the only place it was used as char* was in the
>> > cast from the void* returned by hymem_allocate_memory. It was then
>> > forced to unsigned char*. Logically it made more sense to just
>> > change vec to unsigned char* and fix the cast.
>> >
>> > b) The type of the third parameter to mincore on freebsd needs to be cha
>> r*.
>> >
>> > That should make more sense now?
>>
>> Yes, thanks. I had not figured out the 'double step'.
>>
>> > (Of course, if I'd committed it I would
>> > have explained that in the commit message.)
>>
>> Of course ;-)
>
> I found an old Freebsd 6.2 qemu image and checked the change myself so
> I've committed it as two trivial changes, rather than one complex change,
> in r691981 and r691987.
>
> -Mark.
>
>
>
>
>
Re: [classlib][build][freebsd] Fix Classlib build for FreeBSD 6.3 x86
Posted by Mark Hindess <ma...@googlemail.com>.
In message <48...@gmail.com>, Tim Ellison writes:
>
> Mark Hindess wrote:
> > In message <48...@gmail.com>, Tim Ellison writes:
> >> Mark Hindess wrote:
> >>> +#if defined(FREEBSD)
> >>> +#define HY_VEC_T char
> >>> +#else
> >>> +#define HY_VEC_T unsigned char
> >>> +#endif
> >>> + HY_VEC_T* vec = NULL;
> >> Am I misreading this? It used to be char* on non-FREEBSD systems, and
> >> you needed to change it to be unsigned char* ?
> >
> > Not exactly. But your confusion is understandable. I should have explaine
> d
> > this change. I'm fixing two things:
> >
> > a) vec was a char* but the only place it was used as char* was in the
> > cast from the void* returned by hymem_allocate_memory. It was then
> > forced to unsigned char*. Logically it made more sense to just
> > change vec to unsigned char* and fix the cast.
> >
> > b) The type of the third parameter to mincore on freebsd needs to be cha
> r*.
> >
> > That should make more sense now?
>
> Yes, thanks. I had not figured out the 'double step'.
>
> > (Of course, if I'd committed it I would
> > have explained that in the commit message.)
>
> Of course ;-)
I found an old Freebsd 6.2 qemu image and checked the change myself so
I've committed it as two trivial changes, rather than one complex change,
in r691981 and r691987.
-Mark.
Re: [classlib][build][freebsd] Fix Classlib build for FreeBSD 6.3
x86
Posted by Tim Ellison <t....@gmail.com>.
Mark Hindess wrote:
> In message <48...@gmail.com>, Tim Ellison writes:
>> Mark Hindess wrote:
>>> +#if defined(FREEBSD)
>>> +#define HY_VEC_T char
>>> +#else
>>> +#define HY_VEC_T unsigned char
>>> +#endif
>>> + HY_VEC_T* vec = NULL;
>> Am I misreading this? It used to be char* on non-FREEBSD systems, and
>> you needed to change it to be unsigned char* ?
>
> Not exactly. But your confusion is understandable. I should have explained
> this change. I'm fixing two things:
>
> a) vec was a char* but the only place it was used as char* was in the
> cast from the void* returned by hymem_allocate_memory. It was then
> forced to unsigned char*. Logically it made more sense to just
> change vec to unsigned char* and fix the cast.
>
> b) The type of the third parameter to mincore on freebsd needs to be char*.
>
> That should make more sense now?
Yes, thanks. I had not figured out the 'double step'.
> (Of course, if I'd committed it I would
> have explained that in the commit message.)
Of course ;-)
Regards,
Tim
Re: [classlib][build][freebsd] Fix Classlib build for FreeBSD 6.3 x86
Posted by Mark Hindess <ma...@googlemail.com>.
In message <48...@gmail.com>, Tim Ellison writes:
>
> Mark Hindess wrote:
> > After seeing your change adding the md5sum for freebsd I tried a build on
> > freebsd 7.0-RELEASE on x86_64.
>
> Apologies if I applied Ilya's patch too hastily, I didn't know you were
> also looking at it.
No problem. Sooner they are in svn the better ... fixing minor things later
is not a big deal.
> > I don't see the jlong/void* problems as they are both 64-bit on my machine.
> > However, it is common in classlib to fix this by doing a double cast althou
> gh
> > it is more common to use the classlib defines (IDATA) or (UDATA) than size_
> t.
>
> I can go back and change those again.
The individual files are self-consistent and they work so it probably
isn't a priority. Some code was using the macros jlong2addr and
addr2jlong from modules/portlib/src/main/native/include/shared/hycomp.h
and these are possibly an even better solution in the long term.
> > I also needed the following changes which I assume are freebsd6/7
> > differences. I'm sure the second is fine but can you check to see
> > if these cause problems on your 6.3 system?
> >
> > Index: modules/luni/src/main/native/luni/unix/OSMemoryLinux32.c
> > ===================================================================
> > --- modules/luni/src/main/native/luni/unix/OSMemoryLinux32.c (revision 691923)
> > +++ modules/luni/src/main/native/luni/unix/OSMemoryLinux32.c (working copy)
> > @@ -95,14 +95,20 @@
> > jboolean result = 0;
> > IDATA m_addr = (IDATA)addr;
> > int page_size = getPageSize();
> > - char* vec = NULL;
> > +#if defined(FREEBSD)
> > +#define HY_VEC_T char
> > +#else
> > +#define HY_VEC_T unsigned char
> > +#endif
> > + HY_VEC_T* vec = NULL;
>
> Am I misreading this? It used to be char* on non-FREEBSD systems, and
> you needed to change it to be unsigned char* ?
Not exactly. But your confusion is understandable. I should have explained
this change. I'm fixing two things:
a) vec was a char* but the only place it was used as char* was in the
cast from the void* returned by hymem_allocate_memory. It was then
forced to unsigned char*. Logically it made more sense to just
change vec to unsigned char* and fix the cast.
b) The type of the third parameter to mincore on freebsd needs to be char*.
That should make more sense now? (Of course, if I'd committed it I would
have explained that in the commit message.)
-Mark.
> > int page_count = 0;
> > int align_offset = m_addr%page_size;//addr should align with the
> boundary of a page.
> > m_addr -= align_offset;
> > size += align_offset;
> > page_count = (size+page_size-1)/page_size;
> > - vec = (char *) hymem_allocate_memory(page_count*sizeof(char));
> > - if(mincore((void *)m_addr, size , (unsigned char *)vec)==0) //or
> else there is error about the mincore and return false;
> > + vec = (HY_VEC_T *) hymem_allocate_memory(page_count*sizeof(char))
> ;
> > + if(mincore((void *)m_addr, size, vec)==0) //or else there is erro
> r about the mincore and return false;
> > +#undef HY_VEC_T
> > {
> > int i;
> > for(i=0 ;i<page_count;i++)
> > Index: modules/luni/src/main/native/luni/unix/freebsd/OSResourcesMonitor.c
> > ===================================================================
> > --- modules/luni/src/main/native/luni/unix/freebsd/OSResourcesMonitor.c (re
> vision 691923)
> > +++ modules/luni/src/main/native/luni/unix/freebsd/OSResourcesMonitor.c (wo
> rking copy)
> > @@ -37,7 +37,7 @@
> > {
> > unsigned long free;
> > unsigned long total;
> > - int len = sizeof(free);
> > + size_t len = sizeof(free);
> >
> > if (sysctlbyname("vm.stats.vm.v_free_count", &free, &len, NULL, 0) == -1
> ) {
> > return FALSE;
> >
> > Additionally, I needed to compile new versions of the icu dependencies for
> > freebsd7 that will conflict with the 6.3 versions. I think we can handle
> > the conflict by using the hy.platform defines used to handle the
> > libstdc++5/libstdc++6 conflict on linux.
> >
> > I have a few vm fixes too. I'll try to commit these later today.
> >
> > After building, when I try to run HelloWorld, I have significant problems
> > with pthread related code. Using libthr.so I get a hang early in the
> > startup. If I force the use of libkse.so with /etc/libmap.conf then I
> > get further but it hangs during shutdown. I'll post more details of these
> > when I get some spare time to look at them again.
> >
> > I assume you'll see similar problems.
> >
> > Regards,
> > Mark.
> >
> > In message <5c...@mail.gmail.com>,
> > "Ilya Berezhniuk" writes:
> >> Hi all,
> >>
> >> I prepared a patch to fix Harmony build on my FreeBSD 6.3 machine.
> >>
> >> Could anyone of classlib gurus review and approve Classlib part of
> >> this patch [1], as I'm not familiar with Classlib coding rules?
> >>
> >> Most of the problems were caused by casting jlong to void*, because
> >> sizes of these types are different, and -Werror was specified.
> >> In the patch I used double casting like (void*)(size_t)(jlong value).
> >>
> >> [1] https://issues.apache.org/jira/browse/HARMONY-5967
> >>
> >> --
> >> Ilya.
> >>
> >
> >
>
Re: [classlib][build][freebsd] Fix Classlib build for FreeBSD 6.3
x86
Posted by Tim Ellison <t....@gmail.com>.
Mark Hindess wrote:
> After seeing your change adding the md5sum for freebsd I tried a build on
> freebsd 7.0-RELEASE on x86_64.
Apologies if I applied Ilya's patch too hastily, I didn't know you were
also looking at it.
> I don't see the jlong/void* problems as they are both 64-bit on my machine.
> However, it is common in classlib to fix this by doing a double cast although
> it is more common to use the classlib defines (IDATA) or (UDATA) than size_t.
I can go back and change those again.
> I have an almost identical fix for the hysl.c issue but I made one additional
> change which I have committed as r691931 to keep the iconv and mbtowc code
> consistent.
>
> I fixed the hysock issue with r691184 and r691191 since I came across this
> on another platform a short while ago.
>
> I "fixed" the signal issues with the unrelated r691267.
Ack to all the above.
> I also needed the following changes which I assume are freebsd6/7 differences.
> I'm sure the second is fine but can you check to see if these cause problems
> on your 6.3 system?
>
> Index: modules/luni/src/main/native/luni/unix/OSMemoryLinux32.c
> ===================================================================
> --- modules/luni/src/main/native/luni/unix/OSMemoryLinux32.c (revision 691923)
> +++ modules/luni/src/main/native/luni/unix/OSMemoryLinux32.c (working copy)
> @@ -95,14 +95,20 @@
> jboolean result = 0;
> IDATA m_addr = (IDATA)addr;
> int page_size = getPageSize();
> - char* vec = NULL;
> +#if defined(FREEBSD)
> +#define HY_VEC_T char
> +#else
> +#define HY_VEC_T unsigned char
> +#endif
> + HY_VEC_T* vec = NULL;
Am I misreading this? It used to be char* on non-FREEBSD systems, and
you needed to change it to be unsigned char* ?
Regards,
Tim
> int page_count = 0;
> int align_offset = m_addr%page_size;//addr should align with the boundary of a page.
> m_addr -= align_offset;
> size += align_offset;
> page_count = (size+page_size-1)/page_size;
> - vec = (char *) hymem_allocate_memory(page_count*sizeof(char));
> - if(mincore((void *)m_addr, size , (unsigned char *)vec)==0) //or else there is error about the mincore and return false;
> + vec = (HY_VEC_T *) hymem_allocate_memory(page_count*sizeof(char));
> + if(mincore((void *)m_addr, size, vec)==0) //or else there is error about the mincore and return false;
> +#undef HY_VEC_T
> {
> int i;
> for(i=0 ;i<page_count;i++)
> Index: modules/luni/src/main/native/luni/unix/freebsd/OSResourcesMonitor.c
> ===================================================================
> --- modules/luni/src/main/native/luni/unix/freebsd/OSResourcesMonitor.c (revision 691923)
> +++ modules/luni/src/main/native/luni/unix/freebsd/OSResourcesMonitor.c (working copy)
> @@ -37,7 +37,7 @@
> {
> unsigned long free;
> unsigned long total;
> - int len = sizeof(free);
> + size_t len = sizeof(free);
>
> if (sysctlbyname("vm.stats.vm.v_free_count", &free, &len, NULL, 0) == -1) {
> return FALSE;
>
> Additionally, I needed to compile new versions of the icu dependencies for
> freebsd7 that will conflict with the 6.3 versions. I think we can handle
> the conflict by using the hy.platform defines used to handle the
> libstdc++5/libstdc++6 conflict on linux.
>
> I have a few vm fixes too. I'll try to commit these later today.
>
> After building, when I try to run HelloWorld, I have significant problems
> with pthread related code. Using libthr.so I get a hang early in the
> startup. If I force the use of libkse.so with /etc/libmap.conf then I
> get further but it hangs during shutdown. I'll post more details of these
> when I get some spare time to look at them again.
>
> I assume you'll see similar problems.
>
> Regards,
> Mark.
>
> In message <5c...@mail.gmail.com>,
> "Ilya Berezhniuk" writes:
>> Hi all,
>>
>> I prepared a patch to fix Harmony build on my FreeBSD 6.3 machine.
>>
>> Could anyone of classlib gurus review and approve Classlib part of
>> this patch [1], as I'm not familiar with Classlib coding rules?
>>
>> Most of the problems were caused by casting jlong to void*, because
>> sizes of these types are different, and -Werror was specified.
>> In the patch I used double casting like (void*)(size_t)(jlong value).
>>
>> [1] https://issues.apache.org/jira/browse/HARMONY-5967
>>
>> --
>> Ilya.
>>
>
>