public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: "Nicolas Bértolo" <nicolasbertolo@gmail.com>
Cc: jit@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Port libgccjit to Windows.
Date: Thu, 28 May 2020 15:00:37 -0400	[thread overview]
Message-ID: <885d0b34df56c30f25c2ba57f4eecf517d1ba05c.camel@redhat.com> (raw)
In-Reply-To: <CAFnS-Oncc2W_1UZv1BhHQLjBUGOiBi65wT6uv=mEkbDO9HMLJw@mail.gmail.com>

On Wed, 2020-05-27 at 22:27 -0300, Nicolas Bértolo wrote:
> Hi,
> 
> > Do you have commit/push access to the gcc repository?
> 
> No I don't.
> 
> > BTW, why isn't it necessary to use --enable-host-shared in Windows?
> > Can we document that?
> 
> That's because all code is position independent in Windows.
> 
> > On the subject of nitpicking, I find myself getting distracted by
> the
> > indentation in the patch; there seem to be a lot of mismatches.
> 
> > What editor are you using, and does it have options to
> > (a) show visible whitespace, and
> > (b) to apply a formatting convention?
> 
> > I use Emacs, and it takes care of this for me.  I haven't used it,
> but
> > there's a contrib/clang-format file in the gcc source tree which
> > presumably describes GCC's coding conventions, if that helps for
> the
> > new code.
> 
> The problem seems to be that I was writing tabs but since I have set
> up my
> editor to show them as 2 spaces I couldn't see what was wrong.

Thanks; the latest patch is much better.

> > Am I right in thinking that this installs the libgccjit.a file on
> Windows?
> > Why is this done?
> 
> That is the file libgccjit.dll.a
> 
> It is the import library for gccjit. It is part of the way Windows
> handles
> dynamic libraries.

Thanks.

> > New C++ source files should have a .cc extension.
> > I hope that at some point we'll rename all the existing .c ones
> > accordingly.
> 
> I just couldn't get Make to generate jit-w32.o from jit-w32.cc.
> It looks for jit-w32.c.
> 
> I had to leave it with the .c extension.

Fair enough.

> > Does this call generate a directory that's only accessible to the
> > current user?
> > Otherwise there could be a risk of a hostile user on the same
> machine
> > clobbering the contents and injecting code into this process.
> 
> I changed the code to generate a directory than can only be accessed
> by the
> current user.
> 
> I've attached a new version. It contains a rewrite of the code that
> creates
> temporary directories.
> 
> Nico

I'm going to have to trust your Windows expertise here; the tempdir
code looks convoluted to me, but perhaps that's the only way to do it.
(Microsoft's docs for "SECURITY_ATTRIBUTES" suggest to me that if
lpSecurityDescriptor is NULL, then the directory gets a default
security descriptor, and that this may mean it's only readable by the
user represented by the access token of the process [1], which might
suggest a simplification - but I'm very hazy on how the security model
in Windows works)


I was able to successfully bootstrap and regression test with your
patch on x86_64-pc-linux-gnu.  I also verified that the result of "make
install" was not affected for my configuration.

I've pushed your patch to master as
c83027f32d9cca84959c7d6a1e519a0129731501.

(I had to do a little fixup of the ChangeLog entries to get them to
work with the new hooks on our git repo)

Thanks again for the patch
Dave

[1] https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/aa379560(v=vs.85)


  reply	other threads:[~2020-05-28 19:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-24 20:02 Nicolas Bértolo
2020-05-24 20:48 ` David Malcolm
2020-05-25 19:48   ` Nicolas Bértolo
2020-05-26 18:40     ` David Malcolm
2020-05-28  1:27       ` Nicolas Bértolo
2020-05-28 19:00         ` David Malcolm [this message]
2020-05-28 19:51           ` Nicolas Bértolo
2020-05-28 20:46             ` David Malcolm
2020-06-02 16:26               ` JonY
2020-06-07 16:03                 ` Nicolas Bértolo
2020-06-08  2:11                   ` JonY
2020-06-11 22:02                     ` Nicolas Bértolo
2020-06-12  0:19                       ` JonY
2020-06-16  0:12                         ` JonY
2020-06-16  0:15                           ` Nicolas Bértolo
2020-05-29 14:48           ` NightStrike

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=885d0b34df56c30f25c2ba57f4eecf517d1ba05c.camel@redhat.com \
    --to=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jit@gcc.gnu.org \
    --cc=nicolasbertolo@gmail.com \
    /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).