From: Caroline Tice <cmtice@google.com>
To: Patrick Wollgast <patrick.wollgast@rub.de>
Cc: bkoz@gnu.org, ktietz@redhat.com,
GCC Patches <gcc-patches@gcc.gnu.org>,
libstdc++@gcc.gnu.org
Subject: Re: [Ping] Port of VTV for Cygwin and MinGW
Date: Tue, 23 Sep 2014 06:16:00 -0000 [thread overview]
Message-ID: <CABtf2+T0a=jCMXLTuVPuYp4ViY-cRK3RARRnQQUEhHyNRMWeNA@mail.gmail.com> (raw)
In-Reply-To: <541B5B7E.2090300@rub.de>
Ok, your patch looks OK to me, but I can only approve the libvtv file
changes. The changes in the other files also seem ok to me, but
someone else will have to approve the modifications in them:
gcc/config/i386/cygwin.h
gcc/config/i386/mingw-w64.h
gcc/config/i386/mingw32.h
gcc/cp/vtable-class-hierarchy.c
gcc/varasm.c
libgcc/Makefile.in
libgcc/config.host
libiberty/obstack.c
libstdc++-v3/acinclude.m4
libstdc++-v3/libsupc++/Makefile.am
libstdc++-v3/libsupc++/vtv_stubs.cc
-- Caroline Tice
cmtice@google.com
On Thu, Sep 18, 2014 at 3:23 PM, Patrick Wollgast
<patrick.wollgast@rub.de> wrote:
> Added Benjamin De Kosnik as a c++ runtime libs maintainer and Kai Tietz
> as Windows/Cygwin/MinGW maintainer.
>
>>> In changes to gcc/config/i386/cygwin.h mingw-w64.h and mingw32.h, you forgot to handle the "fvtable-verify=preinit" options. fvtable-veriy=preinit should cause vtv_start_preinit.o to be added to the STARTFILE_SPEC and vtv_end_preinit.o to be added to the ENDFILE_SPEC (as in gcc/config/gnu-user.h). I expect you will also need to add it to your LIB_SPEC definitions in those config files.
>>>
>
> Like discussed via email I set preinit=std. This required additional
> changes in gcc/cp/vtable-class-hierarchy.c.
>
>>> in libgcc/config.host, the indentation looks wrong on the line 660 (where you add the extra parts for vtable verification for the case "i[34567]86-*-mingw*)". It also looks wrong on line 709 (again, adding extra parts, for case "x86_64-*-mingw*)". The rest of the changes in that file look ok, but someone else will need to approve them.
>>>
>
> Indentation fixed.
>
>>> The changes in libgcc/Makefile.in and gcc/varasm.c look ok to me, but someone will will have to approve them since I don't have authority to approve changes there.
>>>
>>> in libstdc++-v3/libsupc++:
>>>
>>> Your change in Makefile.am looks ok to me; your changes in vtv_stubs.cc look ok, except that you appear to have messed up the indentations in the function headers (both for the declarations and the actual functions). Also there is a typo in your comment: 'build' should be 'built'. But content-wise, the change looks fine. Again, someone else will have to actually approve these changes since I do not have that authority.
>>>
>
> Typo and indentation fixed.
>
>>> in libstdc++-v3/src/Makefile.am also looks ok to me; someone else will have to give final approval.
>>>
>>>
>>> in libvtv/Makefile.am, you need to fix the indentation at line 64 (vtv_stubs.cc):
>>>
>>> vtv_stubs_sources = \
>>> vtv_start.c \
>>> vtv_stubs.cc \
>>> vtv_end.c
>>>
>
> Indentation fixed.
>
>>> the rest of the changes in that file look good.
>>>
>>> Why did you make a copy of obstack.c in libvtv rather than using the one in libiberty? It would be better not to make a second copy of the source file if that can be avoided...
>>>
>
> I removed obstack.c from libvtv and added the changes from
> libvtv/obstack.c to libiberty/obstack.c with #ifdefs.
>
>>> in libvtv/vtv_malloc.cc:
>>>
>>> lines 207-213: Fix the indentation on the second line of call to VirtualAlloc.
>>> #if defined (__CYGWIN__) || defined (__MINGW32__)
>>> if ((allocated = VirtualAlloc(NULL, size, MEM_RESERVE|MEM_COMMIT,
>>> PAGE_READWRITE)) == 0)
>>> #else
>>> if ((allocated = mmap (NULL, size, PROT_READ | PROT_WRITE,"
>>> MAP_PRIVATE | MAP_ANONYMOUS, -1, 0)) == 0)
>>> #endif
>>>
>>> Remove extra blank line at line 216.
>>>
>
> Line removed and indentation fixed.
>
>>> in libvtv/vtv_rts.cc:
>>>
>>> Your version of the function read_section_offset_and_length has several lines that exceed the 80 character limit; please fix that. Your function iterate_modules also has one or two lines that are too long, and it needs a function comment.
>>>
>
> Character per line are now correct and comment added.
>
>>> in libvtv/vtv_utils.cc:
>>>
>>> In the function __vtv_open_log, you seem to have the following code twice:
>>>
>>> #ifdef __MINGW32__
>>> mkdir (logs_prefix);
>>> #else
>>> mkdir (logs_prefix, S_IRWXU);
>>> #endif
>>>
>>> was there a reason for this, or is this an accident (in which case the second occurrence should be removed)?
>>>
>
> Should have been 'log_dir' instead of 'logs_prefix' the 2nd time. Fixed now.
>
> regards
> Patrick
next prev parent reply other threads:[~2014-09-23 6:16 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-28 11:04 Patrick Wollgast
2014-09-11 4:12 ` [Ping] " Patrick Wollgast
[not found] ` <CABtf2+RU7frwOXOX2FF8Tmfc6ssrpfFVj1Vuue4cZt19FpSWtQ@mail.gmail.com>
2014-09-12 22:44 ` Caroline Tice
2014-09-18 22:24 ` Patrick Wollgast
2014-09-23 6:16 ` Caroline Tice [this message]
2014-09-23 10:22 ` Jonathan Wakely
2014-09-24 22:25 ` Patrick Wollgast
2014-09-27 10:50 ` Kai Tietz
2014-10-09 13:56 ` Patrick Wollgast
2014-10-09 14:47 ` Kai Tietz
2014-10-16 10:23 ` Patrick Wollgast
2014-10-30 14:51 ` Patrick Wollgast
2014-11-12 16:23 ` Patrick Wollgast
2014-11-12 17:05 ` Kai Tietz
2014-11-12 17:47 ` Patrick Wollgast
2014-11-12 18:45 ` Kai Tietz
2014-11-27 9:59 ` Patrick Wollgast
2014-12-10 16:37 ` Patrick Wollgast
2015-01-04 20:10 ` Patrick Wollgast
2015-01-08 20:34 ` Patrick Wollgast
2015-01-12 18:32 ` Caroline Tice
2015-01-14 19:28 ` Ian Lance Taylor
2015-01-14 21:23 ` Patrick Wollgast
2015-01-14 23:56 ` Ian Lance Taylor
2015-01-15 8:34 ` Patrick Wollgast
2015-01-15 16:14 ` Ian Lance Taylor
2015-01-15 22:13 ` Patrick Wollgast
2015-01-28 14:04 ` Patrick Wollgast
2015-01-29 1:58 ` Caroline Tice
2015-01-29 18:16 ` Matthias Klose
2015-01-29 18:26 ` Matthias Klose
2015-01-29 18:28 ` Jonathan Wakely
2015-01-29 18:34 ` H.J. Lu
2015-01-29 18:59 ` H.J. Lu
2015-01-29 19:27 ` H.J. Lu
2015-01-29 18:30 ` H.J. Lu
2015-01-29 18:53 ` Matthias Klose
2015-01-29 19:39 ` Jakub Jelinek
2015-01-29 19:55 ` H.J. Lu
2015-01-29 20:01 ` Jakub Jelinek
2015-01-29 20:08 ` H.J. Lu
2015-01-29 19:28 ` Jakub Jelinek
2015-01-29 18:16 ` H.J. Lu
2015-01-29 18:22 ` H.J. Lu
2015-01-29 18:23 ` Caroline Tice
2015-02-09 12:32 ` Thomas Schwinge
2015-02-02 19:56 ` Patrick Wollgast
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='CABtf2+T0a=jCMXLTuVPuYp4ViY-cRK3RARRnQQUEhHyNRMWeNA@mail.gmail.com' \
--to=cmtice@google.com \
--cc=bkoz@gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=ktietz@redhat.com \
--cc=libstdc++@gcc.gnu.org \
--cc=patrick.wollgast@rub.de \
/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).