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. > Problem #1: The prologue crash. The code in _initenv() provides a > char[MAX_ENVIRONBLK] buffer to the _shared_getenvblk() function in > shared.c That function expects a char** buffer, with independently > allocated memory for every element. If the elements are !0, the > getenvblk() tries to free them, and since the passed buffer contains > uninitialized memory, so there is your crash, while attempting to > free() a bogus pointer. Initializing the memory wouldn't solve the > problem, as the rest of the env.c code will treat the filled buffer as > a continuous block of memory with asciiz strings, terminated with an > extra 0, where the getenvblk will return the array of char* pointers, > that point to a newly allocated memory. Boo, you're right. This has to be triggering a warning when being compiled about a char* / char ** mismatch. On a quick look, it looks to me that it's _shared_setenvblk and _shared_getenvblk that should take a memory block (char*) as parameter, and stop doing that malloc/free nonsense; treat the block as a block. > 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. > Problem #3: The _initenv() function in env.c and inherit_parent() > function in startup.c seem to be trying to accomplish the same task of > copying the environment variable of the shared process group into > envuironment variable table. This is the least of the problems here :) > > I'm gonna go (unless you guys think I'm chasing geese here), and comb > all this into a working model. This would most likely involve two > things : getting rid of referencing environ directly from the wince > specific code, and fixing the shared block updates/reads with regards > to environment variables. > > While I'm coming up with the solution, I have two questions, anwering > which would very much help me do the things right :) > > a. what's all the code in ceprocess.c / ceshared2.c, seems to do > efforst to spawn applications, and deal with the shared memory, but in > a different way, I'm just not sure when is this code called. Dunno without looking deeper (been many moons since I looked at cegcc.dll code), but I wouldn't be surprised there were a bunch or goblins around here. Keep in mind that this is a bunch of voxware+celib+pedro-when-he-didn't-know-how-to-write-code-and-didn't-know-a-thing-about-CE stuff :-) Wear sunglasses. > 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). -- Pedro Alves ------------------------------------------------------------------------- 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
