Menu
▾
▴
cegcc-devel — Discussion about CeGCC development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(63) |
Sep
(78) |
Oct
(111) |
Nov
(104) |
Dec
(39) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(69) |
Feb
(68) |
Mar
(23) |
Apr
(61) |
May
(56) |
Jun
(122) |
Jul
(82) |
Aug
(44) |
Sep
(63) |
Oct
(73) |
Nov
(77) |
Dec
(102) |
| 2008 |
Jan
(34) |
Feb
(51) |
Mar
(39) |
Apr
(43) |
May
(8) |
Jun
(59) |
Jul
(69) |
Aug
(97) |
Sep
(140) |
Oct
(72) |
Nov
(37) |
Dec
(35) |
| 2009 |
Jan
(70) |
Feb
(104) |
Mar
(42) |
Apr
(121) |
May
(161) |
Jun
(109) |
Jul
(90) |
Aug
(85) |
Sep
(104) |
Oct
(59) |
Nov
(76) |
Dec
(145) |
| 2010 |
Jan
(123) |
Feb
(45) |
Mar
(37) |
Apr
(9) |
May
|
Jun
(5) |
Jul
(22) |
Aug
|
Sep
(4) |
Oct
(5) |
Nov
(2) |
Dec
(83) |
| 2011 |
Jan
(19) |
Feb
(33) |
Mar
(14) |
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(8) |
Dec
(8) |
| 2012 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
|
May
(5) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Dave K. <dav...@go...> - 2010-01-31 16:09:29
|
On 31/01/2010 15:31, Pedro Alves wrote:
> On Sunday 31 January 2010 15:23:05, Dave Korn wrote:
>>> in t-wince-pe (or some other make fragment) ?
>>>
>>> I see that config/i386/t-mingw32 has:
>>>
>>> NATIVE_SYSTEM_HEADER_DIR = /mingw/include
>> Will that work in cross?
>
> Yes. Due to:
>
> configure.ac:
> CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
>
> I also saw:
> config/spu/t-spu-elf:19:NATIVE_SYSTEM_HEADER_DIR = /include
>
> There's no native spu-elf toolchain for sure, so this looks like
> some precedent.
Righto. I was a bit concerned about the comment about it having to match
SYSTEM_INCLUDE_DIR.
>> or possibly just run the
>> install-headers stage of it and force it to install to
>> $prefix/$target/sys-include.
>
> Right, that should work too, though the --with-headers pseudo-ugly
> option avoided needless copies of files in the end.
>
> I'm not sure what is the best approach.
Well, --with-headers is deprecated, and --with-sysroot is meant to be the
way to go these days, so I figure your patch is preferable if nothing untoward
crops up.
> I've just built a toolchain
> with the patches below. A bunch of files showed up on include-fixed,
> amonst which, there was a include-fixed/syslimits.h file.
I took a quick look at some of the other fixes that are getting applied, for
instance _mingw.h gets this:
@@ -242,7 +251,7 @@
#define __MINGW_ATTRIB_NONNULL(arg)
#endif /* GNUC >= 3.3 */
-#if defined(UNDER_CE) && defined(__arm__)
+#if defined(__UNDER_CE__) && defined(__arm__)
/* ARM Windows CE is not underscored. */
# define __U(SYM) _ ## SYM
# define __IMP(S) __imp_ ## S
... and many files (this is wininet.h) have changes relating to the unicode flag:
@@ -731,7 +740,7 @@ typedef struct {
DWORD dwFlags;
} INTERNET_CONNECTED_INFO, * LPINTERNET_CONNECTED_INFO;
-#ifdef UNICODE
+#ifdef __UNICODE__
typedef URL_COMPONENTSW URL_COMPONENTS;
typedef LPURL_COMPONENTSW LPURL_COMPONENTS;
typedef GOPHER_FIND_DATAW GOPHER_FIND_DATA;
Do those look sensible to you? There could conceivably be some knock-on
effect of having all the fixed headers for the first time.
cheers,
DaveK
|
|
From: Pedro A. <pe...@co...> - 2010-01-31 15:32:06
|
On Sunday 31 January 2010 15:23:05, Dave Korn wrote:
>
> > in t-wince-pe (or some other make fragment) ?
> >
> > I see that config/i386/t-mingw32 has:
> >
> > NATIVE_SYSTEM_HEADER_DIR = /mingw/include
>
> Will that work in cross?
Yes. Due to:
configure.ac:
CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
I also saw:
config/spu/t-spu-elf:19:NATIVE_SYSTEM_HEADER_DIR = /include
There's no native spu-elf toolchain for sure, so this looks like
some precedent.
> or possibly just run the
> install-headers stage of it and force it to install to
> $prefix/$target/sys-include.
Right, that should work too, though the --with-headers pseudo-ugly
option avoided needless copies of files in the end.
I'm not sure what is the best approach. I've just built a toolchain
with the patches below. A bunch of files showed up on include-fixed,
amonst which, there was a include-fixed/syslimits.h file.
Index: gcc/config/arm/t-wince-pe
===================================================================
--- gcc/config/arm/t-wince-pe (revision 1439)
+++ gcc/config/arm/t-wince-pe (working copy)
@@ -161,3 +161,5 @@ SHLIB_MKMAP = $(srcdir)/mkmap-flat.awk
# does not get substituted before mkmap-flat.awk is run.
SHLIB_MKMAP_OPTS = -v pe_dll=libgcc_s_$(EH_MODEL)-$(SHLIB_SOVERSION)$(SHLIB_EXT)
SHLIB_MAPFILES = $(srcdir)/libgcc-std.ver
+
+NATIVE_SYSTEM_HEADER_DIR = /include
Index: build-mingw32ce.sh
===================================================================
--- build-mingw32ce.sh (revision 1440)
+++ build-mingw32ce.sh (working copy)
@@ -192,6 +194,7 @@ build_binutils()
--host=${HOST} \
--target=${TARGET} \
--disable-nls \
+ --with-sysroot=${PREFIX}/${TARGET}/ \
--disable-werror
make ${PARALLELISM}
@@ -221,6 +224,7 @@ build_bootstrap_gcc()
--disable-shared \
--disable-interwork \
--without-newlib \
+ --without-headers \
--enable-checking || exit 1
case ${gcc_src} in
@@ -341,11 +345,11 @@ build_gcc()
--disable-interwork \
--without-newlib \
--enable-checking \
- --with-headers \
+ --with-sysroot=${PREFIX}/${TARGET}/ \
--disable-__cxa_atexit
;;
esac
-
+
# we build libstdc++ as dll, so we don't need this.
# --enable-fully-dynamic-string \
@@ -382,6 +386,7 @@ build_gdb()
--disable-win32-registry \
--disable-multilib \
--disable-interwork \
+ --with-sysroot=${PREFIX}/${TARGET}/ \
--enable-checking
export CFLAGS=${PREV_CFLAGS}
|
|
From: Dave K. <dav...@go...> - 2010-01-31 15:22:11
|
On 31/01/2010 14:43, Dave Korn wrote:
> Doh. I'll try --with-headers/--with-libs instead.
So, adding "--with-headers=$prefix/arm-mingw32ce/include
--with-libs=$prefix/arm-mingw32ce/lib" to the configure line for the main gcc
build gets me an installation with lots of new fixed headers in the
include-fixed dir, among which we have a limits.h with the correct header and
trailer. Preinstalling headers to $prefix/$target/sys-include would probably
do the exact same thing but seems like needless duplication. And I don't
think the --with-libs was even necessary at all from the looks of it.
I'll try a full clean build with nothing preinstalled and this patch:
Index: build-mingw32ce.sh
===================================================================
--- build-mingw32ce.sh (revision 1440)
+++ build-mingw32ce.sh (working copy)
@@ -341,6 +341,7 @@ build_gcc()
--disable-interwork \
--without-newlib \
--enable-checking \
+ --with-headers=${PREFIX}/${TARGET}/include \
--with-headers \
--disable-__cxa_atexit
;;
cheers,
DaveK
|
|
From: Dave K. <dav...@go...> - 2010-01-31 15:05:57
|
On 31/01/2010 14:48, Pedro Alves wrote:
> On Sunday 31 January 2010 14:43:06, Dave Korn wrote:
>>> The directory that should contain system headers does not exist:
>>> /opt/mingw32ce/arm-mingw32ce/usr/include
>
> Hmm, or:
>
> NATIVE_SYSTEM_HEADER_DIR = /include
>
> in t-wince-pe (or some other make fragment) ?
>
> I see that config/i386/t-mingw32 has:
>
> NATIVE_SYSTEM_HEADER_DIR = /mingw/include
Will that work in cross?
> I'm guessing a cross build of upstream MinGW is putting
> headers in $(tooldir)/mingw/include then. I never looked
> at their build scripts.
>
> I don't know if we'd have to do something for libs. If so,
> how does one tell gcc that?
Don't think we can, but then again, gcc doesn't really do anything with the
libraries except copy them around. We may need to fix the mingw stage of the
build script to prepare a proper sysroot, or possibly just run the
install-headers stage of it and force it to install to
$prefix/$target/sys-include.
cheers,
DaveK
|
|
From: Pedro A. <pe...@co...> - 2010-01-31 14:55:21
|
On Sunday 31 January 2010 14:43:06, Dave Korn wrote: > > The directory that should contain system headers does not exist: > > /opt/mingw32ce/arm-mingw32ce/usr/include Hmm, or: NATIVE_SYSTEM_HEADER_DIR = /include in t-wince-pe (or some other make fragment) ? I see that config/i386/t-mingw32 has: NATIVE_SYSTEM_HEADER_DIR = /mingw/include I'm guessing a cross build of upstream MinGW is putting headers in $(tooldir)/mingw/include then. I never looked at their build scripts. I don't know if we'd have to do something for libs. If so, how does one tell gcc that? -- Pedro Alves |
|
From: Dave K. <dav...@go...> - 2010-01-31 14:25:55
|
On 31/01/2010 14:27, Dave Korn wrote:
> On 31/01/2010 12:54, Pedro Alves wrote:
>> I think we should be building gcc with `--with-sysroot=${PREFIX}/arm-mingw32ce/'
>
> Just testing that in a non-bootstrap build of gcc only.
Hmm, it's not quite that directly simple:
> The directory that should contain system headers does not exist:
> /opt/mingw32ce/arm-mingw32ce/usr/include
Doh. I'll try --with-headers/--with-libs instead.
cheers,
DaveK
|
|
From: Dave K. <dav...@go...> - 2010-01-31 14:17:09
|
On 31/01/2010 14:15, Sébastien Lorquet wrote: > Many thanks. > > Do I need to file something at http://sourceware.org/bugzilla/ ? Not for now. cheers, DaveK |
|
From: Sébastien L. <sq...@gm...> - 2010-01-31 14:15:50
|
Many thanks. Do I need to file something at http://sourceware.org/bugzilla/ ? Regards Sebastien On Sun, Jan 31, 2010 at 1:22 PM, Dave Korn <dav...@go...>wrote: > On 31/01/2010 11:32, Sébastien Lorquet wrote: > > > Should I report this to upstream? > > You just did :) > > > who can handle that? > > Looks like a job for me. I'll update my cegcc and figure out what's going > on. > > cheers, > DaveK > |
|
From: Dave K. <dav...@go...> - 2010-01-31 14:10:26
|
On 31/01/2010 12:54, Pedro Alves wrote:
> On Sunday 31 January 2010 12:32:21, Dave Korn wrote:
>> I don't think it should be necessary to patch the build system, since it's
>> already capable of doing the right thing (which is to create the private
>> header and fixed syslimits), we need to understand why it isn't doing that.
>>
>
> My guess is that with the options we're building gcc,
> gcc isn't looking at ($tooldir)/includes for fixincludable headers, but
> at ($tooldir)/sys-includes. So it just installs its own limits.h as if
> the system doesn't have one already.
Yep, you can see it happening by cd'ing into the gcc/gcc/ build dir and
running "rm stmp-* ; make": it happens here -
> set -e; for ml in `cat fixinc_list`; do \
> sysroot_headers_suffix=`echo ${ml} | sed -e 's/;.*$//'`; \
> multi_dir=`echo ${ml} | sed -e 's/^[^;]*;//'`; \
> fix_dir=include-fixed${multi_dir}; \
> if [ -f `echo /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/sys-include | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`/limits.h ] ; then \
This if fails
> cat /tmp/cegcc/cegcc/trunk/cegcc/src/gcc-4.4.0/gcc/limitx.h /tmp/cegcc/cegcc/trunk/cegcc/src/gcc-4.4.0/gcc/glimits.h /tmp/cegcc/cegcc/trunk/cegcc/src/gcc-4.4.0/gcc/limity.h > tmp-xlimits.h; \
> else \
> cat /tmp/cegcc/cegcc/trunk/cegcc/src/gcc-4.4.0/gcc/glimits.h > tmp-xlimits.h; \
.. so we use the default template.
> fi; \
> /bin/sh /tmp/cegcc/cegcc/trunk/cegcc/src/gcc-4.4.0/gcc/../mkinstalldirs ${fix_dir}; \
> chmod a+rx ${fix_dir} || true; \
> rm -f ${fix_dir}/limits.h; \
> mv tmp-xlimits.h ${fix_dir}/limits.h; \
> chmod a+r ${fix_dir}/limits.h; \
> done
> rm -f include-fixed/README
> cp /tmp/cegcc/cegcc/trunk/cegcc/src/gcc-4.4.0/gcc/../fixincludes/README-fixinc include-fixed/README
> chmod a+r include-fixed/README
> echo timestamp > stmp-int-hdrs
> I think we should be building gcc with `--with-sysroot=${PREFIX}/arm-mingw32ce/'
Just testing that in a non-bootstrap build of gcc only.
> Might work to pass --with-headers=($tooldir)/includes to gcc too, but that
> feels hackish.
Yeh, don't like the look of that!
> Oh, and the bootstrap gcc's headers get installed at the same
> place as the final gcc. If the bootstrap gcc installs headers
> the final gcc doesn't, we end up with stale headers installed.
> We should be installing the bootstrap compiler in a staged
> dir (or better, everything)..
Yep, it would be a good idea to install the bootstrap compiler to a DESTDIR
and then discard it altogether once it's been used. (However given that the
bootstrap and final gcc are configured so similarly, I'm not sure whether any
problems will actually have been arising in practice.)
cheers,
DaveK
|
|
From: Dave K. <dav...@go...> - 2010-01-31 13:54:22
|
On 31/01/2010 12:50, Danny Backx wrote:
> Was it really that hard to wait for confirmation of another solution ?
Err, exactly the same could be said to you about the prematurity of your
patch in the first place; you haven't analyzed the problem and understood what
is going wrong yet. Pedro's analysis of the configure options and the problem
with the bootstrap headers looks pretty likely correct to me.
cheers,
DaveK
|
|
From: Danny B. <dan...@sc...> - 2010-01-31 13:17:55
|
On Sun, 2010-01-31 at 11:50 +0000, ped...@us... wrote: > Revision: 1440 > http://cegcc.svn.sourceforge.net/cegcc/?rev=1440&view=rev > Author: pedroalves > Date: 2010-01-31 11:50:54 +0000 (Sun, 31 Jan 2010) > > Log Message: > ----------- > Revert previous change. > > Modified Paths: > -------------- > trunk/cegcc/src/scripts/ChangeLog > trunk/cegcc/src/scripts/build-cegcc.sh > trunk/cegcc/src/scripts/build-mingw32ce.sh > trunk/cegcc/src/scripts/build-x86.sh Was it really that hard to wait for confirmation of another solution ? Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info |
|
From: Dave K. <dav...@go...> - 2010-01-31 13:16:03
|
On 31/01/2010 10:11, Danny Backx wrote:
> On Sat, 2010-01-30 at 18:58 +0000, Dave Korn wrote:
>> It goes on to suggest that it might be necessary to define "LIMITS_H_TEST =
>> true" in the t-* makefile frag, so if you guys don't get syslimits.h being
>> generated, maybe that would fix it for you too?
> so all it appears to influence is whether glimits.h is surrounded by
> limitx.h and limity.h or not.
Ah, so it does.
> What we need here is no limits.h coming from gcc because it already
> comes from our src/mingw/include .
I'm fairly sure GCC *requires* its private internal version of limits.h for
correct operation, and that what you want is limits.h and syslimits.h.
> Inspired on all that, how does the patch attached look ?
> It should be the more fundamental take on the problem.
I don't think it should be necessary to patch the build system, since it's
already capable of doing the right thing (which is to create the private
header and fixed syslimits), we need to understand why it isn't doing that.
As I mentioned in another post, I'm updating my cegcc. I'll take a look at
what happens during the build.
cheers,
DaveK
|
|
From: Pedro A. <pe...@co...> - 2010-01-31 13:05:35
|
On Saturday 30 January 2010 17:48:45, Pedro Alves wrote: > On Saturday 30 January 2010 11:35:45, Danny Backx wrote: > > So the next best thing appears to just remove it in the > > scripts/build-mingw32ce.h . > > I just committed such a fix, can you verify ? > > Please don't. Please revert. If there's a real > problem here, I'm sure it has a proper fix. Let's not get > into the habbit of committing quick workarounds for not > understood problems. I've reverted the scripts change in svn myself. (after wanting to look at the limits.h gcc is installed, but somehow forgetting about the hack, and building a pristine head toolchain, which of course, wipes the file. Duh. Starting over...) -- Pedro Alves |
|
From: Pedro A. <pe...@co...> - 2010-01-31 13:01:17
|
On Sunday 31 January 2010 12:32:21, Dave Korn wrote:
> I don't think it should be necessary to patch the build system, since it's
> already capable of doing the right thing (which is to create the private
> header and fixed syslimits), we need to understand why it isn't doing that.
>
My guess is that with the options we're building gcc,
gcc isn't looking at ($tooldir)/includes for fixincludable headers, but
at ($tooldir)/sys-includes. So it just installs its own limits.h as if
the system doesn't have one already.
I think we should be building gcc with `--with-sysroot=${PREFIX}/arm-mingw32ce/'
Might work to pass --with-headers=($tooldir)/includes to gcc too, but that
feels hackish.
Oh, and the bootstrap gcc's headers get installed at the same
place as the final gcc. If the bootstrap gcc installs headers
the final gcc doesn't, we end up with stale headers installed.
We should be installing the bootstrap compiler in a staged
dir (or better, everything)..
--
Pedro Alves
|
|
From: Dave K. <dav...@go...> - 2010-01-31 12:04:59
|
On 31/01/2010 11:32, Sébastien Lorquet wrote:
> Should I report this to upstream?
You just did :)
> who can handle that?
Looks like a job for me. I'll update my cegcc and figure out what's going on.
cheers,
DaveK
|
|
From: Sébastien L. <sq...@gm...> - 2010-01-31 11:32:54
|
(previous mail was only sent to Pedro. I include the previous mail, where I
found that the segfault is in ld, not in collect2.
Some progress.
According to the code, the incriminated lines are:
/* Flag that this BFD uses long names, even though the format might
expect them to be off by default. This won't directly affect the
format of any output BFD created from this one, but the information
can be used to decide what to do. */
bfd_coff_set_long_section_names (abfd, TRUE);
memcpy (buf, hdr->s_name + 1, SCNNMLEN - 1);
buf[SCNNMLEN - 1] = '\0';
strindex = strtol (buf, &p, 10);
if (*p == '\0' && strindex >= 0)
{
strings = _bfd_coff_read_string_table (abfd);
if (strings == NULL)
return FALSE;
* /* FIXME: For extra safety, we should make sure that
strindex does not run us past the end, but right now we
don't know the length of the string table. */
* strings += strindex;
name = (char *) bfd_alloc (abfd,
(bfd_size_type) *strlen (strings)* +
1);
if (name == NULL)
return FALSE;
strcpy (name, strings);
}
playing with GDB I find that:
$3 = 8976241
(gdb) print strings
$4 = 0xacf3e1 <Address 0xacf3e1 out of bounds>
(gdb) print (strings-strindex)
$5 = 0x23fc70 "\r\255\272.debug_abbrev"
(gdb) print buf
$6 = "8976241"
(gdb) print abfd
$7 = (bfd *) 0x23fb00
(gdb) print hdr
$9 = (struct internal_scnhdr *) 0xfaf364
(gdb) print *hdr
$10 = {s_name = "/8976241", s_paddr = 0, s_vaddr = 0, s_size = 145, s_scnptr
= 572, s_relptr = 0, s_lnnoptr = 0, s_nreloc = 0, s_nlnno = 0, s_flags =
1108344832, s_align = 21807152, s_page = 20 '\024'}
(gdb) print target_index
$11 = 4
(gdb) print flags
$12 = 1
(gdb)
I don't know why the heck this happens, but the address out of bounds I get
seems related to this FIXME .
What do you think?
Should I report this to upstream? who can handle that? mingw gurus? "vanilla
binutils" gurus?
It does not happen on linux.
Sebastien
On Sat, Jan 30, 2010 at 9:55 PM, Sébastien Lorquet <sq...@gm...>wrote:
> You're right. I was too sleepy to notice that.
>
> Now I get the sigsegv:
>
> C:\MinGW>c:/mingw/cross41-debug/bin/../libexec/gcc/arm-mingw32ce/4.1.0/collect2.exe
> -v -Bdynamic -o test.exe c:/mingw/cross41-debug/bin/../lib/gcc/arm-mingw32ce
>
> /4.1.0/../../../../arm-mingw32ce/lib/crt3.o
> -Lc:/mingw/cross41-debug/bin/../lib/gcc/arm-mingw32ce/4.1.0
> -Lc:/mingw/cross41-debug/bin/../lib/gcc -Lc:/mingw/cross
> 41-debug/bin/../lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib
> C:\DOCUME~1\squalyl\LOCALS~1\Temp/ccfo5YRa.o -lmingw32 -lgcc -lceoldname
> -lmingwex -lc
>
> oredll -lcoredll -lmingw32 -lgcc -lceoldname -lmingwex -lcoredll
> collect2 version 4.1.0 (arm MinGW)
> c:\MinGW\cross41-debug\bin/arm-mingw32ce-ld.exe -v -Bdynamic -o test.exe
> c:/mingw/cross41-debug/bin/../lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib
> /crt3.o -Lc:/mingw/cross41-debug/bin/../lib/gcc/arm-mingw32ce/4.1.0
> -Lc:/mingw/cross41-debug/bin/../lib/gcc
> -Lc:/mingw/cross41-debug/bin/../lib/gcc/arm-mingw32c
> e/4.1.0/../../../../arm-mingw32ce/lib
> C:\DOCUME~1\squalyl\LOCALS~1\Temp/ccfo5YRa.o -lmingw32 -lgcc -lceoldname
> -lmingwex -lcoredll -lcoredll -lmingw32 -lgcc -lc
> eoldname -lmingwex -lcoredll
>
> collect2: ld returned 5 exit status
>
> C:\MinGW>gdb c:\MinGW\cross41-debug\bin/arm-mingw32ce-ld.exe
> 'gdb' n'est pas reconnu en tant que commande interne
> ou externe, un programme exécutable ou un fichier de commandes.
>
> C:\MinGW>gcc3\bin\gdb c:\MinGW\cross41-debug\bin/arm-mingw32ce-ld.exe
> GNU gdb (GDB) 7.0.1
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "mingw32".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from
> c:\MinGW\cross41-debug\bin/arm-mingw32ce-ld.exe...done.
> < C:\DOCUME~1\squalyl\LOCALS~1\Temp/ccfo5YRa.o -lmingw32 -lgcc -lceoldname
> -lmingwex -lcoredll -lcoredll -lmingw32 -lgcc -lceoldname -lmingwex
> -lcoredll
> Starting program: c:\MinGW\cross41-debug\bin/arm-mingw32ce-ld.exe -v
> -Bdynamic -o test.exe
> c:/mingw/cross41-debug/bin/../lib/gcc/arm-mingw32ce/4.1.0/../../../..
> /arm-mingw32ce/lib/crt3.o
> -Lc:/mingw/cross41-debug/bin/../lib/gcc/arm-mingw32ce/4.1.0
> -Lc:/mingw/cross41-debug/bin/../lib/gcc -Lc:/mingw/cross41-debug/bin/../li
> b/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib
> C:\DOCUME~1\squalyl\LOCALS~1\Temp/ccfo5YRa.o -lmingw32 -lgcc -lceoldname
> -lmingwex -lcoredll -lcoredll -
>
> lmingw32 -lgcc -lceoldname -lmingwex -lcoredll
> [New Thread 556.0xe48]
> GNU ld (GNU Binutils) 2.20.51.20091016
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x77c178ac in strlen () from C:\WINDOWS\system32\msvcrt.dll
> (gdb) bt
> #0 0x77c178ac in strlen () from C:\WINDOWS\system32\msvcrt.dll
> #1 0x00437f78 in make_a_section_from_file (abfd=0x23fb00, hdr=0xfaf364,
> target_index=4) at
> /home/squalyl/projects/cegcc/src/binutils/bfd/coffgen.c:93
> Backtrace stopped: frame did not save the PC
> (gdb) list
> 177 /home/squalyl/projects/cegcc/src/binutils/ld/ldmain.c: No such file
> or directory.
> in /home/squalyl/projects/cegcc/src/binutils/ld/ldmain.c
> (gdb)
>
>
>
|
|
From: Danny B. <dan...@sc...> - 2010-01-31 10:10:57
|
On Sat, 2010-01-30 at 18:58 +0000, Dave Korn wrote:
> It goes on to suggest that it might be necessary to define "LIMITS_H_TEST =
> true" in the t-* makefile frag, so if you guys don't get syslimits.h being
> generated, maybe that would fix it for you too?
I must admit I didn't know I could set that variable in the t-* file.
But I think it does the wrong thing, it appears to override only the
test in the generated cegcc/src/build-mingw32ce/gcc/gcc/Makefile :
if $(LIMITS_H_TEST) ; then \
cat $(srcdir)/limitx.h $(srcdir)/glimits.h
$(srcdir)/limity.h > tmp-xlimits.h; \
else \
cat $(srcdir)/glimits.h > tmp-xlimits.h; \
fi; \
$(mkinstalldirs) $${fix_dir}; \
chmod a+rx $${fix_dir} || true; \
rm -f $${fix_dir}/limits.h; \
mv tmp-xlimits.h $${fix_dir}/limits.h; \
chmod a+r $${fix_dir}/limits.h; \
so all it appears to influence is whether glimits.h is surrounded by
limitx.h and limity.h or not.
What we need here is no limits.h coming from gcc because it already
comes from our src/mingw/include .
Inspired on all that, how does the patch attached look ?
It should be the more fundamental take on the problem.
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
|
|
From: Pedro A. <pe...@co...> - 2010-01-30 19:00:54
|
On Saturday 30 January 2010 18:39:25, Vincent Torri wrote: > Pedro, if you have, once, untar the ported package, you should have > remarked that i provide the dll, and they are stripped (see README > file...). Pasting the relevant bits of the file in the email body goes a long way torwards making it much easier for people to actually read it, and so greatly increases the chances of actually getting people to provide input. Requiring a download, untar, and opening the file, and then quote it on replies is just bloat in the process, which kills people's time. I'll try to get to it if you don't paste the file for some reason, but not now. -- Pedro Alves |
|
From: Dave K. <dav...@go...> - 2010-01-30 18:46:52
|
On 30/01/2010 17:52, Pedro Alves wrote:
> There's no reason to copy a dll with debug info to
> the device. You can copy a stripped version, and keep
> the version with debug info in the host.
>
> Of course, if you want to provide a prebuilt dll with
> debug info to users, you can also provide an
> already pre-stripped dll.
Another option: supply a stripped DLL and a separate .DBG, which the DLL
refers to in a .GNU.debuglink section - see the objcopy options
'--only-keep-debug' and '--add-gnu-debuglink=PATH-TO-FILE'. That way you only
have one DLL to worry about.
cheers,
DaveK
|
|
From: Dave K. <dav...@go...> - 2010-01-30 18:41:26
|
On 30/01/2010 17:48, Pedro Alves wrote: > Doesn't the gcc version include_next the mingw one? Is there > actually a problem you're seeing? GCC has its own private version, which is supposed to include a private fixed version of the system's original header: http://gcc.gnu.org/ml/gcc/2004-01/msg01706.html > If there is a system limits.h, then the limits.h which gcc installs > should have the line > #include "syslimits.h" > > That file should either be the fixed version of <limits.h> installed > by fixincludes, or, if <limits.h> does not need to be fixed, it should > have the line > #include_next <limits.h> It goes on to suggest that it might be necessary to define "LIMITS_H_TEST = true" in the t-* makefile frag, so if you guys don't get syslimits.h being generated, maybe that would fix it for you too? cheers, DaveK |
|
From: Vincent T. <vt...@un...> - 2010-01-30 18:39:32
|
On Sat, 30 Jan 2010, Pedro Alves wrote: > On Saturday 30 January 2010 17:41:41, Vincent Torri wrote: >> >> On Sat, 30 Jan 2010, Pedro Alves wrote: >> >>> On Saturday 30 January 2010 07:13:55, Vincent Torri wrote: >>> >>>> -g is not an option. The dll would be too big. The fact that a dll takes >>>> in memory a multiple of 64KB is already a problem. >>> >>> ??? The data -g puts in the dll doesn't contribute a single byte >>> to what the dll takes in memory. >> >> ok, but runtime startup is a lot bigger > > What's runtime startup? time spent during startup. Sorry > > There's no reason to copy a dll with debug info to > the device. You can copy a stripped version, and keep > the version with debug info in the host. > > Of course, if you want to provide a prebuilt dll with > debug info to users, you can also provide an > already pre-stripped dll. Ok, i restart : 1) Can people read the README file of the current packages to see if the flags are good or not, useless or not, etc... ? 2) Can people tell me which flags i should use to optimize the built for speed ? Pedro, if you have, once, untar the ported package, you should have remarked that i provide the dll, and they are stripped (see README file...). thank you Vincent Torri |
|
From: Pedro A. <pe...@co...> - 2010-01-30 17:52:24
|
On Saturday 30 January 2010 17:41:41, Vincent Torri wrote: > > On Sat, 30 Jan 2010, Pedro Alves wrote: > > > On Saturday 30 January 2010 07:13:55, Vincent Torri wrote: > > > >> -g is not an option. The dll would be too big. The fact that a dll takes > >> in memory a multiple of 64KB is already a problem. > > > > ??? The data -g puts in the dll doesn't contribute a single byte > > to what the dll takes in memory. > > ok, but runtime startup is a lot bigger What's runtime startup? There's no reason to copy a dll with debug info to the device. You can copy a stripped version, and keep the version with debug info in the host. Of course, if you want to provide a prebuilt dll with debug info to users, you can also provide an already pre-stripped dll. -- Pedro Alves |
|
From: Pedro A. <pe...@co...> - 2010-01-30 17:48:45
|
On Saturday 30 January 2010 11:35:45, Danny Backx wrote: > On Fri, 2010-01-29 at 18:47 +0100, Vincent Torri wrote: > > > > On Fri, 29 Jan 2010, Danny Backx wrote: > > > > > On Sat, 2010-01-23 at 13:33 +0100, Vincent Torri wrote: > > >> i've just installed cegcc (mingw32ce compiler) from the svn repo. There is > > >> a limits.h in the folowin sub directories: > > >> > > >> /home/torri/local/opt/mingw32ce/arm-mingw32ce/include/c++/4.4.0/tr1/ > > >> /home/torri/local/opt/mingw32ce/arm-mingw32ce/include/ > > >> /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/ > > >> /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/install-tools/include/ > > >> > > >> When i include limits.h, it is the one in the third directory that is > > >> chosen, and not the one in the second (which, i think, is the correct > > >> one). Is it normal ? Doesn't the gcc version include_next the mingw one? Is there actually a problem you're seeing? > I reread your original message again after a full reinstall on my > system. The full reinstall made the fourth limits.h - the one you're > mentioning - turn up again. > > So I must have removed it locally because of an issue with it, and > forgotten all about it :-) > > I just spent a while figuring out why this file is getting installed. In > the gcc build system, this appears to be hardcoded, so not something I > can work around easily without upsetting the gcc folks. > So the next best thing appears to just remove it in the > scripts/build-mingw32ce.h . > I just committed such a fix, can you verify ? Please don't. Please revert. If there's a real problem here, I'm sure it has a proper fix. Let's not get into the habbit of committing quick workarounds for not understood problems. -- Pedro Alves |
|
From: Vincent T. <vt...@un...> - 2010-01-30 17:41:54
|
On Sat, 30 Jan 2010, Pedro Alves wrote: > On Saturday 30 January 2010 07:13:55, Vincent Torri wrote: > >> -g is not an option. The dll would be too big. The fact that a dll takes >> in memory a multiple of 64KB is already a problem. > > ??? The data -g puts in the dll doesn't contribute a single byte > to what the dll takes in memory. ok, but runtime startup is a lot bigger Vincent Torri |
|
From: Pedro A. <pe...@co...> - 2010-01-30 17:35:17
|
On Friday 29 January 2010 22:01:09, Sébastien Lorquet wrote: > but... Why?! I didn't look closely, but, it sounds like you're debugging the wrong binary --- it looks like you want to debug ld, not collect2. Rerun the collect2 command line with -v, and that will show you the ld invocation. -- Pedro Alves |
15 messages has been excluded from this view by a project administrator.
