On Wed, 2009-07-08 at 16:45 +0200, Danny Backx wrote:
> On Wed, 2009-07-08 at 15:21 +0100, Dave Korn wrote:
> > So, how do those addresses relate to where the DLL actually is loaded in
> > memory? I'm assuming not much, given that it crashes, which would imply
> > something had gone very very wr
Danny Backx wrote:
> 0x0040106a : movl $0x41f6c160,(%esp)
> 0x00401071 <_fu0___ZSt4cout+4>: call 0x4235c492
> 0x00401099 <__static_initialization_and_destruction_0+28>: call
> 0x4235174a
> 0x0040109e <_fu2___ZNSt8ios_base4InitC1Ev+4>: cmpl $0x0,0x8(%ebp)
So, how do those addre
On Wed, 2009-07-08 at 09:41 +0100, Dave Korn wrote:
> Danny Backx wrote:
>
> > global constructors keyed to main () at hello.C:8
> > 8 }
> > Current language: auto; currently c++
> > (gdb)
> > __static_initialization_and_destruction_0 (__initialize_p=1,
> > __priority=65535) at hello.C:8
>
Danny Backx wrote:
> global constructors keyed to main () at hello.C:8
> 8 }
> Current language: auto; currently c++
> (gdb)
> __static_initialization_and_destruction_0 (__initialize_p=1,
> __priority=65535) at hello.C:8
> 8 }
> (gdb)
> 72static ios_base::Init __ioinit;
> (g
On Wed, 2009-07-08 at 07:31 +0100, Dave Korn wrote:
> Danny Backx wrote:
>
> > - linker mentions ios_base::Init::Init()
> > - crash occurs, says gdb, in ios_base::Init __ioinit;
> > - gdbserver occasionally shows the glitch with reading dll names
> > (Symbol file not found for li)
>
> > Info: r
Danny Backx wrote:
> - linker mentions ios_base::Init::Init()
> - crash occurs, says gdb, in ios_base::Init __ioinit;
> - gdbserver occasionally shows the glitch with reading dll names
> (Symbol file not found for li)
> Info: resolving std::cout by linking to __imp___ZSt4cout (auto-import)
> I
On Mon, 2009-07-06 at 08:53 +0200, Johnny Willemsen wrote:
> Hi,
>
> > > You need to either make both calls be to __main, or to __gccmain,
> > never to both.
> >
> > I think I fixed that one already.
> >
> > Right now, a constructor from libstdc++ is dying when it gets called
> > for the first t
Hi,
> > You need to either make both calls be to __main, or to __gccmain,
> never to both.
>
> I think I fixed that one already.
>
> Right now, a constructor from libstdc++ is dying when it gets called
> for the first time.
>
> It happens to get mentioned in a linker message about auto-import.
Pedro Alves wrote :
> You need to either make both calls be to __main, or to __gccmain,
never to both.
I think I fixed that one already.
Right now, a constructor from libstdc++ is dying when it gets called for the
first time.
It happens to get mentioned in a linker message about auto-import. N
Let's see if I can make sense.
So that globsl C++ contructors are run, gcc puts a magic
call to a special function right at the top of `main'. On most
targets that need it, it's called __main, but on ARM,
it's called __gccmain. Now, in addition to this magic
call that gcc puts there itself, the
When I compile the same program with arm-mingw32ce-g++ or with
i386-mingw32ce-g++ , the results are different.
pavilion: {124} i386-mingw32ce-g++ -g -D_WIN32_IE=0x0400
-D_WIN32_WCE=0x0400 -o hello.exe hello.C
Info: resolving std::cout by linking to __imp___ZSt4cout (auto-import)
Info: resolving s
On Fri, 2009-06-19 at 17:02 +0200, Danny Backx wrote:
> I'm trying to track down the problem by writing small test programs that
> use C++ constructors in the presence of DLLs.
>
> I have something with a constructor in a DLL that doesn't look right,
> but I've not figured it out yet.
There's not
On Fri, 2009-06-19 at 11:20 +0200, Johnny Willemsen wrote:
> > This was clearly an error but I can explain and fix it.
> >
> > There were overlapping main/gccmain (or so) functions in src/mingw and
> > src/gcc-4.4.0/gcc/libgcc2.c . Both were calling constructors and
> > destructors.
> >
> > Now,
Hi,
> This was clearly an error but I can explain and fix it.
>
> There were overlapping main/gccmain (or so) functions in src/mingw and
> src/gcc-4.4.0/gcc/libgcc2.c . Both were calling constructors and
> destructors.
>
> Now, here's a debug session that shows that the constructor of the
> iost
This was clearly an error but I can explain and fix it.
There were overlapping main/gccmain (or so) functions in src/mingw and
src/gcc-4.4.0/gcc/libgcc2.c . Both were calling constructors and
destructors.
Now, here's a debug session that shows that the constructor of the
iostream crashes.
How do
Hmm, very interesting.
\network\x86> gdbserver : /network/x86/ctor.exe
Process /network/x86/ctor.exe created; pid = 100466698
Listening on port
Remote debugging from host 172.17.1.10
ctor B
ctor B
ctor A
Hello
dtor A
dtor B
dtor B
Child exited with status 0
GDBserver exiting
The constru
Vincent R. wrote :
> First how do you test on x86 platform ? DO you have an emulator for that ?
The ebox 4300 on my desk runs Windows Embedded CE 6.0 .
Danny
--
Danny Backx - danny.backx - at scarlet.be ; http://danny.backx.info
---
Danny Backx wrote:
> The C++ library on x86 appears to crash at initialisation even in the
> simplest of programs. At least, it does so when compiled against the DLL
> version of the library.
>
> #include
> using namespace std;
> int main(int argc, char *argv[])
> {
> cout << "Hello" << end
On Tue, 16 Jun 2009 21:03:44 +0200, Danny Backx
wrote:
> The C++ library on x86 appears to crash at initialisation even in the
> simplest of programs. At least, it does so when compiled against the DLL
> version of the library.
>
> #include
> using namespace std;
> int main(int argc, char *argv[
The C++ library on x86 appears to crash at initialisation even in the
simplest of programs. At least, it does so when compiled against the DLL
version of the library.
#include
using namespace std;
int main(int argc, char *argv[])
{
cout << "Hello" << endl ;
}
Are there any tricks involved
20 matches
Mail list logo
