[doc] Add John Marino to doc/contrib.texi (was: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly)
On Wed, 21 May 2014, Jonathan Wakely wrote: Bootstrapped on x86_64-unknown-dragonfly3.6 and x86_64-unknown-linux-gnu, committed to trunk as http://gcc.gnu.org/r210694 John, thanks for contributing the target support and for persevering with the review process :-) And here is the corresponding entry to doc/contrib.texi. Committed. Better late than never, I guess, and still in time for 5.0. :-) Gerald 2015-04-09 Gerald Pfeifer ger...@pfeifer.com * doc/contrib.texi (Contributors): Add John Marino. Index: doc/contrib.texi === --- doc/contrib.texi(revision 221959) +++ doc/contrib.texi(working copy) @@ -590,6 +590,9 @@ Bob Manson for his behind the scenes work on dejagnu. @item +John Marino for contributing the DragonFly BSD port. + +@item Philip Martin for lots of libstdc++ string and vector iterator fixes and improvements, and string clean up and testsuites.
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 12 May 2014 18:14, Jeff Law wrote: On 05/12/14 11:10, John Marino wrote: On 5/12/2014 18:59, Jeff Law wrote: On 05/09/14 01:14, John Marino wrote: 1) Patch updated online as requested 2) At this exact point in time, we probably can share the files 3) I might debate that we should share the files - that would imply reviewing the existing counterpart files for NetBSD and OpenBSD and combining when equivalent. Let's go ahead and keep the files separate. We can always go back and combine them at a later date if we see the need. So with that in mind, the patch is good to go with the gnat thread stuff removed. Do you have write access, or do you you need someone to commit the change for you? Thanks, Jeff! I do not have write access, but jwakely has graciously offered to commit this patchset when it achieves approval, so I guess he's on deck! OK. It's Jon's :-) Great, I'll coordinate with John and aim to get it committed before Friday.
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 05/09/14 01:14, John Marino wrote: On 5/9/2014 07:26, Jeff Law wrote: On 05/03/14 01:11, John Marino wrote: In config.gcc: +no | gnat | single) + # Let these non-posix thread selections fall through if requested Support for gnat as a thread model was removed in 2011. So I think you need to remove that case. I realized that the gnat thread mechanism had been removed a couple of days ago, but I didn't want to invalidate the ongoing review since it was a not really an issue. I'll make the change now. This hunk was obviously created when it did exist. No problem. configure.ac: + *-*-dragonfly* | *-*-freebsd*) +if grep dl_iterate_phdr $target_header_dir/sys/link_elf.h /dev/null 21; then + gcc_cv_target_dl_iterate_phdr=yes +else + gcc_cv_target_dl_iterate_phdr=no +fi +;; Presumably you intended to change freebsd* here. Just want a confirmation. I haven't worked on the *bsd platforms in about 20 years, so I have no idea if this is right for them in general. Yes, this is intentional. This is why I also did a full testsuite on FreeBSD as well as DragonFly to prove that still worked. OK. Just wanted to be sure. As I mentioned, it's been a *long* time since I did anything with the *bsd ports. NetBSD and OpenBSD would be handled similarly when the time comes, but they would need to grep a different header. I see you have a dragonfly-stdint.h. Is there a particular reason why you can't use the freebsd-stdint.h? I didn't check every type, but a quick glance makes me think they ought to be equivalent. Similarly for dragonfly.opt. And there is already precedent for each system to have its own files: freebsd.opt freebsd-stdint.h openbsd.opt openbsd-stdint.h netbsd.opt ( The dragonfly-stdint.h is cleaner than freebsd-stdint.h as well. Yea, there's always a bit of a natural tension between having this kind of stuff duplicated vs sharing when their contents are common. I lean towards the latter in this case for a variety of reasons. While similar due to heritage, and also due to a conscious effort to keep the userland compatible where a difference isn't specifically needed, DragonFly is not FreeBSD. We've had a challenge with software that consider them to be equivalent in every aspect. I certainly understand having done similar stuff in the past. Sometimes changes are made against a FreeBSD file that is not valid for DragonFly, so even if they are equivalent today they may not be in the future. We prefer separate configuration files like NetBSD and OpenBSD have in general. Right and this is the most important counter-argument to sharing. They're compatible today, but will they be tomorrow? It sounds like Dragonfly has a bit of a mandate to be different than FreeBSD, so there's probably more than the usual chance this stuff could diverge in the future. by the way config/dragonfly.h and config/i386/dragonfly.h are significantly different that FreeBSD counterparts. And we eliminated the equivalent of config/i386/freebsd64.h by combining it's functionality into config/i386/dragonfly.h. There are also platform-specific differences there so there is no question that DragonFly needs its own header files. I saw that when scanning dragfonfly.h and freebsd.h to see how much commonality there was between them. I'm going to trust the unwind code works and isn't duplicating something from somewhere else that ought to instead be shared. Not only is it not duplicated, FreeBSD needs its own, different version (FreeBSD is currently missing unwind functionality). I have the patch and that's a separate submission (out of scope for DragonFly target creation). Believe me, if there is one thing you would not want to duplicate, it's MD support code. FYI NetBSD and OpenBSD are missing this functionality too. So it basically looks good. Can you fix the config.gcc nit and determine if we can (and should) share files with freebsd. Repost after those fixes and we should be ready to go. 1) Patch updated online as requested 2) At this exact point in time, we probably can share the files 3) I might debate that we should share the files - that would imply reviewing the existing counterpart files for NetBSD and OpenBSD and combining when equivalent. Let's go ahead and keep the files separate. We can always go back and combine them at a later date if we see the need. So with that in mind, the patch is good to go with the gnat thread stuff removed. Do you have write access, or do you you need someone to commit the change for you? Jeff
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 5/12/2014 18:59, Jeff Law wrote: On 05/09/14 01:14, John Marino wrote: 1) Patch updated online as requested 2) At this exact point in time, we probably can share the files 3) I might debate that we should share the files - that would imply reviewing the existing counterpart files for NetBSD and OpenBSD and combining when equivalent. Let's go ahead and keep the files separate. We can always go back and combine them at a later date if we see the need. So with that in mind, the patch is good to go with the gnat thread stuff removed. Do you have write access, or do you you need someone to commit the change for you? Thanks, Jeff! I do not have write access, but jwakely has graciously offered to commit this patchset when it achieves approval, so I guess he's on deck! John
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 05/12/14 11:10, John Marino wrote: On 5/12/2014 18:59, Jeff Law wrote: On 05/09/14 01:14, John Marino wrote: 1) Patch updated online as requested 2) At this exact point in time, we probably can share the files 3) I might debate that we should share the files - that would imply reviewing the existing counterpart files for NetBSD and OpenBSD and combining when equivalent. Let's go ahead and keep the files separate. We can always go back and combine them at a later date if we see the need. So with that in mind, the patch is good to go with the gnat thread stuff removed. Do you have write access, or do you you need someone to commit the change for you? Thanks, Jeff! I do not have write access, but jwakely has graciously offered to commit this patchset when it achieves approval, so I guess he's on deck! OK. It's Jon's :-) Jeff
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 5/9/2014 07:26, Jeff Law wrote: On 05/03/14 01:11, John Marino wrote: In config.gcc: +no | gnat | single) + # Let these non-posix thread selections fall through if requested Support for gnat as a thread model was removed in 2011. So I think you need to remove that case. I realized that the gnat thread mechanism had been removed a couple of days ago, but I didn't want to invalidate the ongoing review since it was a not really an issue. I'll make the change now. This hunk was obviously created when it did exist. configure.ac: + *-*-dragonfly* | *-*-freebsd*) +if grep dl_iterate_phdr $target_header_dir/sys/link_elf.h /dev/null 21; then + gcc_cv_target_dl_iterate_phdr=yes +else + gcc_cv_target_dl_iterate_phdr=no +fi +;; Presumably you intended to change freebsd* here. Just want a confirmation. I haven't worked on the *bsd platforms in about 20 years, so I have no idea if this is right for them in general. Yes, this is intentional. This is why I also did a full testsuite on FreeBSD as well as DragonFly to prove that still worked. NetBSD and OpenBSD would be handled similarly when the time comes, but they would need to grep a different header. I see you have a dragonfly-stdint.h. Is there a particular reason why you can't use the freebsd-stdint.h? I didn't check every type, but a quick glance makes me think they ought to be equivalent. Similarly for dragonfly.opt. And there is already precedent for each system to have its own files: freebsd.opt freebsd-stdint.h openbsd.opt openbsd-stdint.h netbsd.opt ( The dragonfly-stdint.h is cleaner than freebsd-stdint.h as well. It looks like there's a fair amount of duplication in config/dragonfly.h and config/i386/dragonfly but I don't see an easy way to fix that. So, I'll let that go. While similar due to heritage, and also due to a conscious effort to keep the userland compatible where a difference isn't specifically needed, DragonFly is not FreeBSD. We've had a challenge with software that consider them to be equivalent in every aspect. Sometimes changes are made against a FreeBSD file that is not valid for DragonFly, so even if they are equivalent today they may not be in the future. We prefer separate configuration files like NetBSD and OpenBSD have in general. by the way config/dragonfly.h and config/i386/dragonfly.h are significantly different that FreeBSD counterparts. And we eliminated the equivalent of config/i386/freebsd64.h by combining it's functionality into config/i386/dragonfly.h. There are also platform-specific differences there so there is no question that DragonFly needs its own header files. I'm going to trust the unwind code works and isn't duplicating something from somewhere else that ought to instead be shared. Not only is it not duplicated, FreeBSD needs its own, different version (FreeBSD is currently missing unwind functionality). I have the patch and that's a separate submission (out of scope for DragonFly target creation). Believe me, if there is one thing you would not want to duplicate, it's MD support code. FYI NetBSD and OpenBSD are missing this functionality too. So it basically looks good. Can you fix the config.gcc nit and determine if we can (and should) share files with freebsd. Repost after those fixes and we should be ready to go. 1) Patch updated online as requested 2) At this exact point in time, we probably can share the files 3) I might debate that we should share the files - that would imply reviewing the existing counterpart files for NetBSD and OpenBSD and combining when equivalent. And one final thing, do you have a copyright assignment on file with the FSF? Yes, since 2011. I mentioned that in the very first post of the thread along with the associated assignment number. jeff Thank you very much for the overarching review Jeff! John
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 3 May 2014 08:11, John Marino wrote: On 5/2/2014 22:15, Joseph S. Myers wrote: On Fri, 2 May 2014, John Marino wrote: 1) I don't know which type definitions are missing (iow, the important ones from sys/type.h that are required to build gcc) The default presumption should be: * stddef.h from GCC provides what it needs to provide; nothing extra is needed and such a #include should not be needed at all. * Special measures to avoid duplicate typedefs (where some other header also defines one of the typedefs defined in stddef.h) aren't in fact needed, because GCC allows duplicate typedefs in system headers (even outside C11 mode - in C11 mode it's a standard feature). So try removing that #include. If that causes problems, investigate based on the actual problems seen. Hi Joseph, Removing the include worked after also removing the #ifdef __DragonFly with regards to the rune_t type definition. I built gcc with a full bootstraps on both DragonFly platforms successfully. stddef.h is much simpler now: --- gcc/ginclude/stddef.h.orig +++ gcc/ginclude/stddef.h @@ -133,6 +133,7 @@ #ifndef _BSD_PTRDIFF_T_ #ifndef ___int_ptrdiff_t_h #ifndef _GCC_PTRDIFF_T +#ifndef _PTRDIFF_T_DECLARED /* DragonFly */ #define _PTRDIFF_T #define _T_PTRDIFF_ #define _T_PTRDIFF @@ -141,10 +142,12 @@ #define _BSD_PTRDIFF_T_ #define ___int_ptrdiff_t_h #define _GCC_PTRDIFF_T +#define _PTRDIFF_T_DECLARED #ifndef __PTRDIFF_TYPE__ #define __PTRDIFF_TYPE__ long int #endif typedef __PTRDIFF_TYPE__ ptrdiff_t; +#endif /* _PTRDIFF_T_DECLARED */ #endif /* _GCC_PTRDIFF_T */ #endif /* ___int_ptrdiff_t_h */ #endif /* _BSD_PTRDIFF_T_ */ @@ -198,6 +201,7 @@ #define _GCC_SIZE_T #define _SIZET_ #if (defined (__FreeBSD__) (__FreeBSD__ = 5)) \ + || defined(__DragonFly__) \ || defined(__FreeBSD_kernel__) /* __size_t is a typedef on FreeBSD 5, must not trash it. */ #elif defined (__VMS__) revised patchset : http://leaf.dragonflybsd.org/~marino/gcc-df-target/patches/patch-dragonfly-target revised changelog : http://leaf.dragonflybsd.org/~marino/gcc-df-target/changelog_entries/gcc_ChangeLog_entry.txt revised commit msg: http://leaf.dragonflybsd.org/~marino/gcc-df-target/proposed_commit-msg.txt Good catch! Does the rest of the patch set look good to you? I think all the non-obvious patches have been reviewed collectively by various people now and may be ready to be approved now. Ian's approved the libiberty.h change, Joseph's approved the stddef.h change, I've approved the libstdc++ parts. IIUC it still needs explicit approval for the rest, e.g. trivial adjustments to configuration stuff in libitm and libcilkrts. Are there specific maintainers for those libs? The rest look obvious to me, it doesn't touch other targets at all except for one bit that replaces a check for __FreeBSD__ = 7 with a grep for the dl_iterate_phdr function in a system header, which only affects FreeBSD and looks OK to me. Anyone willing to give it an overall approval?
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 05/08/14 07:14, Jonathan Wakely wrote: Ian's approved the libiberty.h change, Joseph's approved the stddef.h change, I've approved the libstdc++ parts. IIUC it still needs explicit approval for the rest, e.g. trivial adjustments to configuration stuff in libitm and libcilkrts. Are there specific maintainers for those libs? The rest look obvious to me, it doesn't touch other targets at all except for one bit that replaces a check for __FreeBSD__ = 7 with a grep for the dl_iterate_phdr function in a system header, which only affects FreeBSD and looks OK to me. Anyone willing to give it an overall approval? I'll take a look at the rest. I mostly wanted someone else to deal with stddef.h :-) jeff
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 5/8/2014 15:32, Jeff Law wrote: On 05/08/14 07:14, Jonathan Wakely wrote: Anyone willing to give it an overall approval? I'll take a look at the rest. I mostly wanted someone else to deal with stddef.h :-) Thanks Jeff! I'm am very appreciative of that. John
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 05/03/14 01:11, John Marino wrote: revised patchset : http://leaf.dragonflybsd.org/~marino/gcc-df-target/patches/patch-dragonfly-target revised changelog : http://leaf.dragonflybsd.org/~marino/gcc-df-target/changelog_entries/gcc_ChangeLog_entry.txt revised commit msg: http://leaf.dragonflybsd.org/~marino/gcc-df-target/proposed_commit-msg.txt Good catch! Does the rest of the patch set look good to you? I think all the non-obvious patches have been reviewed collectively by various people now and may be ready to be approved now. In config.gcc: +no | gnat | single) + # Let these non-posix thread selections fall through if requested Support for gnat as a thread model was removed in 2011. So I think you need to remove that case. configure.ac: + *-*-dragonfly* | *-*-freebsd*) +if grep dl_iterate_phdr $target_header_dir/sys/link_elf.h /dev/null 21; then + gcc_cv_target_dl_iterate_phdr=yes +else + gcc_cv_target_dl_iterate_phdr=no +fi +;; Presumably you intended to change freebsd* here. Just want a confirmation. I haven't worked on the *bsd platforms in about 20 years, so I have no idea if this is right for them in general. I see you have a dragonfly-stdint.h. Is there a particular reason why you can't use the freebsd-stdint.h? I didn't check every type, but a quick glance makes me think they ought to be equivalent. Similarly for dragonfly.opt. It looks like there's a fair amount of duplication in config/dragonfly.h and config/i386/dragonfly but I don't see an easy way to fix that. So, I'll let that go. I'm going to trust the unwind code works and isn't duplicating something from somewhere else that ought to instead be shared. So it basically looks good. Can you fix the config.gcc nit and determine if we can (and should) share files with freebsd. Repost after those fixes and we should be ready to go. And one final thing, do you have a copyright assignment on file with the FSF? jeff
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 5/2/2014 22:15, Joseph S. Myers wrote: On Fri, 2 May 2014, John Marino wrote: 1) I don't know which type definitions are missing (iow, the important ones from sys/type.h that are required to build gcc) The default presumption should be: * stddef.h from GCC provides what it needs to provide; nothing extra is needed and such a #include should not be needed at all. * Special measures to avoid duplicate typedefs (where some other header also defines one of the typedefs defined in stddef.h) aren't in fact needed, because GCC allows duplicate typedefs in system headers (even outside C11 mode - in C11 mode it's a standard feature). So try removing that #include. If that causes problems, investigate based on the actual problems seen. Hi Joseph, Removing the include worked after also removing the #ifdef __DragonFly with regards to the rune_t type definition. I built gcc with a full bootstraps on both DragonFly platforms successfully. stddef.h is much simpler now: --- gcc/ginclude/stddef.h.orig +++ gcc/ginclude/stddef.h @@ -133,6 +133,7 @@ #ifndef _BSD_PTRDIFF_T_ #ifndef ___int_ptrdiff_t_h #ifndef _GCC_PTRDIFF_T +#ifndef _PTRDIFF_T_DECLARED /* DragonFly */ #define _PTRDIFF_T #define _T_PTRDIFF_ #define _T_PTRDIFF @@ -141,10 +142,12 @@ #define _BSD_PTRDIFF_T_ #define ___int_ptrdiff_t_h #define _GCC_PTRDIFF_T +#define _PTRDIFF_T_DECLARED #ifndef __PTRDIFF_TYPE__ #define __PTRDIFF_TYPE__ long int #endif typedef __PTRDIFF_TYPE__ ptrdiff_t; +#endif /* _PTRDIFF_T_DECLARED */ #endif /* _GCC_PTRDIFF_T */ #endif /* ___int_ptrdiff_t_h */ #endif /* _BSD_PTRDIFF_T_ */ @@ -198,6 +201,7 @@ #define _GCC_SIZE_T #define _SIZET_ #if (defined (__FreeBSD__) (__FreeBSD__ = 5)) \ + || defined(__DragonFly__) \ || defined(__FreeBSD_kernel__) /* __size_t is a typedef on FreeBSD 5, must not trash it. */ #elif defined (__VMS__) revised patchset : http://leaf.dragonflybsd.org/~marino/gcc-df-target/patches/patch-dragonfly-target revised changelog : http://leaf.dragonflybsd.org/~marino/gcc-df-target/changelog_entries/gcc_ChangeLog_entry.txt revised commit msg: http://leaf.dragonflybsd.org/~marino/gcc-df-target/proposed_commit-msg.txt Good catch! Does the rest of the patch set look good to you? I think all the non-obvious patches have been reviewed collectively by various people now and may be ready to be approved now. Thanks, John
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On Fri, 2 May 2014, John Marino wrote: So given the track record (building itself, building base, building 21,000 software ports) over a couple of years I think any issues this could have caused would have been seen and identified by now. These issues aren't generally obvious (given that the ISO C conformance modes aren't used that often, and when they are that doesn't mean the application is using POSIX types for something else). (I don't know what the FreeBSD sys/_types.h defines, but it at least seems possible from the name that it is only defining things in the implementation namespace, with the public sys/types.h being what then includes sys/_types.h and does typedef __foo_t foo_t; or similar to provide the public POSIX types that aren't in ISO C.) Here are the headers in question: http://grok.dragonflybsd.org/xref/freebsd/sys/sys/_types.h That seems OK for stddef.h inclusion, as long as the machine/_types.h is OK. http://grok.dragonflybsd.org/xref/dragonfly/sys/sys/types.h That's definitely not correct to include in stddef.h; it defines lots of types outside the ISO C namespace. -- Joseph S. Myers jos...@codesourcery.com
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 5/2/2014 19:49, Joseph S. Myers wrote: On Fri, 2 May 2014, John Marino wrote: http://grok.dragonflybsd.org/xref/dragonfly/sys/sys/types.h That's definitely not correct to include in stddef.h; it defines lots of types outside the ISO C namespace. Ok. So I guess there are two problems. 1) I don't know which type definitions are missing (iow, the important ones from sys/type.h that are required to build gcc) 2) Mainly because of 1) I don't know what to pull in instead. DragonFly doesn't have this _type.h split like FreeBSD Do you have a suggestion for me on how to proceed? Thanks, John
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On Fri, 2 May 2014, John Marino wrote: 1) I don't know which type definitions are missing (iow, the important ones from sys/type.h that are required to build gcc) The default presumption should be: * stddef.h from GCC provides what it needs to provide; nothing extra is needed and such a #include should not be needed at all. * Special measures to avoid duplicate typedefs (where some other header also defines one of the typedefs defined in stddef.h) aren't in fact needed, because GCC allows duplicate typedefs in system headers (even outside C11 mode - in C11 mode it's a standard feature). So try removing that #include. If that causes problems, investigate based on the actual problems seen. -- Joseph S. Myers jos...@codesourcery.com
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 5/2/2014 22:15, Joseph S. Myers wrote: On Fri, 2 May 2014, John Marino wrote: 1) I don't know which type definitions are missing (iow, the important ones from sys/type.h that are required to build gcc) The default presumption should be: * stddef.h from GCC provides what it needs to provide; nothing extra is needed and such a #include should not be needed at all. * Special measures to avoid duplicate typedefs (where some other header also defines one of the typedefs defined in stddef.h) aren't in fact needed, because GCC allows duplicate typedefs in system headers (even outside C11 mode - in C11 mode it's a standard feature). So try removing that #include. If that causes problems, investigate based on the actual problems seen. Okay, will do. Thanks!
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
The include of sys/types.h from stddef.h seems risky, given that that's a POSIX header that typically defines various types ISO C does not permit to be defined in stddef.h (ISO C does not have any general *_t namespace reservation, unlike POSIX). Have you verified that if you include stddef.h with -std=c90 / -std=c99 / -std=c11, the resulting definitions (compiler and preprocessor) are all ones permitted by the relevant C standard version to be provided by stddef.h? (I don't know what the FreeBSD sys/_types.h defines, but it at least seems possible from the name that it is only defining things in the implementation namespace, with the public sys/types.h being what then includes sys/_types.h and does typedef __foo_t foo_t; or similar to provide the public POSIX types that aren't in ISO C.) -- Joseph S. Myers jos...@codesourcery.com
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 5/2/2014 01:03, Joseph S. Myers wrote: The include of sys/types.h from stddef.h seems risky, given that that's a POSIX header that typically defines various types ISO C does not permit to be defined in stddef.h (ISO C does not have any general *_t namespace reservation, unlike POSIX). Have you verified that if you include stddef.h with -std=c90 / -std=c99 / -std=c11, the resulting definitions (compiler and preprocessor) are all ones permitted by the relevant C standard version to be provided by stddef.h? You bring up some interesting points. I haven't specific tested anything like that, but DragonFly has been using this modification for years - since gcc 4.6 at least. It is even in the primary base compiler: http://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEAD:/contrib/gcc-4.7/gcc/ginclude/stddef.h So given the track record (building itself, building base, building 21,000 software ports) over a couple of years I think any issues this could have caused would have been seen and identified by now. (I don't know what the FreeBSD sys/_types.h defines, but it at least seems possible from the name that it is only defining things in the implementation namespace, with the public sys/types.h being what then includes sys/_types.h and does typedef __foo_t foo_t; or similar to provide the public POSIX types that aren't in ISO C.) Here are the headers in question: http://grok.dragonflybsd.org/xref/freebsd/sys/sys/_types.h http://grok.dragonflybsd.org/xref/dragonfly/sys/sys/types.h Thanks, John
[PING] Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
Hi folks, Does anyone have any issues with this set of patches to add support for the DragonFly targets? It's a blocker for other patches of mine that have a more general benefit, but this (relatively simple) one has to go in first. Thanks, John On 4/20/2014 21:04, John Marino wrote: On 4/20/2014 14:51, Jonathan Wakely wrote: On 19 April 2014 20:39, John Marino wrote: Hello GCC developers, For the last few years, I have been maintaining a large set of patches that add support for the DragonFly BSD target and also complete Ada frontend support on all four major BSDs among other things. Before I can submit patches for Ada or testsuite cases, DragonFly must be a recognized, working target. The patches attached here will provide out-of-the-box support for the C, C++, Objective-C and Fortran frontends. Thanks for the patch - I only have a few general, minor comments. As noted at http://gcc.gnu.org/lists.html C++ library patches should go to the libstdc++ list as well as gcc-patches, so I've CC'd that list (original mail and patch are at http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01128.html) Patches should not include generated files such as configure, as the diffs don't always apply cleanly and the changes are implied by the patches to files such as acinclude.m4 and configure.ac. The regenerated versions should of course be committed, and the ChangeLog should mention they are regenerated, as you've done. Thanks for your advice, Jonathan. I've updated the patch to remove the two configure file patches. I also removed an errant -rpath from the dragonfly.h specs that crept in from FreeBSD ports. I've attached the updated patch to this email. The changelog text should be correctly capitalised and sentences ended with a period (e.g. New target. and New. not New target and new). The individual ChangeLog entries at http://leaf.dragonflybsd.org/~marino/gcc-df-target/changelog_entries/ would generally be used as the commit message, grouped and prefixed by the name of the sub-directory: I have updated the six entry files at http://leaf.dragonflybsd.org/~marino/gcc-df-target/changelog_entries/ to conform to this style. I updated the proposed commit message accordingly: http://leaf.dragonflybsd.org/~marino/gcc-df-target/proposed_commit-msg.txt The libstdc++ changes are OK for trunk if the rest gets approved. Thanks! I see from the critique of another submitted patch that also touches liberty that I'm supposed to cross-post to gdb and binutils, so I've cc'd them as well. Regards, John
Re: [PING] Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On Tue, Apr 29, 2014 at 11:37 AM, John Marino gnu...@marino.st wrote: Does anyone have any issues with this set of patches to add support for the DragonFly targets? It's a blocker for other patches of mine that have a more general benefit, but this (relatively simple) one has to go in first. It's inconvenient, but patches are much more likely to be reviewed when they cover a separate part of the tree, as different people maintain different parts. I expect your libitm and libcilkrts could be approved trivially if you send them separately. The change to include/libiberty.h is fine. I don't understand the benefit of libgcc/enable-execute-stack-bsd.c. The code seems the same as the existing libgcc/enable-execute-stack-mprotect.c. All you are changing is omitting need_enable_exec_stack. If you just drop the FreeBSD constructor, you will get the behaviour you want. Ian
Re: [PING] Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 4/29/2014 19:23, Ian Lance Taylor wrote: On Tue, Apr 29, 2014 at 11:37 AM, John Marino gnu...@marino.st wrote: Does anyone have any issues with this set of patches to add support for the DragonFly targets? It's a blocker for other patches of mine that have a more general benefit, but this (relatively simple) one has to go in first. It's inconvenient, but patches are much more likely to be reviewed when they cover a separate part of the tree, as different people maintain different parts. I expect your libitm and libcilkrts could be approved trivially if you send them separately. Hi Ian, I was trying to identify specific people (e.g. an libitm person) and have them approve specific files since they are trivial as you saw. I decided to keep the patch set as an atomic unit because it needs to be committed as a unit, and also because I assumed it provided the necessary context. The change to include/libiberty.h is fine. thanks! I don't understand the benefit of libgcc/enable-execute-stack-bsd.c. The code seems the same as the existing libgcc/enable-execute-stack-mprotect.c. All you are changing is omitting need_enable_exec_stack. If you just drop the FreeBSD constructor, you will get the behaviour you want. With the caveat that this patch is over 2 years old, I just took a look at both files. I would have not needed to modify this file at all for DragonFly. In fact, I seem to recall that I didn't modify it for DragonFly, but rather for FreeBSD. If I had to guess, it would be that I found mprotect() was needed regardless of value of kern.stackprot. I must have traced some test failures back to this. Which I guess that's what you mean - just delete the block between #if defined __FreeBSD__ and the next #elif which should be equivalent. I can tweak the patch set to do that. And what about the dl_iterate_phdr changes? Do they look good to you? Thanks, John
Re: [PING] Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On Tue, Apr 29, 2014 at 2:37 PM, John Marino gnu...@marino.st wrote: I don't understand the benefit of libgcc/enable-execute-stack-bsd.c. The code seems the same as the existing libgcc/enable-execute-stack-mprotect.c. All you are changing is omitting need_enable_exec_stack. If you just drop the FreeBSD constructor, you will get the behaviour you want. With the caveat that this patch is over 2 years old, I just took a look at both files. I would have not needed to modify this file at all for DragonFly. In fact, I seem to recall that I didn't modify it for DragonFly, but rather for FreeBSD. If I had to guess, it would be that I found mprotect() was needed regardless of value of kern.stackprot. I must have traced some test failures back to this. Which I guess that's what you mean - just delete the block between #if defined __FreeBSD__ and the next #elif which should be equivalent. I can tweak the patch set to do that. Yes. And what about the dl_iterate_phdr changes? Do they look good to you? They looked fine to me but I'm not a build system maintainer. Ian
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 19 April 2014 20:39, John Marino wrote: Hello GCC developers, For the last few years, I have been maintaining a large set of patches that add support for the DragonFly BSD target and also complete Ada frontend support on all four major BSDs among other things. Before I can submit patches for Ada or testsuite cases, DragonFly must be a recognized, working target. The patches attached here will provide out-of-the-box support for the C, C++, Objective-C and Fortran frontends. Thanks for the patch - I only have a few general, minor comments. As noted at http://gcc.gnu.org/lists.html C++ library patches should go to the libstdc++ list as well as gcc-patches, so I've CC'd that list (original mail and patch are at http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01128.html) Patches should not include generated files such as configure, as the diffs don't always apply cleanly and the changes are implied by the patches to files such as acinclude.m4 and configure.ac. The regenerated versions should of course be committed, and the ChangeLog should mention they are regenerated, as you've done. The changelog text should be correctly capitalised and sentences ended with a period (e.g. New target. and New. not New target and new). The individual ChangeLog entries at http://leaf.dragonflybsd.org/~marino/gcc-df-target/changelog_entries/ would generally be used as the commit message, grouped and prefixed by the name of the sub-directory: gcc/ * config.gcc (*-*-dragonfly*): New target etc. etc. libcilkrts/ * runtime/os-unix.c (__DragonFly__): New target etc. etc. libgcc/ * libgcc/config.host (*-*-dragonfly*): New target etc. etc. The libstdc++ changes are OK for trunk if the rest gets approved.
