On Wed, Dec 17, 2008 at 11:10:53PM +0100, Michael Schwingen wrote: > [email protected] wrote: > > > >> or speed_table.c should be compiled separately and linked > >> in. > >> > > > > It could be. Would I need to do anything other than add rlink_speed_table.o > > to RLINKFILES in src/jtag/Makefile.am, rename rlink/speed_table.c to > > rlink_speed_table.c, change static speed_table to extern > > rlink_speed_table, and somehow convey how long it is? The latter could, > > of course, just be a const int called rlink_speed_table_length or > > something like that, since I can't use the sizeof trick to tell how large an > > array is if it's defined elsewhere and all the C file using it knows is > > that it's an extern pointer. That would, of course, also require the > > addition of rlink_speed_table.h, which would be included from both > > rlink.c and rlink_speed_table.c, and that leads us well down that > > slippery slope of namespace clutter I alluded to earlier. > > > > It would probably just be a lot easier to rename to .h, than to do this. > > > How big is the table? > > If it is small, generating a .h that is included is fine with me. > However, if it gets bigger (and thus requires substantial time for > compiling the table alone), then a separate .c file (just as you > described - with an additional integer for size, plus a .h with the > prototypes) would be better IMHO.
You can see it by looking in the patch, the table is a pointer and a couple of shorts/chars per speed, and there are currently 4 speeds (though there could be up to 64, depending on certain design decisions). The pointers point to char arrays of 250-300 bytes per speed. Even with the logical extreme of 64 speeds, it oughtn't take too awfully long to compile that. It would take just as long to compile it to its own .o file, anyway. > > Previously, there wasn't even a speed_table.c. The khz/prescaler table > > was directly in rlink.c, and the DTC blobs were loaded from binary files > > at runtime. That still had the same issue of how/when to build those > > files and added the possibility of mismatch between the version of the > > rlink driver and the version of the blob files found on a given system. > > While I generally dislike programs embedding blobs in themselves like > > that, the cons of having the files separate but in the search path > > outweighed the niceness of not embedding. > > > Hm - the XScale target has the same problem: the debug stub that is > downloaded to the target is not compiled-in, but loaded from a binary > file. It seems to work fine as long as the dependency is clearly documented. > > cu > Michael It worked fine, mostly. But I found that searching always searches the builtin path before any specified on the command line, so I was running into problems where testing a not yet installed version would have a mismatch because the blobs for the installed version were getting used. Looking for the binaries in only the install location, besides me not knowing how to find out where that is, would make it impossible to test/run openocd before it is installed, since no files, or the wrong ones, would be found. Granted, the usual case is to run the version of openocd that is installed. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
