Quantcast

arm-mingw32ce-gcc -g makes ld fail in mingw

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

arm-mingw32ce-gcc -g makes ld fail in mingw

Sébastien Lorquet
Hi,

I my quest trying to get a working mingw32ce version under win32 mingw (is someone interested by my (trivial) changes to the build-mingw32ce.sh script?) I had a small problem.

I noticed that any program compiled with -g makes LD fail with a win32 exception dialog. The exception code is 0xC0...05 which I believe is a segfault or null pointer access tentative. The faulting AppName is ld.exe and the faulting ModName is msvcrt.dll.

The latest toolchain, that produces the bug, is at: http://www.unsads.com/~squalyl/cegcc/mingw32ce-4.1-20100125.zip

Simplest test case:

#include <windows.h>
int APIENTRY WinMain(HINSTANCE inInstance, HINSTANCE inPrevInst, LPWSTR inCmdLine, int inCmdShow)
{
    MessageBoxW(NULL, L"hello", L"hello", MB_ICONINFORMATION);
    return 0;
}

compiles fine under linux with both
arm-mingw32ce-gcc test.c -o test.exe
and
arm-mingw32ce-gcc -g test.c -o test.exe

But with my toolchain, cross compiled from linux to mingw32msvc, the second line fails.

How can I use ./configure magic to generate a toolchain compiled with -g so that I can run it under gdb and provide a stack trace?

Apart from that, the toolchain is quite comfortable to use, for example with code::blocks. What could prevent it from being an official build?

I did not try gcc 4.4. Is this code stable enough to build from the current svn? I'll try that tomorrow.

Regards
Sebastien

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: arm-mingw32ce-gcc -g makes ld fail in mingw

Sébastien Lorquet
Hi,

Really , no one has a clue about this?

is there a --enable-debug option in configure or not?
I don't ask anyone to debug my own crap, I just want to do it by myself! -- but I'm asking opinion about the most efficient way to do it.

Regards
Sebastien

On Wed, Jan 27, 2010 at 1:54 AM, Sébastien Lorquet <[hidden email]> wrote:
Hi,

I my quest trying to get a working mingw32ce version under win32 mingw (is someone interested by my (trivial) changes to the build-mingw32ce.sh script?) I had a small problem.

I noticed that any program compiled with -g makes LD fail with a win32 exception dialog. The exception code is 0xC0...05 which I believe is a segfault or null pointer access tentative. The faulting AppName is ld.exe and the faulting ModName is msvcrt.dll.

The latest toolchain, that produces the bug, is at: http://www.unsads.com/~squalyl/cegcc/mingw32ce-4.1-20100125.zip

Simplest test case:

#include <windows.h>
int APIENTRY WinMain(HINSTANCE inInstance, HINSTANCE inPrevInst, LPWSTR inCmdLine, int inCmdShow)
{
    MessageBoxW(NULL, L"hello", L"hello", MB_ICONINFORMATION);
    return 0;
}

compiles fine under linux with both
arm-mingw32ce-gcc test.c -o test.exe
and
arm-mingw32ce-gcc -g test.c -o test.exe

But with my toolchain, cross compiled from linux to mingw32msvc, the second line fails.

How can I use ./configure magic to generate a toolchain compiled with -g so that I can run it under gdb and provide a stack trace?

Apart from that, the toolchain is quite comfortable to use, for example with code::blocks. What could prevent it from being an official build?

I did not try gcc 4.4. Is this code stable enough to build from the current svn? I'll try that tomorrow.

Regards
Sebastien


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: arm-mingw32ce-gcc -g makes ld fail in mingw

Sébastien Lorquet
OK, export CFLAGS=-g before building seemed to be sufficient.

I'm now playing with GDB and the strange thing is, it does not catch any fault.

The last lines executed are:

Breakpoint 1, main (argc=20, argv=0x3e4008) at /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c:756
756     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
(gdb) c
Continuing.

Breakpoint 2, prefix_from_env (env=0x4192ed "COMPILER_PATH", pprefix=0x41d170) at /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c:687
687     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
(gdb) n
689     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
(gdb) n
691     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
(gdb) n
main (argc=20, argv=0x3e4008) at /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c:897
897     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
(gdb) n
prefix_from_env (env=0x4192fb "PATH", pprefix=0x41d180) at /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c:685
685     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
(gdb) n

Breakpoint 2, prefix_from_env (env=0x4192fb "PATH", pprefix=0x41d180) at /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c:687
687     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
(gdb) n
689     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
(gdb) n
690     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
(gdb) n
collect2: ld returned 5 exit status

Program exited with code 05.
(gdb)

the last "next" command makes ld exit(5).

I'll step insn by insn to find the opcode that makes it crash, so that I can get a stack history.

regards
sebastien

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: arm-mingw32ce-gcc -g makes ld fail in mingw

Sébastien Lorquet
The last assembly lines executed at the moment of the crash are:

(gdb)
636     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
0x00401ea9 <find_a_file+536>:    8b 45 f0       mov    -0x10(%ebp),%eax
0x00401eac <find_a_file+539>:    89 45 c8       mov    %eax,-0x38(%ebp)
0x00401eaf <find_a_file+542>:    eb 54  jmp    0x401f05 <find_a_file+628>
(gdb)
645     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
0x00401f08 <find_a_file+631>:    8b 5d fc       mov    -0x4(%ebp),%ebx
0x00401f0b <find_a_file+634>:    c9     leave
0x00401f0c <find_a_file+635>:    c3     ret
(gdb)
main (argc=20, argv=0x3e4008) at /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c:974
974     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
0x0040278e <main+1608>:  8b 85 6c ff ff ff      mov    -0x94(%ebp),%eax
0x00402794 <main+1614>:  85 c0  test   %eax,%eax
0x00402796 <main+1616>:  74 0b  je     0x4027a3 <main+1629>
(gdb)
975     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
0x00402798 <main+1618>:  8b 85 6c ff ff ff      mov    -0x94(%ebp),%eax
0x0040279e <main+1624>:  a3 2c d0 41 00 mov    %eax,0x41d02c
(gdb)
977     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
0x004027a3 <main+1629>:  8b 55 a4       mov    -0x5c(%ebp),%edx
0x004027a6 <main+1632>:  8b 45 8c       mov    -0x74(%ebp),%eax
0x004027a9 <main+1635>:  89 02  mov    %eax,(%edx)
0x004027ab <main+1637>:  8b 45 a4       mov    -0x5c(%ebp),%eax
0x004027ae <main+1640>:  8b 10  mov    (%eax),%edx
0x004027b0 <main+1642>:  8b 45 9c       mov    -0x64(%ebp),%eax
0x004027b3 <main+1645>:  89 10  mov    %edx,(%eax)
0x004027b5 <main+1647>:  83 45 9c 04    addl   $0x4,-0x64(%ebp)
0x004027b9 <main+1651>:  83 45 a4 04    addl   $0x4,-0x5c(%ebp)
(gdb)
980     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
0x004027bd <main+1655>:  83 ec 0c       sub    $0xc,%esp
0x004027c0 <main+1658>:  68 11 93 41 00 push   $0x419311
0x004027c5 <main+1663>:  e8 c6 c9 00 00 call   0x40f190 <make_temp_file>
0x004027ca <main+1668>:  83 c4 10       add    $0x10,%esp
0x004027cd <main+1671>:  a3 d0 d0 41 00 mov    %eax,0x41d0d0
(gdb)
make_temp_file (suffix=0x419311 ".c") at /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c:149
149     /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c: No such file or directory.
        in /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c
0x0040f190 <make_temp_file+0>:   55     push   %ebp
0x0040f191 <make_temp_file+1>:   89 e5  mov    %esp,%ebp
0x0040f193 <make_temp_file+3>:   83 ec 28       sub    $0x28,%esp
(gdb)
150     in /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c
0x0040f196 <make_temp_file+6>:   e8 65 fe ff ff call   0x40f000 <choose_tmpdir>
0x0040f19b <make_temp_file+11>:  89 45 ec       mov    %eax,-0x14(%ebp)
(gdb)
choose_tmpdir () at /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c:98
98      in /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c
0x0040f000 <choose_tmpdir+0>:    55     push   %ebp
0x0040f001 <choose_tmpdir+1>:    89 e5  mov    %esp,%ebp
0x0040f003 <choose_tmpdir+3>:    83 ec 18       sub    $0x18,%esp
(gdb)
99      in /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c
0x0040f006 <choose_tmpdir+6>:    c7 45 f4 00 00 00 00   movl   $0x0,-0xc(%ebp)
(gdb)
103     in /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c
0x0040f00d <choose_tmpdir+13>:   a1 f0 d3 41 00 mov    0x41d3f0,%eax
0x0040f012 <choose_tmpdir+18>:   85 c0  test   %eax,%eax
0x0040f014 <choose_tmpdir+20>:   74 0d  je     0x40f023 <choose_tmpdir+35>
(gdb)
106     in /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c
0x0040f023 <choose_tmpdir+35>:   83 ec 0c       sub    $0xc,%esp
0x0040f026 <choose_tmpdir+38>:   68 97 b4 41 00 push   $0x41b497
0x0040f02b <choose_tmpdir+43>:   e8 e0 8a 00 00 call   0x417b10 <getenv>
0x0040f030 <choose_tmpdir+48>:   83 c4 10       add    $0x10,%esp
0x0040f033 <choose_tmpdir+51>:   83 ec 08       sub    $0x8,%esp
0x0040f036 <choose_tmpdir+54>:   ff 75 f4       pushl  -0xc(%ebp)
0x0040f039 <choose_tmpdir+57>:   50     push   %eax
0x0040f03a <choose_tmpdir+58>:   e8 0f 01 00 00 call   0x40f14e <try_dir>
0x0040f03f <choose_tmpdir+63>:   83 c4 10       add    $0x10,%esp
0x0040f042 <choose_tmpdir+66>:   89 45 f4       mov    %eax,-0xc(%ebp)
(gdb)
collect2: ld returned 5 exit status

Program exited with code 05.
(gdb)
The program is not being run.
(gdb)
The program is not being run.
(gdb)

This is strange, there is a direct exit.

I'll add a breakpoint at /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c:106, and try to get a stack frame with local variables.

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: arm-mingw32ce-gcc -g makes ld fail in mingw

Sébastien Lorquet
106     in /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c
0x0040f023 <choose_tmpdir+35>:   83 ec 0c       sub    $0xc,%esp
0x0040f026 <choose_tmpdir+38>:   68 97 b4 41 00 push   $0x41b497
0x0040f02b <choose_tmpdir+43>:   e8 e0 8a 00 00 call   0x417b10 <getenv>
0x0040f030 <choose_tmpdir+48>:   83 c4 10       add    $0x10,%esp
0x0040f033 <choose_tmpdir+51>:   83 ec 08       sub    $0x8,%esp
0x0040f036 <choose_tmpdir+54>:   ff 75 f4       pushl  -0xc(%ebp)
0x0040f039 <choose_tmpdir+57>:   50     push   %eax
0x0040f03a <choose_tmpdir+58>:   e8 0f 01 00 00 call   0x40f14e <try_dir>
0x0040f03f <choose_tmpdir+63>:   83 c4 10       add    $0x10,%esp
0x0040f042 <choose_tmpdir+66>:   89 45 f4       mov    %eax,-0xc(%ebp)
(gdb)


(gdb) break /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c:106
Breakpoint 3 at 0x40f023: file /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c, line 106.

<mingw32 -lgcc -lceoldname -lmingwex -lcoredll -lcoredll -lmingw32 -lgcc -lceoldname -lmingwex -lcoredll
Starting program: c:/mingw/cross41-debug/bin/../libexec/gcc/arm-mingw32ce/4.1.0/collect2.exe -Bdynamic -o test.exe c:/mingw/cross41-debug/bin/../lib/gcc/arm-min
gw32ce/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-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib C:\DOCUME~1\squalyl\LOCALS~1\Temp/ccYkdej9.o -lmingw32 -lgcc -lceoldname -lmingw
ex -lcoredll -lcoredll -lmingw32 -lgcc -lceoldname -lmingwex -lcoredll
[New Thread 3428.0x16d8]

Breakpoint 1, main (argc=20, argv=0x3e4008) at /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c:756
756     /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c: No such file or directory.
        in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
0x00402166 <main+32>:    a1 90 92 41 00 mov    0x419290,%eax
0x0040216b <main+37>:    8b 15 70 91 41 00      mov    0x419170,%edx
0x00402171 <main+43>:    6a 00  push   $0x0
0x00402173 <main+45>:    50     push   %eax
0x00402174 <main+46>:    68 94 92 41 00 push   $0x419294
0x00402179 <main+51>:    52     push   %edx
0x0040217a <main+52>:    e8 58 da 00 00 call   0x40fbd7 <concat>
0x0040217f <main+57>:    83 c4 10       add    $0x10,%esp
0x00402182 <main+60>:    89 85 70 ff ff ff      mov    %eax,-0x90(%ebp)
(gdb) c
Continuing.

Breakpoint 2, prefix_from_env (env=0x4192ed "COMPILER_PATH", pprefix=0x41d170) at /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c:687
687     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
0x00401fc4 <prefix_from_env+6>:  83 ec 0c       sub    $0xc,%esp
0x00401fc7 <prefix_from_env+9>:  ff 75 08       pushl  0x8(%ebp)
0x00401fca <prefix_from_env+12>:         e8 41 5b 01 00 call   0x417b10 <getenv>
0x00401fcf <prefix_from_env+17>:         83 c4 10       add    $0x10,%esp
0x00401fd2 <prefix_from_env+20>:         89 45 fc       mov    %eax,-0x4(%ebp)
(gdb) c
Continuing.

Breakpoint 2, prefix_from_env (env=0x4192fb "PATH", pprefix=0x41d180) at /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c:687
687     in /home/squalyl/projects/cegcc/src/gcc/gcc/collect2.c
0x00401fc4 <prefix_from_env+6>:  83 ec 0c       sub    $0xc,%esp
0x00401fc7 <prefix_from_env+9>:  ff 75 08       pushl  0x8(%ebp)
0x00401fca <prefix_from_env+12>:         e8 41 5b 01 00 call   0x417b10 <getenv>
0x00401fcf <prefix_from_env+17>:         83 c4 10       add    $0x10,%esp
0x00401fd2 <prefix_from_env+20>:         89 45 fc       mov    %eax,-0x4(%ebp)
(gdb) c
Continuing.

Breakpoint 3, choose_tmpdir () at /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c:106
106     /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c: No such file or directory.
        in /home/squalyl/projects/cegcc/src/gcc/libiberty/make-temp-file.c
0x0040f023 <choose_tmpdir+35>:   83 ec 0c       sub    $0xc,%esp
0x0040f026 <choose_tmpdir+38>:   68 97 b4 41 00 push   $0x41b497
0x0040f02b <choose_tmpdir+43>:   e8 e0 8a 00 00 call   0x417b10 <getenv>
0x0040f030 <choose_tmpdir+48>:   83 c4 10       add    $0x10,%esp
0x0040f033 <choose_tmpdir+51>:   83 ec 08       sub    $0x8,%esp
0x0040f036 <choose_tmpdir+54>:   ff 75 f4       pushl  -0xc(%ebp)
0x0040f039 <choose_tmpdir+57>:   50     push   %eax
0x0040f03a <choose_tmpdir+58>:   e8 0f 01 00 00 call   0x40f14e <try_dir>
0x0040f03f <choose_tmpdir+63>:   83 c4 10       add    $0x10,%esp
0x0040f042 <choose_tmpdir+66>:   89 45 f4       mov    %eax,-0xc(%ebp)
(gdb) n
collect2: ld returned 5 exit status

Program exited with code 05.

crash is really at assembly level. The incriminated line is the first of these three:

  base = try_dir (getenv ("TMPDIR"), base);
  base = try_dir (getenv ("TMP"), base);
  base = try_dir (getenv ("TEMP"), base);

but... Why?!

I forgot to add -O0 to the debug CFLAGS. Now building the toolchain with:

export CFLAGS="-g -O0 -fno-inline"
export LDFLAGS=-g


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: arm-mingw32ce-gcc -g makes ld fail in mingw

Pedro Alves-5
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

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: arm-mingw32ce-gcc -g makes ld fail in mingw

Sébastien Lorquet
(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 <[hidden email]> 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)




------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: arm-mingw32ce-gcc -g makes ld fail in mingw

Dave Korn-2
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

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: arm-mingw32ce-gcc -g makes ld fail in mingw

Sébastien Lorquet
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 <[hidden email]> 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


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: arm-mingw32ce-gcc -g makes ld fail in mingw

Dave Korn-2
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


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: arm-mingw32ce-gcc -g makes ld fail in mingw

Dave Korn-2
In reply to this post by Sébastien Lorquet
On 27/01/2010 00:54, Sébastien Lorquet wrote:

> The latest toolchain, that produces the bug, is at:
> http://www.unsads.com/~squalyl/cegcc/mingw32ce-4.1-20100125.zip

  I downloaded this zip and unpacked it to C:\ on a WinXpSp2 machine, then ran

PATH C:\mingw32ce-4.1-20100125\cross41\bin;%PATH%

> Simplest test case:
>
> #include <windows.h>
> int APIENTRY WinMain(HINSTANCE inInstance, HINSTANCE inPrevInst, LPWSTR
> inCmdLine, int inCmdShow)
> {
>     MessageBoxW(NULL, L"hello", L"hello", MB_ICONINFORMATION);
>     return 0;
> }
>
> compiles fine under linux with both
> arm-mingw32ce-gcc test.c -o test.exe
> and
> arm-mingw32ce-gcc -g test.c -o test.exe
>
> But with my toolchain, cross compiled from linux to mingw32msvc, the second
> line fails.

  So... are we sure we're testing the same thing?  Because it worked fine for me:

C:\mingw32ce-4.1-20100125>dir
 Volume in drive C has no label.
 Volume Serial Number is 6857-454C

 Directory of C:\mingw32ce-4.1-20100125

31/01/2010  16:40    <DIR>          .
31/01/2010  16:40    <DIR>          ..
31/01/2010  16:37    <DIR>          cross41
31/01/2010  16:34               209 test.c
               1 File(s)            209 bytes
               3 Dir(s)  17,257,099,264 bytes free

C:\mingw32ce-4.1-20100125>type test.c
#include <windows.h>
int APIENTRY WinMain(HINSTANCE inInstance, HINSTANCE inPrevInst, LPWSTR
inCmdLine, int inCmdShow)
{
    MessageBoxW(NULL, L"hello", L"hello", MB_ICONINFORMATION);
    return 0;
}


C:\mingw32ce-4.1-20100125>arm-mingw32ce-gcc -g test.c -o test.exe

C:\mingw32ce-4.1-20100125>dir
 Volume in drive C has no label.
 Volume Serial Number is 6857-454C

 Directory of C:\mingw32ce-4.1-20100125

31/01/2010  16:40    <DIR>          .
31/01/2010  16:40    <DIR>          ..
31/01/2010  16:37    <DIR>          cross41
31/01/2010  16:34               209 test.c
31/01/2010  16:40            28,753 test.exe
               2 File(s)         28,962 bytes
               3 Dir(s)  17,257,066,496 bytes free

C:\mingw32ce-4.1-20100125>arm-mingw32ce-objdump -h test.exe

test.exe:     file format pei-arm-wince-little

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000788  00011000  00011000  00000400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000020  00012000  00012000  00000c00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .rdata        0000029c  00013000  00013000  00000e00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .debug_aranges 000000e0  00014000  00014000  00001200  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_pubnames 000001f9  00015000  00015000  00001400  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_info   000013b3  00016000  00016000  00001600  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_abbrev 00000682  00018000  00018000  00002a00  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_line   00000740  00019000  00019000  00003200  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_frame  00000258  0001a000  0001a000  00003a00  2**2
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_str    0000004e  0001b000  0001b000  00003e00  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_loc    00000646  0001c000  0001c000  00004000  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_ranges 00000070  0001d000  0001d000  00004800  2**0
                  CONTENTS, READONLY, DEBUGGING

C:\mingw32ce-4.1-20100125>


On 31/01/2010 11:32, Sébastien Lorquet wrote:

> 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);
>         }


> (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'}

  Now, this should be a section header from the input .o file (created
temporarily during compilation since not using --save-temps), and some of
those values look right, but the s_name, which is meant to be a decimal offset
into the string table (at the end of the .o file) is clearly nonsensical.
>
> I don't know why the heck this happens, but the address out of bounds I get
> seems related to this FIXME .

  The FIXME is stating that it would be nice if we could detect this kind of
malformed input here, but we (for structural reasons) can't.  The problem has
to be either that the assembler generated a bogus .o file in the first place,
or that ld is somehow corrupting or misreading that section header.

  Since I can't reproduce this problem, can you try recompiling your testcase,
using --save-temps, and then show us the output of "arm-mingw32ce-objdump -h
test.o" ?

    cheers,
      DaveK



------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: arm-mingw32ce-gcc -g makes ld fail in mingw

Sébastien Lorquet
I'm sorry Dave, I'm afraid ld can't let me do that...

hrrrrrm... well

Just tried the very command you reported. My XP is SP3.

C:\mingw32ce-4.1-20100125>dir
 Le volume dans le lecteur C n'a pas de nom.
 Le numéro de série du volume est 80AF-8B27

 Répertoire de C:\mingw32ce-4.1-20100125

31/01/2010  20:15    <REP>          .
31/01/2010  20:15    <REP>          ..
31/01/2010  20:15    <REP>          cross41
31/01/2010  20:26               205 test.c
               0 fichier(s)                0 octets
               3 Rép(s)   6 609 469 440 octets libres

C:\mingw32ce-4.1-20100125>set PATH=c:\mingw32ce-4.1-20100125\cross41\bin;%PATH%

C:\mingw32ce-4.1-20100125>type test.c
#include <windows.h>
int APIENTRY WinMain(HINSTANCE inInstance, HINSTANCE inPrevInst, LPWSTR
inCmdLine, int inCmdShow)
{
   MessageBoxW(NULL, L"hello", L"hello", MB_ICONINFORMATION);
   return 0;
}

C:\mingw32ce-4.1-20100125>arm-mingw32ce-gcc -g test.c -o test.exe
collect2: ld returned 5 exit status

with a "ld.exe did domething bad and was closed" message from windows.

Bonus 1: I tried --save-temps.
Guess what? arm-mingw32ce-objdump - test.o ALSO crashes. In the same place, yes. At least it's consistent. I'm attaching the .o/.s files for your amusement. If the .o file crashes your setup, then as is generating garbage and ld and objdump are victims.

C:\mingw32ce-4.1-20100125>c:\MinGW\gcc3\bin\gdb.exe arm-mingw32ce-objdump
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:\mingw32ce-4.1-20100125\cross41\bin/arm-mingw32ce-objdump.exe...done.
(gdb) run -h test.o
Starting program: c:\mingw32ce-4.1-20100125\cross41\bin/arm-mingw32ce-objdump.exe -h test.o
[New Thread 2552.0xb44]

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  0x0042ff37 in make_a_section_from_file (abfd=0x2325a8) at /home/squalyl/cegcc/src/binutils/bfd/coffgen.c:93
#2  coff_real_object_p (abfd=0x2325a8) at /home/squalyl/cegcc/src/binutils/bfd/coffgen.c:222
#3  coff_object_p (abfd=0x2325a8) at /home/squalyl/cegcc/src/binutils/bfd/coffgen.c:301
Backtrace stopped: frame did not save the PC
(gdb)


Bonus 2: my environment. But I hardly think env will change something in this problem.

C:\mingw32ce-4.1-20100125>set
ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\squalyl\Application Data
CLIENTNAME=Console
CommonProgramFiles=C:\Program Files\Fichiers communs
COMPUTERNAME=Q45XP
ComSpec=C:\WINDOWS\system32\cmd.exe
FP_NO_HOST_CHECK=NO
GPUTILS_HEADER_PATH=C:\Program Files\gputils\header
GPUTILS_LKR_PATH=C:\Program Files\gputils\lkr
GTK_BASEPATH=C:\GTK
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\squalyl
LANG=FR
LOGONSERVER=\\Q45XP
NUMBER_OF_PROCESSORS=2
OS=Windows_NT
PANGO_WIN32_NO_UNISCRIBE=anything
Path=c:\mingw32ce-4.1-20100125\cross41\bin;C:\GTK\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\programs\opensc\bin;C:\jlibs\ocf\lib;C:\Program
 Files\TortoiseSVN\bin;C:\Program Files\Microchip\MPLAB C32 Suite\bin;C:\Program Files\Microchip\MPLAB IDE\VDI;C:\Program Files\HI-TECH Software\PICC\PRO\9.65\b
in;C:\sdcc\bin;C:\Program Files\gputils\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 15 Stepping 13, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0f0d
ProgramFiles=C:\Program Files
PROMPT=$P$G
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\DOCUME~1\squalyl\LOCALS~1\Temp
TMP=C:\DOCUME~1\squalyl\LOCALS~1\Temp
USERDOMAIN=Q45XP
USERNAME=squalyl
USERPROFILE=C:\Documents and Settings\squalyl
VS90COMNTOOLS=C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\
windir=C:\WINDOWS

PS: the binaries in this toolchain includes debug information:
http://www.unsads.com/~squalyl/cegcc/mingw32ce-4.1-20100129+gdb+dbg.zip

Regards and thanks
Sebastien

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel

test.o (3K) Download Attachment
test.s (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: arm-mingw32ce-gcc -g makes ld fail in mingw

Dave Korn-2
On 31/01/2010 22:32, Sébastien Lorquet wrote:

> as is generating garbage and ld and objdump are victims.

  Yep.  The section headers are full of nonsense.  The string table is present
and all the long section names are there, but all the section headers containt
"/1579551", which is way out of range.

  We need to debug what's going on in coff_write_object_contents() in the
assembler.  If you walk through this loop:

  for (current = abfd->sections;
       current != NULL;
       current = current->next)
    {
      struct internal_scnhdr section;
      bfd_boolean is_reloc_section = FALSE;


... checking the contents of 'current' each time, and then seeing what happens
to len and string_size here:

      /* Handle long section names as in PE.  This must be compatible
         with the code in coff_write_symbols and _bfd_coff_final_link.  */
      if (bfd_coff_long_section_names (abfd))
        {
          size_t len;

          len = strlen (current->name);
          if (len > SCNNMLEN)
            {
              [ ... more ... ]
              string_size += len + 1;
              long_section_names = TRUE;
            }
        }

... we should get some idea what's going wrong.

    cheers,
      DaveK


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: arm-mingw32ce-gcc -g makes ld fail in mingw

Sébastien Lorquet
First step: run arm-mingw32ce-gcc -g --save-temps test.c -o test.exe
this crashes after quite a LONG time (several seconds).

then:

C:\MinGW>del test.o

C:\MinGW>gcc3\bin\gdb.exe arm-mingw32ce-as.exe
GNU gdb 6.8
Copyright (C) 2008 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 "i686-pc-mingw32"...
(gdb) break coffcode.h:3656
Breakpoint 1 at 0x45fef1: file /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h, line 3656. (2 locations)
(gdb) run test.s
Starting program: c:\MinGW\cross41-debug\bin/arm-mingw32ce-as.exe test.s
[New thread 2316.0x3b0]

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h: No such file or directory.
        in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
(gdb) print len
$1 = 5
(gdb) print string_size
$2 = 4
(gdb) print *current
$3 = {name = 0x4a0a6e ".text", id = 16, index = 0, next = 0x1591608, prev = 0x0, flags = 279, user_set_vma = 0, linker_mark = 0,
  linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0, has_tls_get_addr_call = 0,
  has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 72, rawsize = 0, relax = 0x0, relax_count = 0,
  output_offset = 0, output_section = 0x1591550, alignment_power = 2, relocation = 0x0, orelocation = 0x14e54a0, reloc_count = 2, filepos = 500,
  rel_filepos = 1596, line_filepos = 0, userdata = 0x2328b0, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0,
  moving_line_filepos = 0, target_index = 1, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e3358,
  symbol_ptr_ptr = 0x15915e8, map_head = {link_order = 0x0, s = 0x0}, map_tail = {link_order = 0x0, s = 0x0}}
(gdb)

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
(gdb) display len
1: len = 5
(gdb) display string_size
2: string_size = 4
(gdb) display *current
3: *current = {name = 0x4a0a74 ".data", id = 17, index = 1, next = 0x15916c0, prev = 0x1591550, flags = 3, user_set_vma = 0, linker_mark = 0,
  linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0, has_tls_get_addr_call = 0,
  has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 0, rawsize = 0, relax = 0x0, relax_count = 0,
  output_offset = 0, output_section = 0x1591608, alignment_power = 2, relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 0,
  rel_filepos = 0, line_filepos = 0, userdata = 0x2328f8, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0,
  moving_line_filepos = 0, target_index = 2, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e34c0,
  symbol_ptr_ptr = 0x15916a0, map_head = {link_order = 0x0, s = 0x0}, map_tail = {link_order = 0x0, s = 0x0}}
(gdb)
(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x4a0a7a ".bss", id = 18, index = 2, next = 0x15918e8, prev = 0x1591608, flags = 1, user_set_vma = 0, linker_mark = 0,
  linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0, has_tls_get_addr_call = 0,
  has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 0, rawsize = 0, relax = 0x0, relax_count = 0,
  output_offset = 0, output_section = 0x15916c0, alignment_power = 2, relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 0,
  rel_filepos = 0, line_filepos = 0, userdata = 0x232940, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0,
  moving_line_filepos = 0, target_index = 3, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e3628,
  symbol_ptr_ptr = 0x1591758, map_head = {link_order = 0x0, s = 0x0}, map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 4
1: len = 4

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x16d7418 ".debug_abbrev", id = 21, index = 3, next = 0x15919a0, prev = 0x15916c0, flags = 298, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 145, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x15918e8, alignment_power = 0, relocation = 0x0, orelocation = 0x0, reloc_count = 0,
  filepos = 572, rel_filepos = 0, line_filepos = 0, userdata = 0x16d7440, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 4, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e3d58,
  symbol_ptr_ptr = 0x1591980, map_head = {link_order = 0x0, s = 0x0}, map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 4
1: len = 13

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x14e6518 ".debug_info", id = 22, index = 4, next = 0x1591a58, prev = 0x15918e8, flags = 302, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 451, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x15919a0, alignment_power = 0, relocation = 0x0, orelocation = 0x1814718, reloc_count = 9,
  filepos = 717, rel_filepos = 1616, line_filepos = 0, userdata = 0x14e6540, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 5, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e3ee8,
  symbol_ptr_ptr = 0x1591a38, map_head = {link_order = 0x0, s = 0x0}, map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 18
1: len = 11

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x14e75e0 ".debug_line", id = 23, index = 5, next = 0x1591b10, prev = 0x15919a0, flags = 8460, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 248, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x1591a58, alignment_power = 0, relocation = 0x0, orelocation = 0x18149e0, reloc_count = 1,
  filepos = 1168, rel_filepos = 1706, line_filepos = 0, userdata = 0x14e8600, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 6, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e4078,
  symbol_ptr_ptr = 0x1591af0, map_head = {link_order = 0x0, s = 0x0}, map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 30
1: len = 11

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x14e96f8 ".rdata", id = 24, index = 6, next = 0x1591bc8, prev = 0x1591a58, flags = 290, user_set_vma = 0, linker_mark = 0,
  linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0, has_tls_get_addr_call = 0,
  has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 12, rawsize = 0, relax = 0x0, relax_count = 0,
  output_offset = 0, output_section = 0x1591b10, alignment_power = 2, relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 1416,
  rel_filepos = 0, line_filepos = 0, userdata = 0x14e9718, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0,
  moving_line_filepos = 0, target_index = 7, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e77a0,
  symbol_ptr_ptr = 0x1591ba8, map_head = {link_order = 0x0, s = 0x0}, map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 42
1: len = 6

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x14ecf58 ".debug_frame", id = 25, index = 7, next = 0x1591c80, prev = 0x1591b10, flags = 302, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 48, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x1591bc8, alignment_power = 2, relocation = 0x0, orelocation = 0x1814a68, reloc_count = 2,
  filepos = 1428, rel_filepos = 1716, line_filepos = 0, userdata = 0x14ecf80, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 8, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e7b88,
  symbol_ptr_ptr = 0x1591c60, map_head = {link_order = 0x0, s = 0x0}, map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 42
1: len = 12

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x14edfc8 ".debug_loc", id = 26, index = 8, next = 0x1591d38, prev = 0x1591bc8, flags = 298, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 42, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x1591c80, alignment_power = 0, relocation = 0x0, orelocation = 0x0, reloc_count = 0,
  filepos = 1476, rel_filepos = 0, line_filepos = 0, userdata = 0x16d7868, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 9, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e7e08,
  symbol_ptr_ptr = 0x1591d18, map_head = {link_order = 0x0, s = 0x0}, map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 55
1: len = 10

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x16d79b0 ".debug_pubnames", id = 27, index = 9, next = 0x1591df0, prev = 0x1591c80, flags = 302, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 30, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x1591d38, alignment_power = 0, relocation = 0x0, orelocation = 0x1814b38, reloc_count = 1,
  filepos = 1518, rel_filepos = 1736, line_filepos = 0, userdata = 0x16d79d8, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 10, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e7fc0,
  symbol_ptr_ptr = 0x1591dd0, map_head = {link_order = 0x0, s = 0x0}, map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 66
1: len = 15

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x16d7a20 ".debug_aranges", id = 28, index = 10, next = 0x1591ea8, prev = 0x1591d38, flags = 302, user_set_vma = 0,
  linker_mark = 0, linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0,
  has_tls_get_addr_call = 0, has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 32, rawsize = 0, relax = 0x0,
  relax_count = 0, output_offset = 0, output_section = 0x1591df0, alignment_power = 0, relocation = 0x0, orelocation = 0x1814ba0, reloc_count = 2,
  filepos = 1548, rel_filepos = 1746, line_filepos = 0, userdata = 0x16d7a48, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0,
  kept_section = 0x0, moving_line_filepos = 0, target_index = 11, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e8128,
  symbol_ptr_ptr = 0x1591e88, map_head = {link_order = 0x0, s = 0x0}, map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 82
1: len = 14

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x16d7a90 ".debug_str", id = 29, index = 11, next = 0x0, prev = 0x1591df0, flags = 298, user_set_vma = 0, linker_mark = 0,
  linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0, has_tls_get_addr_call = 0,
  has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 13, rawsize = 0, relax = 0x0, relax_count = 0,
  output_offset = 0, output_section = 0x1591ea8, alignment_power = 0, relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 1580,
  rel_filepos = 0, line_filepos = 0, userdata = 0x16d7ab8, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0,
  moving_line_filepos = 0, target_index = 12, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e8290,
  symbol_ptr_ptr = 0x1591f40, map_head = {link_order = 0x0, s = 0x0}, map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 97
1: len = 10

(gdb) c
Continuing.

Breakpoint 1, coff_write_object_contents (abfd=0x2326c8) at /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h:3656
3656    in /home/squalyl/projects/cegcc/src/binutils/bfd/coffcode.h
3: *current = {name = 0x16d7a90 ".debug_str", id = 29, index = 11, next = 0x0, prev = 0x1591df0, flags = 298, user_set_vma = 0, linker_mark = 0,
  linker_has_input = 0, gc_mark = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 0, has_tls_reloc = 0, has_tls_get_addr_call = 0,
  has_gp_reloc = 0, need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 13, rawsize = 0, relax = 0x0, relax_count = 0,
  output_offset = 0, output_section = 0x1591ea8, alignment_power = 0, relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 1580,
  rel_filepos = 0, line_filepos = 0, userdata = 0x16d7ab8, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0,
  moving_line_filepos = 0, target_index = 12, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x2326c8, symbol = 0x14e8290,
  symbol_ptr_ptr = 0x1591f40, map_head = {link_order = 0x0, s = 0x0}, map_tail = {link_order = 0x0, s = 0x0}}
2: string_size = 97
1: len = 10
(gdb) c
Continuing.

Program exited normally.


All of this seems very normal to me. What about you?

Sebastien

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: arm-mingw32ce-gcc -g makes ld fail in mingw

Sébastien Lorquet
Notice I pasted twice the last loop. It only happens once.



------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Loading...