Thanks for the link. I usually will write wrapper functions to access static variables, rather than exporting global variables. As such, it has been a long time since I have thought much about this detail, and my past experience still managed to lead me to the fix quickly enough.
--Z On Wed, 2009-11-18 at 14:55 -0600, Dean Glazeski wrote: > It seems hard to understand, but there appears to be a very subtle > difference. With a pointer, a, the variable is going to have 2 or 4 > bytes allocated to store an address. When an offset is done, a[3], > it's going to load the contents of a and then add 3 to get to the > desired value. If a was declared as an array, this would load the > contents of the array as opposed to the address and this results in > the seg fault. If a was an array, a[], then there will be some space > allocated for the actual array contents and a becomes a constant > offset in assembly. This offset is put into a move instruction and > added with 3. Now we are actually offsetting into an array. > > Aren't C externs fun? Here's a site that explains it well. I know, > it's from microsoft, but it has pretty ASCII pictures :) > > http://support.microsoft.com/kb/44463 > > // Dean Glazeski > > > On Wed, Nov 18, 2009 at 2:05 PM, Zach Welch <z...@superlucidity.net> > wrote: > Okay.... I've pushed it. However, I have to wonder if I am > the only one > that is a little surprised that this was the source of the > problem. > > > On Wed, 2009-11-18 at 13:49 -0600, Dean Glazeski wrote: > > I can confirm that this fixes the seg fault on my end. > > > > // Dean Glazeski > > > > > > On Wed, Nov 18, 2009 at 1:42 PM, Zach Welch > <z...@superlucidity.net> > > wrote: > > On Wed, 2009-11-18 at 11:34 -0800, Zach Welch wrote: > > > On Wed, 2009-11-18 at 11:23 -0700, David Brownell > wrote: > > > > On Wednesday 18 November 2009, Zach Welch wrote: > > > > > On Tue, 2009-11-17 at 09:39 -0800, Zachary T > Welch > > wrote: > > > > > > Hi all, > > > > > > > > > > > > This series modularizes the startup.tcl > file, putting > > various pieces > > > > > > of the system where they belong. Instead of > linking > > it into the library, > > > > > > provide it as a parameter to the > command_init() > > routine from openocd.c. > > > > > > Fixes the layering violations that this > built-in TCL > > code created. > > > > > > > > > > Pushed, with a fix in the second patch to add > the new > > files to be > > > > > distributed by the automake rules. > > > > > > > > Now OpenOCD reliably coredumps on startup... > > > > > > Uh-oh I though that I had tested those changes > fairly well, > > but I > > > apparently made a mistake. I'll try to figure out > what's > > going on and > > > commit a fix shortly. > > > > > > Okay, this seems like it fixed the crash for me: > > > > diff --git a/src/openocd.h b/src/openocd.h > > index 70e3ee0..a91d46f 100644 > > --- a/src/openocd.h > > +++ b/src/openocd.h > > @@ -37,6 +37,6 @@ void openocd_sleep_prelude(void); > > void openocd_sleep_postlude(void); > > > > /// provides a hard-coded command environment setup > > -extern const char *openocd_startup_tcl; > > +extern const char openocd_startup_tcl[]; > > > > #endif > > > > If that works for you, then I'll push it. Why it > works for > > me, I have > > no clear idea... any insight would be welcome. > > > > Cheers, > > > > Zach > > > > _______________________________________________ > > Openocd-development mailing list > > Openocd-development@lists.berlios.de > > > https://lists.berlios.de/mailman/listinfo/openocd-development > > > > > > > > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
