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 <[email protected]> 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 <[email protected]> > > 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 > > [email protected] > > https://lists.berlios.de/mailman/listinfo/openocd-development > > > > > > >
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
