[patch] enable the building on libatomic on DragonFly
With the attached patch, libatomic will build and pass 100% of the tests
on DragonFly.
suggested entry for libatomic/ChangeLog:
2015-07-XX John Marino
* configure.tgt: Add *-*-dragonfly to supported targets.
Please consider this patch for trunk.
Thanks,
John
--- libatomic/configure.tgt.orig2015-07-09 16:08:55 UTC
+++ libatomic/configure.tgt
@@ -110,7 +110,7 @@ case "${target}" in
;;
*-*-linux* | *-*-gnu* | *-*-k*bsd*-gnu \
- | *-*-netbsd* | *-*-freebsd* | *-*-openbsd* \
+ | *-*-netbsd* | *-*-freebsd* | *-*-openbsd* | *-*-dragonfly* \
| *-*-solaris2* | *-*-sysv4* | *-*-irix6* | *-*-osf* | *-*-hpux11* \
| *-*-darwin* | *-*-aix* | *-*-cygwin*)
# POSIX system. The OS is supported.
[patch] fixes -fcilkplus functionality on DragonFly (fixes ~2600 tests)
After posting the first testsuite results for DragonFly, it was clear that the -fcilkplus functionality was broken: https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg01046.html The problem was related to the __cpu_model symbol not getting exported. The solution was to create libgcc/config/i386/t-dragonfly to define an additional symbol map (similar to t-freebsd). Simply creating the file is enough because there's already a placeholder for t-dragonfly at libgcc/config.host. The patch is attached. The improved results of the patch can be seen on the next posted testsuite results: https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg01081.html An additional ~2600 tests now pass. Please consider this patch for incorporation into trunk. Only DragonFly uses the new t-dragonfly file so there is no impact to other platforms. suggested entry for libgcc/ChangeLog: 2015-07-XX John Marino * config/i386/t-dragonfly: New. Thanks, John --- /dev/null 2015-07-10 21:56:18 UTC +++ libgcc/config/i386/t-dragonfly @@ -0,0 +1,2 @@ +# Required for -fcilkplus support +SHLIB_MAPFILES += $(srcdir)/config/i386/libgcc-bsd.ver
Re: [patch] fixes -fcilkplus functionality on DragonFly (fixes ~2600 tests)
On 7/11/2015 1:45 PM, Jonathan Wakely wrote: > On 11 July 2015 at 06:46, Jeff Law wrote: >> On 07/10/2015 06:34 PM, John Marino wrote: >>> >>> After posting the first testsuite results for DragonFly, it was clear >>> that the -fcilkplus functionality was broken: >>> https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg01046.html >>> >>> The problem was related to the __cpu_model symbol not getting exported. >>> >>> The solution was to create libgcc/config/i386/t-dragonfly to define an >>> additional symbol map (similar to t-freebsd). Simply creating the file >>> is enough because there's already a placeholder for t-dragonfly at >>> libgcc/config.host. The patch is attached. >>> >>> The improved results of the patch can be seen on the next posted >>> testsuite results: >>> https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg01081.html >>> >>> An additional ~2600 tests now pass. >>> Please consider this patch for incorporation into trunk. Only DragonFly >>> uses the new t-dragonfly file so there is no impact to other platforms. >>> >>> suggested entry for libgcc/ChangeLog: >>> >>> 2015-07-XX John Marino >>> >>> * config/i386/t-dragonfly: New. >> >> OK. >> jeff >> > > John, If you like I can commit this for you on Monday when I commit > your patch to os_defines.h. > That is very kind, Jonathan! thanks, Monday would be great. John P.S. I have a 3rd simple one that you can commit on Monday as well if it gets approved (no reason it shouldn't): https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00897.html
Re: [libstdc++ testsuite][patch] many locale tests only SUPPORTED on linux, start making these portable
On 11/11/2015 10:51 PM, Jonathan Wakely wrote: > On 16/10/15 11:21 +0200, John Marino wrote: > > The only significant comment was: > > e.g. `"de_DE" => "de_DE@ISO8859-15` should be `e.g. "de_DE" => > "de_DE.ISO8859-15"` ? Since it's an encoding, @ is used for a modifier. > FYI, https://www.ietf.org/rfc/rfc4646.txt > It's a good catch; that looks like a typo. Did that appear in more than one place? What are the next steps then? Thanks, John
[PATCH] Contribute FreeBSD unwind support (x86_64 and x86)
I have maintained unwind support for FreeBSD i386 and x86_64 in my
"gnat-aux" repository for many years (I created it). I've always
intended on contributing it back to GCC, but I never got around to
"proving" it worked until now.
The version I've been using actually has two flavors: FreeBSD 8 and
below and FreeBSD 9 and above. However, the last of the FreeBSD 8
releases reaches EOL at the end of June so the unwind support I've
attached here drops the FreeBSD 8 variation for simplicity's sake.
I was under the impression that MD unwinding was used for more than just
GNAT but it looks like that impression was wrong. When I ran the
testsuite, the only tests affected were Ada tests.
FreeBSD 10.1 / gcc-6.0.0 before patch applied:
http://leaf.dragonflybsd.org/~marino/freebsd/summary-100F64.txt
FreeBSD 10.1 / gcc-6.0.0 after patch applied:
http://leaf.dragonflybsd.org/~marino/freebsd/summary-unwind-100F64.txt
Difference between runs:
http://leaf.dragonflybsd.org/~marino/freebsd/unwind-diff-100F64.txt
FreeBSD 11/amd64 with patch (Ada only):
http://leaf.dragonflybsd.org/~marino/freebsd/summary-110F64.txt
FreeBSD 11/i386 with patch (Ada only)
http://leaf.dragonflybsd.org/~marino/freebsd/summary-110F32.txt
Note that I provided a similar unwind support for DragonFly a few months
ago. Please consider applying the attached patch to gcc trunk. (copy
of patch found here:
http://leaf.dragonflybsd.org/~marino/freebsd/freebsd-unwind-support.diff )
Suggested text for libgcc/ChangeLog:
2015-05-XX John Marino
* config.host (i[34567]86-*-freebsd*, x86_64-*-freebsd*):
Set md_unwind_header
* config/i386/freebsd-unwind.h: New.
Also please recall that my copyright assignment to FSF is in order!
Thanks,
John Marino
--- /dev/null
+++ libgcc/config/i386/freebsd-unwind.h
@@ -0,0 +1,173 @@
+/* DWARF2 EH unwinding support for FreeBSD: AMD x86-64 and x86.
+ Copyright (C) 2015 Free Software Foundation, Inc.
+ Contributed by John Marino
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
+<http://www.gnu.org/licenses/>. */
+
+/* Do code reading to identify a signal frame, and set the frame
+ state data appropriately. See unwind-dw2.c for the structs. */
+
+#include
+#include
+#include
+#include
+
+#define REG_NAME(reg) sf_uc.uc_mcontext.mc_## reg
+
+#ifdef __x86_64__
+#define MD_FALLBACK_FRAME_STATE_FOR x86_64_freebsd_fallback_frame_state
+
+static _Unwind_Reason_Code
+x86_64_freebsd_fallback_frame_state
+(struct _Unwind_Context *context, _Unwind_FrameState *fs)
+{
+ struct sigframe *sf;
+ long new_cfa;
+
+ /* Prior to FreeBSD 9, the signal trampoline was located immediately
+ before the ps_strings. To support non-executable stacks on AMD64,
+ the sigtramp was moved to a shared page for FreeBSD 9. Unfortunately
+ this means looking frame patterns again (sys/amd64/amd64/sigtramp.S)
+ rather than using the robust and convenient KERN_PS_STRINGS trick.
+
+ : lea 0x10(%rsp),%rdi
+ : pushq $0x0
+ : mov $0x1a1,%rax
+ : syscall
+
+ If we can't find this pattern, we're at the end of the stack.
+ */
+
+ if (!( *(unsigned int *)(context->ra) == 0x247c8d48
+&& *(unsigned int *)(context->ra + 4) == 0x48006a10
+&& *(unsigned int *)(context->ra + 8) == 0x01a1c0c7
+&& *(unsigned int *)(context->ra + 12) == 0x050f ))
+return _URC_END_OF_STACK;
+
+ sf = (struct sigframe *) context->cfa;
+ new_cfa = sf->REG_NAME(rsp);
+ fs->regs.cfa_how = CFA_REG_OFFSET;
+ /* Register 7 is rsp */
+ fs->regs.cfa_reg = 7;
+ fs->regs.cfa_offset = new_cfa - (long) context->cfa;
+
+ /* The SVR4 register numbering macros aren't usable in libgcc. */
+ fs->regs.reg[0].how = REG_SAVED_OFFSET;
+ fs->regs.reg[0].loc.offset = (long)&sf->REG_NAME(rax) - new_cfa;
+ fs->regs.reg[1].how = REG_SAVED_OFFSET;
+ fs->regs.reg[1].loc.offset = (long)&sf->REG_NAME(rdx) - new_cfa;
+ fs->regs.reg[2].how = REG_SAVED_OFFSET;
+ fs->regs.reg[2].loc.offset = (long)&sf->
Re: [PATCH] Contribute FreeBSD unwind support (x86_64 and x86)
On 5/27/2015 18:17, Jeff Law wrote: > Thanks for pointing that out. Otherwise I'd probably have asked the > redundant question :-) > > Installed on the trunk. > Thanks a lot, Jeff! Very painless this time. :) By the way, I can't see any reason why this couldn't be backported to the gcc-5 branch as well. I don't know the procedure for that though. Regards, John
[patch] Implement Ada support for DragonFly, improve it for FreeBSD
This patch set is a subset of the GNAT patches I've maintained separately for a few years. I have limited it adding support for x86-64-*-dragonfly* and improving support for i[34567]86-*-freebsd and x86_64-*-freebsd*. In some cases of pre-processor macros, they may contain additions for NetBSD and OpenBSD. GNAT does not officially support these platforms, so technically they are no-ops. However, GNAT is buildable in OpenBSD ports, and in NetBSD's pkgsrc. Since I'm modifying the lines anyway and I already know they are required for NetBSD and OpenBSD, I'm adding them at the same time to reduce diffs elsewhere. I am only doing this when I touch the line for other reasons involving FreeBSD and DragonFly BSD. I've added the attached patch to the gcc trunk as it was on May 29, built GNAT and ran the testsuite. The results are linked here: 1. http://leaf.dragonflybsd.org/~marino/freebsd/dfly64.concise.log.txt 2. http://leaf.dragonflybsd.org/~marino/freebsd/fbsd64.concise.log.txt 3. http://leaf.dragonflybsd.org/~marino/freebsd/fbsd32.concise.log.txt There is one regression in the gnat.dg tests on all platforms, but I believe this is caused by recent commits to GNAT and not by these patches. Note 1) All TOOL_TARGET_PAIRS in gcc/ada/gcc-interface/Makefile.in should be removed for most (if not all) platforms as they were moved to gnattools/configure and are now no-ops. However, for this patch set I only removed them for FreeBSD. Note 2) I removed reference to FreeBSD 6 and earlier. These platforms have been EOL for years (FreeBSD 8 is EOL in 4 weeks) Note 3) FreeBSD should have switched to use errno years ago, this patch does that now. Note 4) For all BSD except DragonFly (which doesn't support i386 anymore), the GCC_UNWINDER is specified for i386 platforms. It wasn't specified before. Note 5) All the ce/cxa/cxg tests that failed on i386-FreeBSD are related to the 53-bit float mantissa issue on FreeBSD. This is resolved by my GNAT-AUX repository changes so the tests pass without compromising other compilers, but those patches are out of scope of this set. copy of patch: http://leaf.dragonflybsd.org/~marino/freebsd/gnat-dragonfly-support.diff copy of suggested commit message: http://leaf.dragonflybsd.org/~marino/freebsd/gnat-dragonfly-support.msg.txt (both attached to this email) Also, my FSF copyright assignment is in order and on file at FSF. Thank you for reviewing this! John gnattools/ChangeLog: 2015-06-XX John Marino * configure.ac (*-*-dragonfly*): Add * configure: Regenerate gcc/ada/ChangeLog: 2015-06-XX John Marino * a-intnam-dragonfly.ads: New * s-osinte-dragonfly.adb: New * s-osinte-dragonfly.ads: New * system-dragonfly-x86_64.ads: New * adaint.c: Add BSD macros * cstreams.c: ditto * gsocket.h: ditto * link.c: ditto * socket.c: ditto * env.c: Add __DragonFly__, remove __FreeBSD__ * init.c: Add __DragonFly__, change __gnat_install_handler prototype from empty to void * initialize.c: Add __DragonFly__ * sysdep.c: ditto. * s-osinte-freebsd.adb: Use __get_errno instead of __error * tracebak.c: Set unwinder for i386 BSD * gcc-interface/Makefile.in: Add x86_64 DragonFly, tweak x86_64 FreeBSD and x86 FreeBSD --- gnattools/configure.orig +++ gnattools/configure @@ -2039,6 +2039,11 @@ mlib-tgt-specific.adbhttp://www.gnu.org/licenses/>. -- +-- -- +-- GNARL was developed by the GNARL team at Florida State University. -- +-- Extensive contributions were provided by Ada Core Technologies, Inc. -- +-- -- +-- + +-- This is the DragonFly BSD THREADS version of this package + +with System.OS_Interface; + +package Ada.Interrupts.Names is + + -- All identifiers in this unit are implementation defined + + pragma Implementation_Defined; + + -- Beware that the mapping of names to signals may be many-to-one. There + -- may be aliases. Also, for all signal names that are not supported on + -- the current system the value of the corresponding constant will be zero. + + SIGHUP : constant Interrupt_ID := + System.OS_Interface.SIGHUP; -- hangup + + SIGINT : constant Interrupt_ID := + System.OS_Interface.SIGINT; -- interrupt (rubout) + + SIGQUIT : constant Interrupt_ID := + System.OS_Interface.SIGQUIT; -- quit (ASCD FS) + + SIGILL : constant Interrupt_ID := + System.OS_Interface.SIGILL; -- illegal instruction (not reset) + + SIGTRAP : constant Interrupt_ID := + System.OS_Interface.SIGTRAP; -- trace trap (not reset) + + SIGIOT : constant Interrupt_ID := + Sy
Re: [patch] Implement Ada support for DragonFly, improve it for FreeBSD
On 6/3/2015 09:30, Arnaud Charlet wrote: >>> Note 1) All TOOL_TARGET_PAIRS in gcc/ada/gcc-interface/Makefile.in >>> should be removed for most (if not all) platforms as they were moved to >>> gnattools/configure and are now no-ops. However, for this patch set I >>> only removed them for FreeBSD. >> >> They are actually used if you configure with --disable-libada so should be >> preserved. > > Right. Okay, so that means the Makefile.in patch needs changing in two ways: 1. Don't remove TOOL_TARGET_PAIRS lines from two FreeBSD targets 2. Add TOOL_TARGET_PAIRS line to new DragonFly target. Is a new submission necessary or can this be handled by committer? A new submission will take me a few days because I'm traveling ATM. >> >> This looks good to me modulo the TOOL_TARGET_PAIRS thing. But ChangeLog >> lines >> must all start with a capital letter and end with a period. >> >> Please leave a couple of more days for Thomas or Arno to comment though. > > My main question is: who will maintain these files after they are in > (e.g. regularly test this configuration and post patches to fix any breakage)? Well, both FreeBSD and DragonFly are officially supported platforms. They both utilize FreeBSD ports which supports the last 5 releases and the development release of GCC. Additionally it features 2-3 versions that specifically build GNAT. So it is built continuously and breakage will be found. In all likelihood, I would be the first to discover the breakage and also the most likely to submit the patch. This covers all three targets (both FreeBSD and the one DragonFly). By the way, I am not aware of "official" build testing on the two existing FreeBSD configurations, so in any case there is no regression. Jonathan Wakely told me about gcc build farms -- I'd like to get a continuous, automated DragonFly test build going as well. John
Re: [patch] Implement Ada support for DragonFly, improve it for FreeBSD
On 6/3/2015 11:39, Thomas Quinot wrote: > Patch looks good to me. The story with floats is that on FreeBSD, the > i386 FPU is set to 53-bit floats, but the GNAT runtime library always > issues a "finit" instruction to reset it to full precision, so we need > to reset TARGET_96_ROUND_53_LONG_DOUBLE to 0. I have this fixed in an interesting way on gnat-aux. I found that setting TARGET_96_ROUND_53_LONG_DOUBLE affects other front ends, so you have to choose which one you want to be correct, GNAT or the C (or whatever, can't remember which ones were affected now) My solution was to create two common backends, one for gnat and one for the others. An example of the main patch is here: https://raw.githubusercontent.com/jrmarino/draco/master/misc/flux5/patch-gcc_Makefile.in (note the new s-modes-ada target) and then this patch is needed: https://raw.githubusercontent.com/jrmarino/draco/master/misc/flux5/patch-gcc_ada_gcc-interface_Make-lang.in With those modifications, all the ACATS tests pass on i386 and the other front ends work as expected. I don't know if such a modification would ever be considered for GCC but I've been running it for a couple of years with no reported problems. John
Re: [patch] Implement Ada support for DragonFly, improve it for FreeBSD
On 6/3/2015 11:03, Arnaud Charlet wrote: >> Is a new submission necessary or can this be handled by committer? > Preferably yes. >> A new submission will take me a few days because I'm traveling ATM. There was a significant amount of bitrot. Apparently right after I submitted the patch, many macros were adjusted by Adacore hitting the same files and copyrights as I did. I updated the patch set by hand and tested it against the 31 may snapshot. I also fixed the TOOLS_TARGET_PAIRS issue of course. same URL: http://leaf.dragonflybsd.org/~marino/freebsd/gnat-dragonfly-support.diff I also updated the suggested commit message as Eric suggested: http://leaf.dragonflybsd.org/~marino/freebsd/gnat-dragonfly-support.msg.txt Hopefully this patch isn't already bitrotted! John
Re: [patch] Use --enable-libstdcxx-time=yes on DragonFly BSD
On 3/10/2015 20:23, Jonathan Wakely wrote: > It has just occurred to me we might want to make this change for GCC5: > > > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 > index 1727140..0b8c0f0 100644 > --- a/libstdc++-v3/acinclude.m4 > +++ b/libstdc++-v3/acinclude.m4 > @@ -1219,11 +1219,11 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [ > ac_has_clock_realtime=yes > fi > ac_has_nanosleep=yes > ac_has_sched_yield=yes > ;; > - freebsd*|netbsd*) > + freebsd*|netbsd*|dragonfly*) > ac_has_clock_monotonic=yes > ac_has_clock_realtime=yes > ac_has_nanosleep=yes > ac_has_sched_yield=yes > ;; > > > We could make this change post-GCC5 but as the dragonfly target is new > for GCC5 it would be a shame to release it with a sub-optimal > resolution for clocks and thread sleeping. > > John, assuming I'm right that dragonfly supports all these features, > could you test this change? (You'll need the same change on line > 19555 of the libstdc++-v3/configure script.) > Sure, I can test it. How can I tell if the result is successful? Successful build versus failed build? Thanks, John
Re: [patch] Use --enable-libstdcxx-time=yes on DragonFly BSD
On 3/10/2015 21:18, Jonathan Wakely wrote: > On 10/03/15 20:55 +0100, John Marino wrote: >> On 3/10/2015 20:23, Jonathan Wakely wrote: >>> John, assuming I'm right that dragonfly supports all these features, >>> could you test this change? (You'll need the same change on line >>> 19555 of the libstdc++-v3/configure script.) >>> >> >> Sure, I can test it. How can I tell if the result is successful? >> Successful build versus failed build? > > Yes, that should be enough. If any of sched_yield(), nanosleep(), > clock_gettime() etc. is missing you'll get a build failure. > > I'll do a full testsuite run (bootstrap and 'make check') on dragonfly > before committing, but I'll need some time to resurrect the dragonfly > VM I was using previously. Hi Jonathan, gcc 5 built fine on DragonFly with your patch: http://muscles.dragonflybsd.org/bulk/bleeding-edge-potential/20150310_142205/logs/gcc5-5.0.s20150308.log Regards, John
Re: [patch] Use --enable-libstdcxx-time=yes on DragonFly BSD
On 3/10/2015 23:04, John Marino wrote: > On 3/10/2015 21:18, Jonathan Wakely wrote: >> On 10/03/15 20:55 +0100, John Marino wrote: >>> On 3/10/2015 20:23, Jonathan Wakely wrote: >>>> John, assuming I'm right that dragonfly supports all these features, >>>> could you test this change? (You'll need the same change on line >>>> 19555 of the libstdc++-v3/configure script.) >>>> >>> >>> Sure, I can test it. How can I tell if the result is successful? >>> Successful build versus failed build? >> >> Yes, that should be enough. If any of sched_yield(), nanosleep(), >> clock_gettime() etc. is missing you'll get a build failure. >> >> I'll do a full testsuite run (bootstrap and 'make check') on dragonfly >> before committing, but I'll need some time to resurrect the dragonfly >> VM I was using previously. > > Hi Jonathan, > gcc 5 built fine on DragonFly with your patch: > http://muscles.dragonflybsd.org/bulk/bleeding-edge-potential/20150310_142205/logs/gcc5-5.0.s20150308.log > Hi Jonathan, Today I build gcc5 and looked at the config.h contained in libstdc++-v3's build directory and none of those variables are enabled. The code that is patched doesn't seem to do anything. I grepped the entire build directory for "libstdcxx_time" and got no results. I don't have "--enable-libstdcxx-time" set as a configure argument. So I am thinking somehow this configuration check got skipped completely. John
Re: [patch] Use --enable-libstdcxx-time=yes on DragonFly BSD
On 3/13/2015 11:23, Jonathan Wakely wrote: > On 13 March 2015 at 08:50, John Marino wrote: >> Hi Jonathan, >> Today I build gcc5 and looked at the config.h contained in >> libstdc++-v3's build directory and none of those variables are enabled. >> >> The code that is patched doesn't seem to do anything. I grepped the >> entire build directory for "libstdcxx_time" and got no results. >> >> I don't have "--enable-libstdcxx-time" set as a configure argument. So >> I am thinking somehow this configuration check got skipped completely. > > Hi John, > > The variables cause additional checks to be run in configure, which > then result in these macros in c++config.h Okay. I guess I was just looking at the wrong config file then. Thanks for sorting out that confusion! John
[Ada] Add DragonFly support to System.OS_Constants template
The System.OS_Constants templates for GNAT has three preprocessor checks for FreeBSD. In all three cases, DragonFly BSD needs to be treated the same as FreeBSD. The attached patch accomplishes this. Please consider incorporating the patch into trunk. Regards, John Index: gcc/ada/s-oscons-tmplt.c === --- gcc/ada/s-oscons-tmplt.c(revision 225453) +++ gcc/ada/s-oscons-tmplt.c(working copy) @@ -402,7 +402,7 @@ /* ioctl(2) requests are "int" in UNIX, but "unsigned long" on FreeBSD */ -#ifdef __FreeBSD__ +#if defined (__FreeBSD__) || defined (__DragonFly__) # define CNI CNU # define IOCTL_Req_T "unsigned" #else @@ -1014,7 +1014,7 @@ */ -#if defined (__FreeBSD__) || defined (__linux__) +#if defined (__FreeBSD__) || defined (__linux__) || defined (__DragonFly__) # define PTY_Library "-lutil" #else # define PTY_Library "" @@ -1435,7 +1435,8 @@ #endif CND(CLOCK_THREAD_CPUTIME_ID, "Thread CPU clock") -#if defined(__FreeBSD__) || (defined(_AIX) && defined(_AIXVERSION_530)) +#if defined(__FreeBSD__) || (defined(_AIX) && defined(_AIXVERSION_530)) \ + || defined(__DragonFly__) /** On these platforms use system provided monotonic clock instead of ** the default CLOCK_REALTIME. We then need to set up cond var attributes ** appropriately (see thread.c).
[PATCH] libstdc++ os_defines now required for DragonFly
On the development branch of DragonFly BSD, it was discovered that __LONG_LONG_SUPPORTED was accidently unconditionally defined. This had a positive side effect of allowing GCC conftests to pass for C99 support via wchar.h. When the bug was fixed, the wchar C99 conftest now fails, resulting in a c++ regression where software that previously compiled now fail due to unknown functions such as wcstoll (since C99 supported changed from "true" to "false") FreeBSD behaves the exactly same way, and this OS dealt with it with system-specific defines. The DragonFly regression is fixed by copying the relevant defines from the FreeBSD config. (see attached patch). This patch should be applied to trunk and also backported to GCC-5 branch. Thanks, John Index: libstdc++-v3/config/os/bsd/dragonfly/os_defines.h === --- libstdc++-v3/config/os/bsd/dragonfly/os_defines.h (revision 225453) +++ libstdc++-v3/config/os/bsd/dragonfly/os_defines.h (working copy) @@ -29,4 +29,9 @@ // System-specific #define, typedefs, corrections, etc, go here. This // file will come before all others. +#define _GLIBCXX_USE_C99_CHECK 1 +#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE >= 1999)) +#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1 +#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined __LONG_LONG_SUPPORTED) + #endif
[patch] testsuite enable PIE tests on DragonFly
DragonFly supports PIE but the tests for it are disabled.
The attached patch for the trunk will enable these checks on DragonFly.
Thanks for considering this!
John
p.s. suggested gcc/testsuite/changelog entry:
2015-07-XX John Marino
* lib/target-supports.exp (check_effective_target_pie):
Add *-*-dragonfly*
Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp (revision 225610)
+++ gcc/testsuite/lib/target-supports.exp (working copy)
@@ -974,6 +974,7 @@
proc check_effective_target_pie { } {
if { [istarget *-*-darwin\[912\]*]
+|| [istarget *-*-dragonfly*]
|| [istarget *-*-freebsd*]
|| [istarget *-*-linux*]
|| [istarget *-*-gnu*] } {
[patch] Fix Unwind support on DragonFly BSD after sigtramp move
Right after DragonFly 4.8 was released (27 Mar 2017), the signal
trampoline was moved (twice) in response to a Ryzen bug. This broke
GCC's unwind support for DragonFly.
To avoid hardcoding the sigtramp location to avoid issues like this in
the future, a new sysctl was added to DragonFly to return the signal
trampoline address range (FreeBSD has a similar sysctl for similar
reasons). The attached patch fixes DragonFly unwind support for current
DragonFly, and maintains support for Release 4.8 and earlier.
This patch has been in use for a few months and works fine. It is
similar in function to the FreeBSD Aarch64 unwind support I submitted
through Andreas T. a few months ago.
I believe the patch can be applied to trunk and release 7 branch.
I am the closest thing to a maintainer for DragonFly, so I don't know if
additional approval is needed. This patch is purely DragonFly-specific
and cannot affect other platforms in any way.
If agreed, it would be great if somebody could commit this for me
against the trunk and GCC-7-branch.
Thanks!
John
P.S. Yes, my copyright assignment is on file (I've contributed a few
patches already).
suggested log entry of libgcc/ChangeLog:
2017-07-XX John Marino
* config/i386/dragonfly-unwind.h: Handle sigtramp relocation.
--- libgcc/config/i386/dragonfly-unwind.h.orig 2017-02-06 16:26:52 UTC
+++ libgcc/config/i386/dragonfly-unwind.h
@@ -28,9 +28,13 @@ see the files COPYING3 and COPYING.RUNTI
#include
#include
+#include
#include
#include
#include
+#if __DragonFly_version > 400800
+#include
+#endif
#define REG_NAME(reg) sf_uc.uc_mcontext.mc_## reg
@@ -39,20 +43,44 @@ see the files COPYING3 and COPYING.RUNTI
#define MD_FALLBACK_FRAME_STATE_FOR x86_64_dragonfly_fallback_frame_state
-static void
-x86_64_sigtramp_range (unsigned char **start, unsigned char **end)
+static int
+x86_64_outside_sigtramp_range (unsigned char *pc)
{
- unsigned long ps_strings;
- int mib[2];
- size_t len;
-
- mib[0] = CTL_KERN;
- mib[1] = KERN_PS_STRINGS;
- len = sizeof (ps_strings);
- sysctl (mib, 2, &ps_strings, &len, NULL, 0);
+ static int sigtramp_range_determined = 0;
+ static unsigned char *sigtramp_start, *sigtramp_end;
- *start = (unsigned char *)ps_strings - 32;
- *end = (unsigned char *)ps_strings;
+ if (sigtramp_range_determined == 0)
+{
+#if __DragonFly_version > 400800
+ struct kinfo_sigtramp kst = {0};
+ size_t len = sizeof (kst);
+ int mib[3] = { CTL_KERN, KERN_PROC, KERN_PROC_SIGTRAMP };
+
+ sigtramp_range_determined = 1;
+ if (sysctl (mib, 3, &kst, &len, NULL, 0) == 0)
+ {
+sigtramp_range_determined = 2;
+sigtramp_start = kst.ksigtramp_start;
+sigtramp_end = kst.ksigtramp_end;
+ }
+#else
+ unsigned long ps_strings;
+ size_t len = sizeof (ps_strings);
+ int mib[2] = { CTL_KERN, KERN_PS_STRINGS };
+
+ sigtramp_range_determined = 1;
+ if (sysctl (mib, 2, &ps_strings, &len, NULL, 0) == 0)
+ {
+sigtramp_range_determined = 2;
+sigtramp_start = (unsigned char *)ps_strings - 32;
+sigtramp_end = (unsigned char *)ps_strings;
+ }
+#endif
+}
+ if (sigtramp_range_determined < 2) /* sysctl failed if < 2 */
+return 1;
+
+ return (pc < sigtramp_start || pc >= sigtramp_end );
}
@@ -60,13 +88,10 @@ static _Unwind_Reason_Code
x86_64_dragonfly_fallback_frame_state
(struct _Unwind_Context *context, _Unwind_FrameState *fs)
{
- unsigned char *pc = context->ra;
- unsigned char *sigtramp_start, *sigtramp_end;
struct sigframe *sf;
long new_cfa;
- x86_64_sigtramp_range(&sigtramp_start, &sigtramp_end);
- if (pc >= sigtramp_end || pc < sigtramp_start)
+ if (x86_64_outside_sigtramp_range(context->ra))
return _URC_END_OF_STACK;
sf = (struct sigframe *) context->cfa;
Add Ada support for aarch64-*-freebsd*
The attached patch to gcc trunk enables Ada support on aarch64-*-freebsd*. All tests pass except those affected by the currently missing unwind support (c52103x, c52104x, c52104y, cb1010a, cb1010c, cb1010d, gnat.dg/null_pointer_deref* (3)). I'd also like to get this patch backported to the gcc-6 branch. There's a one-line content difference between patches, so I've attached the 6.x specific patch as well. My copyright assignment is on file and in order. Thanks, John gcc/ada/Changelog: 2017-02-XX John Marino * gcc-interface/Makefile.in: Support aarch64-freebsd --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus --- gcc/ada/gcc-interface/Makefile.in.orig 2017-02-06 16:29:55 UTC +++ gcc/ada/gcc-interface/Makefile.in @@ -1495,6 +1495,34 @@ ifeq ($(strip $(filter-out x86_64 kfreeb LIBRARY_VERSION := $(LIB_VERSION) endif +# aarch64 FreeBSD +ifeq ($(strip $(filter-out %aarch64 freebsd%,$(target_cpu) $(target_os))),) + LIBGNAT_TARGET_PAIRS = \ + a-intnam.ads--- gcc/ada/gcc-interface/Makefile.in.orig 2017-02-06 18:55:09 UTC +++ gcc/ada/gcc-interface/Makefile.in @@ -1475,6 +1475,34 @@ ifeq ($(strip $(filter-out x86_64 kfreeb LIBRARY_VERSION := $(LIB_VERSION) endif +# aarch64 FreeBSD +ifeq ($(strip $(filter-out %aarch64 freebsd%,$(target_cpu) $(target_os))),) + LIBGNAT_TARGET_PAIRS = \ + a-intnam.ads
Re: Add Ada support for aarch64-*-freebsd*
On 2/7/2017 05:37, Arnaud Charlet wrote: The attached patch to gcc trunk enables Ada support on aarch64-*-freebsd*. All tests pass except those affected by the currently missing unwind support (c52103x, c52104x, c52104y, cb1010a, cb1010c, cb1010d, gnat.dg/null_pointer_deref* (3)). I'd also like to get this patch backported to the gcc-6 branch. There's a one-line content difference between patches, so I've attached the 6.x specific patch as well. My copyright assignment is on file and in order. gcc/ada/Changelog: 2017-02-XX John Marino * gcc-interface/Makefile.in: Support aarch64-freebsd It seems wrong to reuse system-freebsd-x86.ads for a different processor. We should either: - use a different system file (e.g. system-freebsd-aarch64.ads) - or rename the file to e.g. system-freebsd.ads, *and* adjust the setting of at least Default_Bit_Order to something like: Default_Bit_Order : constant Bit_Order := Bit_Order'Val (Standard'Default_Bit_Order); Arno Hi Arno, This is exactly what aarch64-*-linux* is doing is doing in gcc 6 branch (e.g. system.adsafter, but now I see it has been changed to "system.ads"system.adsthen to "system.ads I would vote for simply copying system-freebsd-x86.ads to system-freebsd-aarch64.ads but that seems to go against the recent effort to merge the x86-64 and i386 system versions. I am not currently aware of any content differences between system-freebsd-x86.ads and the proposed system-freebsd-aarch64.ads. They would be duplicates as far as I know. (I'm not particularly fond of one system file for all processors though). John
Re: Add Ada support for aarch64-*-freebsd*
On 2/7/2017 07:41, Arnaud Charlet wrote: This is exactly what aarch64-*-linux* is doing is doing in gcc 6 branch (e.g. system.ads Well no, you are reusing an x86_64 file for an aarch64 architecture, so this is exactly the same issue. I was pointing out that on gcc-6, aarch64-linux is using x86-64 system file too. Since I used gcc-6 for the original testing on freebsd, that's where it came from. It's been changed on trunk, but nobody backported those changes to gcc-6. It was obviously "good enough" and a "placeholder" as indicated in the nearby comment. If you want, I can create a duplicate file with a different name. Or I can add a "placeholder" comment like we see on aarch64-linux. Adding a new system file would not change the end result but if you like it more, I'll submit a new patch that creates this new system file. John
Re: Add Ada support for aarch64-*-freebsd*
On 2/7/2017 07:53, Arnaud Charlet wrote: I was pointing out that on gcc-6, aarch64-linux is using x86-64 system file too. Since I used gcc-6 for the original testing on freebsd, that's where it came from. It's been changed on trunk, but nobody backported those changes to gcc-6. It was obviously "good enough" and a "placeholder" as indicated in the nearby comment. Well, that's a bad practice that we want to fix rather than copy :-) If you want, I can create a duplicate file with a different name. Or I can add a "placeholder" comment like we see on aarch64-linux. Adding a new system file would not change the end result but if you like it more, I'll submit a new patch that creates this new system file. Given that the more recent trend is to merge more these system files as opposed to systematically breaking them, I'd recommend renaming the file to system-freedbsd and change the definition of Default_Bit_Order which will be needed sooner or later in any case (if not already). Okay, I'll modify the patch accordingly. It increases the complexity but if that's the correct approach then so be it. John
Re: Add Ada support for aarch64-*-freebsd*
On 2/7/2017 07:53, Arnaud Charlet wrote: I was pointing out that on gcc-6, aarch64-linux is using x86-64 system file too. Since I used gcc-6 for the original testing on freebsd, that's where it came from. It's been changed on trunk, but nobody backported those changes to gcc-6. It was obviously "good enough" and a "placeholder" as indicated in the nearby comment. Well, that's a bad practice that we want to fix rather than copy :-) If you want, I can create a duplicate file with a different name. Or I can add a "placeholder" comment like we see on aarch64-linux. Adding a new system file would not change the end result but if you like it more, I'll submit a new patch that creates this new system file. Given that the more recent trend is to merge more these system files as opposed to systematically breaking them, I'd recommend renaming the file to system-freedbsd and change the definition of Default_Bit_Order which will be needed sooner or later in any case (if not already). Okay, I've attached the trunk patch. The commit message is adjusted accordingly: gcc/ada/Changelog: 2017-02-XX John Marino * system-freebsd-x86.ads: Rename into... * system-freebsd.ads: ...this (Default_Bit_Order): Define using Standard'Default_Bit_Order * gcc-interface/Makefile.in: Support aarch64-freebsd (x86_64/FreeBSD): Adjust to above renaming. (i386/FreeBSD): Likewise. Given the precedent set on gcc-6 with aarch64-linux, I think the gcc-6 backport patch is still ok (re-attached for convenience) and the original commit message then is still valid: gcc/ada/Changelog: 2017-02-XX John Marino * gcc-interface/Makefile.in: Support aarch64-freebsd What do you think, Arno? Thanks, John --- gcc/ada/gcc-interface/Makefile.in.orig 2017-02-06 16:29:55 UTC +++ gcc/ada/gcc-interface/Makefile.in @@ -1495,6 +1495,34 @@ ifeq ($(strip $(filter-out x86_64 kfreeb LIBRARY_VERSION := $(LIB_VERSION) endif +# aarch64 FreeBSD +ifeq ($(strip $(filter-out %aarch64 freebsd%,$(target_cpu) $(target_os))),) + LIBGNAT_TARGET_PAIRS = \ + a-intnam.adshttp://www.gnu.org/licenses/>. -- +-- -- +-- GNAT was originally developed by the GNAT team at New York University. -- +-- Extensive contributions were provided by Ada Core Technologies Inc. -- +-- -- +-- + +package System is + pragma Pure; + -- Note that we take advantage of the implementation permission to make + -- this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada + -- 2005, this is Pure in any case (AI-362). + + pragma No_Elaboration_Code_All; + -- Allow the use of that restriction in units that WITH this unit + + type Name is (SYSTEM_NAME_GNAT); + System_Name : constant Name := SYSTEM_NAME_GNAT; + + -- System-Dependent Named Numbers + + Min_Int : constant := Long_Long_Integer'First; + Max_Int : constant := Long_Long_Integer'Last; + + Max_Binary_Modulus: constant := 2 ** Long_Long_Integer'Size; + Max_Nonbinary_Modulus : constant := 2 ** Integer'Size - 1; + + Max_Base_Digits : constant := Long_Long_Float'Digits; + Max_Digits: constant := Long_Long_Float'Digits; + + Max_Mantissa : constant := 63; + Fine_Delta: constant := 2.0 ** (-Max_Mantissa); + + Tick : constant := 0.000_001; + + -- Storage-related Declarations + + type Address is private; + pragma Preelaborable_Initialization (Address); + Null_Address : constant Address; + + Storage_Unit : constant := 8; + Word_Size: constant := Standard'Word_Size; + Memory_Size : constant := 2 ** Word_Size; + + -- Address comparison + + function "<" (Left, Right : Address) return Boolean; + function "<=" (Left, Right : Address) return Boolean; + function ">" (Left, Right : Address) return Boolean; + function ">=" (Left, Right : Address) return Boolean; + function "=" (Left, Right : Address) return Boolean; + + pragma Import (Intrinsic, "<"); + pragma Import (Intrinsic, "<="); + pragma Import (Intrinsic, ">"); + pragma Import (Intrinsic, ">="); + pragma Import (Intrinsic, "="); + + -- Other System-Dependent Declarations + + type Bit_Order is (High_Order_First, Low_Order_First); + Default_Bit_Order : constant Bit_Order := + Bit_Order'Val (Standard'Default_Bit_Order); + pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning + + -- Priority-r
Re: [patch][libstdc++] Provide nearly complete locale support for DragonFly
On 7/31/2015 6:06 PM, John Marino wrote:
> So far, DragonFly only handles the C/POSIX locale through the "generic"
> locale support files, similar to FreeBSD and Darwin. The following
> patchset enables nearly complete support for named locales. The except
> is for std:messages which requires gettext support in libc which is not
> present in any *BSD. For that category, I have left generic support in
> place at Jonathan's recommendation.
>
> The support was made by talking the GNU version and adapting it to work
> on DragonFly.
>
> Testing has shown these patches to be working. A "before" test results:
> https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg01678.html
> PASS: 9883
> FAIL: 89
> XSUCC: 1
> XFAIL: 66
> UNSUP: 465
> The most recent test:
> https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg03024.html
> PASS: 10074
> FAIL: 32
> XFAIL: 68
> UNSUP: 401
>
> For full disclosure, a number of improvements were made to the OS in the
> area of locales, such as DragonFly being the first BSD to acquire full
> collation support.
>
> Most of the remaining failures are due to differences in locale
> definitions between linux and DragonFly (DragonFly now uses CLDR POSIX
> definitions, v2.0.1 currently)
>
> Attachments:
> 1. combined diff
> 2. diff between gnu and dragonfly version (FYI)
> 3. Suggested Changelog entry
>
> This work should be highly interesting for FreeBSD and perhaps darwin as
> well. FreeBSD may be able to switch to it directly without any required
> modifications, but of course that must be tested.
>
> There is no risk to approving this patchset because it affects only
> DragonFly. Please consider approving this for incorporating into trunk
> (also recall that my FSF copyright assignment is filed and in order.)
>
I'd like to ping the original post
(https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02678.html )
and also provide a 2-line revision of the patch set.
The first line adds "#include " to bits/c++locale.h which is
needed for the locale_t type definition.
The second change adds "#define _GLIBCXX_USE_C99 1" to dragonfly's
os_defines.h. We copied FreeBSD's configuration, but FreeBSD doesn't
yet support C99 so it wasn't set there. It fixes several regressions we
found after using GCC a bit.
How does this attached patchset look?
I had to add one line to the suggested Changelog entry for os_defines.h
Regards,
John
Index: libstdc++-v3/acinclude.m4
===
--- libstdc++-v3/acinclude.m4 (revision 226444)
+++ libstdc++-v3/acinclude.m4 (working copy)
@@ -2087,17 +2087,17 @@
dragonfly)
AC_MSG_RESULT(dragonfly)
- CLOCALE_H=config/locale/generic/c_locale.h
+ CLOCALE_H=config/locale/dragonfly/c_locale.h
CLOCALE_CC=config/locale/dragonfly/c_locale.cc
- CCODECVT_CC=config/locale/generic/codecvt_members.cc
- CCOLLATE_CC=config/locale/generic/collate_members.cc
+ CCODECVT_CC=config/locale/dragonfly/codecvt_members.cc
+ CCOLLATE_CC=config/locale/dragonfly/collate_members.cc
CCTYPE_CC=config/locale/dragonfly/ctype_members.cc
CMESSAGES_H=config/locale/generic/messages_members.h
CMESSAGES_CC=config/locale/generic/messages_members.cc
- CMONEY_CC=config/locale/generic/monetary_members.cc
- CNUMERIC_CC=config/locale/generic/numeric_members.cc
- CTIME_H=config/locale/generic/time_members.h
- CTIME_CC=config/locale/generic/time_members.cc
+ CMONEY_CC=config/locale/dragonfly/monetary_members.cc
+ CNUMERIC_CC=config/locale/dragonfly/numeric_members.cc
+ CTIME_H=config/locale/dragonfly/time_members.h
+ CTIME_CC=config/locale/dragonfly/time_members.cc
CLOCALE_INTERNAL_H=config/locale/generic/c++locale_internal.h
;;
Index: libstdc++-v3/config/locale/dragonfly/c_locale.cc
===
--- libstdc++-v3/config/locale/dragonfly/c_locale.cc(revision 226444)
+++ libstdc++-v3/config/locale/dragonfly/c_locale.cc(working copy)
@@ -1,4 +1,4 @@
-// Wrapper for underlying C-language localization -*- C++ -*-
+// localization implementation details, DragonFly version -*- C++ -*-
// Copyright (C) 2014-2015 Free Software Foundation, Inc.
//
@@ -27,19 +27,15 @@
//
// Written by Benjamin Kosnik
+// Modified for DragonFly by John Marino
-#include // For errno
-#include // For isinf, finite, finitef, fabs
-#include // For strof, strtold
-#include
-#include
+#include
#include
+#include
#include
+#include
+#include
-#ifdef _GLIBCXX_HAVE_IEEEFP_H
-#include
-#endif
-
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -47,41 +43,11 @@
template<>
Re: [patch][libstdc++] Provide nearly complete locale support for DragonFly
On 8/27/2015 2:26 PM, Jonathan Wakely wrote: > > N.B. please CC the libstdc++ list on all libstdc++ patches. > The tests on DragonFly look excellent now, nice work. Okay, noted for the future. > I think that should probably be defined on FreeBSD too now, so that > the _GLIBCXX_USE_C99_DYNAMIC checks come into effect. I actually doubt this is valid for FreeBSD. That platform is missing C99 functions in libm. Once the FreeBSD libm is augmented, then it should be set. However, FreeBSD should evaluate switching from generic locale support to DragonFly locale support. It may even work out of the box (collating pending getting collation support from DragonFly which is already in the works). > Committed to trunk with only minor changes to remove some trailing > whitespace in config/os/bsd/dragonfly/ctype_configure_char.cc and to > capitalize a couple of ChangeLog lines. > > Thanks for the ongoing improvements to DragonFly support. Great! I had caught those whitespace changes when imported into DragonFly base but I must have forgotten to apply those changes to version 2 of the patch set. Thanks for review and I'm glad they were high quality. Regards, John
[patch] gfortran testsuite/read_dir.f90 - set xfail on dragonfly as well
Steve Kargl suspected that read_dir.f90 would fail on all BSDs with the
recent change. At least for DragonFly BSD, he is correct:
https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg01222.html
Please consider incorporating the attached patch which sets the test for
xfail on dragonfly as well as freebsd.
Suggested gcc/testsuite/ChangeLog entry:
2015-09-XX John Marino
* gfortran.dg/read_dir.f90: XFAIL this testcase on DragonFly.
Thanks,
John
Index: gcc/testsuite/gfortran.dg/read_dir.f90
===
--- gcc/testsuite/gfortran.dg/read_dir.f90 (revision 227744)
+++ gcc/testsuite/gfortran.dg/read_dir.f90 (working copy)
@@ -1,4 +1,4 @@
-! { dg-do run { xfail *-*-freebsd* } }
+! { dg-do run { xfail *-*-freebsd* *-*-dragonfly* } }
! PR67367
program bug
implicit none
[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 4/29/2014 19:23, Ian Lance Taylor wrote: > On Tue, Apr 29, 2014 at 11:37 AM, John Marino 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: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 5/2/2014 01:03, Joseph S. Myers wrote: > The include of from seems risky, given that > that's a POSIX header that typically defines various types ISO C does not > permit to be defined in (ISO C does not have any general *_t > namespace reservation, unlike POSIX). > > Have you verified that if you include 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 > ? 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 defines, but it at least > seems possible from the name that it is only defining things in the > implementation namespace, with the public being what then > includes 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
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 ; 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 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: > > * 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 ) 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
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: > > * 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 ) 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 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 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 2>&1; 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 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
