Hi, On Wed, Sep 17, 2008 at 7:46 PM, Pedro Alves <[EMAIL PROTECTED]> wrote: > On Thursday 18 September 2008 02:56:47, Pawel Veselov wrote: >> Argh, took me a find out what's going on. Will need some more time to >> actually produce a fix. Discovered all that while testing the changes >> to the tracer. > AFAIK, you should be able to debug cegcc.dll with gdbserver, cuz > gdbserver.exe is a mingw32ce app (doesn't load cegcc.dll), and from > the point of view of gdb, cegcc.dll is just another dll.
That's exactly what I'm doing :) But since my problem was that the application would just plain hang the device if executed, and after some debugging I found out that it was failing in free(), I had to understand the logic behind the prologue code to know why. [ skipped for later] >> Problem #2: environ variable. Though the environ variable is set up by >> the stdlib module of the newlib(environ.c), the actual code that deals >> with environment variables (setenv_r.c) has it's own pointer to it, >> called p_environ. The p_environ is of (char***) type, and is >> initialized with the value of &environ. The environ is of type >> (char*[]), and initialized to a constant array that contains a (null). >> The stdlib setenv_r implementation has a static tracking variable, >> that, once there is a modification to the environment block is done, >> (except for overwriting a variable with a smaller length value), the >> p_environ is reallocated. So it longer points to the environ. Also, >> since the initial environment block is always empty, the reallocation >> is quite guaranteed once any new variable is added. As a result of all >> the above, the rest of newlib code must never rely on the "environ" >> variable to do anything, as it's value will first always be stale. >> wince part of newlib seems to frequently use "environ" variable during >> spawn(). > Are you sure? `*p_environ' is writen to as part of the > realloccing, which updates `environ'. As long as we don't assume > `environ' doesn't change across function calls, we're safe. Do > we not? That is, keep a point to environ somewhere, instead of > always referencing it directly, is bad. Yes, we are. Anything with more than one asterisk always makes me loose it :) The setenv_r are also thread safe (supposedely, since there is some locking code inside, not sure how it works and if it does) [ skipped ] >> b. Say a .c source declares an intialized static varable. When the >> .dll loads up, when does the initialization code gets executed? I hope >> it's before the dll entry point is jumped to. > Come on, that'd be easy for you to confirm! (hint: yes). Dude, if it wasn't for your hint.... :) Thank you. <sorry for the dup, forgot to CC the list> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
