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 cmt...@google.com On Thu, Sep 18, 2014 at 3:23 PM, Patrick Wollgast <patrick.wollg...@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
