public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: John Marino <gnugcc@marino.st>
To: Jeff Law <law@redhat.com>,  "Joseph S. Myers" <joseph@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org, Jonathan Wakely <jwakely.gcc@gmail.com>,
	 Gerald Pfeifer <gerald@pfeifer.com>,
	manu@gcc.gnu.org,
	"Eric Botcazou (gnu.org)" <ebotcazou@gcc.gnu.org>
Subject: Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
Date: Fri, 09 May 2014 07:15:00 -0000	[thread overview]
Message-ID: <536C8059.8090304@marino.st> (raw)
In-Reply-To: <536C671F.4080100@redhat.com>

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

  reply	other threads:[~2014-05-09  7:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-19 19:41 John Marino
2014-04-20 19:05 ` Jonathan Wakely
2014-04-21  4:41   ` John Marino
2014-04-29 15:39     ` [PING] " John Marino
2014-04-29 17:25       ` Ian Lance Taylor
2014-04-29 18:50         ` John Marino
2014-04-30  0:07           ` Ian Lance Taylor
2014-05-01 23:03 ` Joseph S. Myers
2014-05-01 23:46   ` John Marino
2014-05-02 17:49     ` Joseph S. Myers
2014-05-02 18:17       ` John Marino
2014-05-02 20:15         ` Joseph S. Myers
2014-05-02 20:20           ` John Marino
2014-05-03  7:12           ` John Marino
2014-05-08 13:15             ` Jonathan Wakely
2014-05-08 13:32               ` Jeff Law
2014-05-08 13:36                 ` John Marino
2014-05-09  5:27             ` Jeff Law
2014-05-09  7:15               ` John Marino [this message]
2014-05-12 16:59                 ` Jeff Law
2014-05-12 17:10                   ` John Marino
2014-05-12 17:14                     ` Jeff Law
2014-05-13 14:10                       ` Jonathan Wakely
2014-05-21 11:43                     ` Jonathan Wakely
2015-04-09 20:12                       ` [doc] Add John Marino to doc/contrib.texi (was: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly) Gerald Pfeifer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=536C8059.8090304@marino.st \
    --to=gnugcc@marino.st \
    --cc=ebotcazou@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gerald@pfeifer.com \
    --cc=joseph@codesourcery.com \
    --cc=jwakely.gcc@gmail.com \
    --cc=law@redhat.com \
    --cc=manu@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).