On Thu, Oct 11, 2012 at 8:43 AM, Matthias Hartmann
<matthias.w.hartm...@gmail.com> wrote:
> Peter,
>
> starting with 20bit development I have problems to build for mingw32
> (windows).
>
> Build is OK, but immediately msp430-gcc crashes with a segmentation fault.
>
> Some analysis (see below) brought me to the point that
> if (targetm.cpp_builtin_define_type_minmax (min_macro, max_macro, type))
> return;
> in c-cppbuiltin.c is not working correctly when build for mingw32.
> In deed, targetm.cpp_builtin_define_type_minmax does not contain the
> address of msp430_cpp_builtin_define_type_minmax.
Then this is probably a problem with mspgcc, since I added that call
and return in order to support 20-bit code. I'll look into whether
it's working right at all, and what the best fix is. Thanks for
tracking it down this far.
Peter
> I tried several versions of mingw, gcc, binutils on different
> platforms, always the same result.
>
> So I implemented a very dirty fix in builtin_define_type_minmax in
> file c-cppbuiltin.c.
> if ( targetm.cpp_builtin_define_type_minmax != &
> msp430_cpp_builtin_define_type_minmax ) {
> fprintf (stderr,"***FIX***: targetm.cpp_builtin_define_type_minmax
> = & msp430_cpp_builtin_define_type_minmax\n");
> fprintf (stderr,"&msp430_cpp_builtin_define_type_minmax = %#p\n",
> & msp430_cpp_builtin_define_type_minmax);
> fprintf (stderr,"targetm.cpp_builtin_define_type_minmax = %#p\n",
> targetm.cpp_builtin_define_type_minmax);
> targetm.cpp_builtin_define_type_minmax = &
> msp430_cpp_builtin_define_type_minmax;
> }
>
> And moved the prototype of msp430_cpp_builtin_define_type_minmax from
> msp430.c to msp430-protos.c.
>
> I don't really know what is going on there, but maybe something with
> weak symbols and the linker linking cc1.exe.
> The differences in the link command between a build for linux and
> mingw (best viewed with a fixed width font):
> MINGW UBUNTU
> i686-w64-mingw32-gcc gcc
> -g -g
> -O2 -O2
> -D__USE_MINGW_ACCESS
> -DIN_GCC -DIN_GCC
> -DCROSS_DIRECTORY_STRUCTURE
> -DCROSS_DIRECTORY_STRUCTURE
> -W -W
> -Wall -Wall
> -Wno-narrowing
> -Wwrite-strings -Wwrite-strings
> -Wcast-qual -Wcast-qual
> -Wstrict-prototypes
> -Wstrict-prototypes
> -Wmissing-prototypes
> -Wmissing-prototypes
> -Wmissing-format-attribute
> -Wmissing-format-attribute
> -pedantic -pedantic
> -Wno-long-long -Wno-long-long
> -Wno-variadic-macros
> -Wno-variadic-macros
> -Wno-overlength-strings
> -Wno-overlength-strings
> -Wold-style-definition
> -Wold-style-definition
> -Wc++-compat -Wc++-compat
> -fno-common -fno-common
> -DHAVE_CONFIG_H -DHAVE_CONFIG_H
> -Wl,--stack,12582912
> -o cc1.exe -o cc1
> c-lang.o c-lang.o
> c-family/stub-objc.o
> c-family/stub-objc.o
> attribs.o attribs.o
> c-errors.o c-errors.o
> c-decl.o c-decl.o
> c-typeck.o c-typeck.o
> c-convert.o c-convert.o
> c-aux-info.o c-aux-info.o
> c-objc-common.o c-objc-common.o
> c-parser.o c-parser.o
> tree-mudflap.o tree-mudflap.o
> c-family/c-common.o
> c-family/c-common.o
> c-family/c-cppbuiltin.o
> c-family/c-cppbuiltin.o
> c-family/c-dump.o
> c-family/c-dump.o
> c-family/c-format.o
> c-family/c-format.o
> c-family/c-gimplify.o
> c-family/c-gimplify.o
> c-family/c-lex.o
> c-family/c-lex.o
> c-family/c-omp.o
> c-family/c-omp.o
> c-family/c-opts.o
> c-family/c-opts.o
> c-family/c-pch.o
> c-family/c-pch.o
> c-family/c-ppoutput.o
> c-family/c-ppoutput.o
> c-family/c-pragma.o
> c-family/c-pragma.o
> c-family/c-pretty-print.o
> c-family/c-pretty-print.o
> c-family/c-semantics.o
> c-family/c-semantics.o
> c-family/c-ada-spec.o
> c-family/c-ada-spec.o
> msp430-c.o msp430-c.o
> default-c.o default-c.o
> cc1-checksum.o cc1-checksum.o
> main.o main.o
> tree-browser.o tree-browser.o
> libbackend.a libbackend.a
> libcommon-target.a
> libcommon-target.a
> libcommon.a libcommon.a
> ../libcpp/libcpp.a
> ../libcpp/libcpp.a
> ../libdecnumber/libdecnumber.a
> ../libdecnumber/libdecnumber.a
> libcommon.a libcommon.a
> ../libcpp/libcpp.a
> ../libcpp/libcpp.a
> ../libiberty/libiberty.a
> ../libiberty/libiberty.a
> ../libdecnumber/libdecnumber.a
> ../libdecnumber/libdecnumber.a
> -L/root/mspgcc-20120911/BUILD/gcc/./gmp/.libs
> -L/root/mspgcc-20120911/BUILD/gcc/./gmp/.libs
> -L/root/mspgcc-20120911/BUILD/gcc/./mpfr/.libs
> -L/root/mspgcc-20120911/BUILD/gcc/./mpfr/.libs
> -L/root/mspgcc-20120911/BUILD/gcc/./mpc/src/.libs
> -L/root/mspgcc-20120911/BUILD/gcc/./mpc/src/.libs
> -lmpc -lmpc
> -lmpfr -lmpfr
> -lgmp -lgmp
> -rdynamic
> -ldl
> -L../zlib -L../zlib
> -lz -lz
>
> I guess, that the missing "-rdynamic -ldl" may cause the problem, but
> just guessing.
>
> Do you or any body else have any idea how do fix that in a clean way?
>
> Would be fine to have working mingw builds for windows in the future.
>
> Best
>
> Matthias
>
>
>
>
> 2012/10/9 Przemek Klosowski <przemek.klosow...@gmail.com>:
>> On Mon, Oct 8, 2012 at 5:14 PM, Matthias Hartmann
>> <matthias.w.hartm...@gmail.com> wrote:
>>> Did investigate some more.
>>>
>>> error happens in cc1.exe.
>>> compiled a version of cc1.exe with -ggdb and -O0 and run it via gdb
>>> with a simple test program
>> ...
>>> GNU C (GCC) version 4.7.0 20120322 (mspgcc dev 20120911) (msp430)
>> ...
>>> Program received signal SIGSEGV, Segmentation fault.
>> ...
>>> #4 0x00b8050c in __mingw_vsprintf (buf=buf@entry=0x0,
>>> fmt=fmt@entry=0xbce560 "%s=%s%s", argv=argv@entry=0x56efd88
>>> "αß│\005_EXCEPTIONS__ 1\nwƒ¡") at
>>> ../../mingw/mingwex/stdio/vsprintf.c:62
>>> #5 0x004bf81f in sprintf (__stream=0x0, __format=0xbce560 "%s=%s%s",
>>> __format=0xbce560 "%s=%s%s") at
>>> /opt/mxe/usr/lib/gcc/i686-pc-mingw32/4.7.1/../../../../i686-pc-mingw32/include/stdio.h:266
>>> #6 0x0049a2c0 in builtin_define_type_minmax
>>> (min_macro=min_macro@entry=0x0, max_macro=max_macro@entry=0xbc0f20
>>> "__SCHAR_MAX__", type=0x5b3e1e0)
>>> at ../../../gcc-4.7.0/gcc/c-family/c-cppbuiltin.c:1214
>>
>>
>> sprintf outputs to a buffer in memory, so 0x0 (NULL) is not a good
>> value there, and will SEGV. I don't understand the stack layup above
>> this call, though.
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
