Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2009:oremanj:journal:week5 [2009/06/26 21:32] rwcr |
soc:2009:oremanj:journal:week5 [2009/06/26 22:26] (current) rwcr |
||
|---|---|---|---|
| Line 114: | Line 114: | ||
| The issue I noted in the last paragraph of yesterday's entry was not quite so bad as it seemed; after accounting for different header bytes and different version numbers, for gPXE's purposes the bulk of the WPA and RSN information elements can be parsed identically. Huzzah. The two versions still have some respective idiosyncracies in the handling of the 4-Way Handshake (which is next up on the list of things to write), but the ''wpa_supplicant'' code is a good reference for that. | The issue I noted in the last paragraph of yesterday's entry was not quite so bad as it seemed; after accounting for different header bytes and different version numbers, for gPXE's purposes the bulk of the WPA and RSN information elements can be parsed identically. Huzzah. The two versions still have some respective idiosyncracies in the handling of the 4-Way Handshake (which is next up on the list of things to write), but the ''wpa_supplicant'' code is a good reference for that. | ||
| - | Today I moved all the helper functions that will only be needed when some encryption method is supported into a separate file, ''sec80211.c'', so they don't bloat the code size in wireless builds that don't use encryption. There's one chink in that: the main wireless probe code needs to be able to differentiate fully between the various types of secured network even if they're not all supported, as WPA looks like WEP to a client that knows nothing about WPA. So ''net80211_probe_step()'' has to call ''sec80211_detect()'', but we don't want that call to pull in ''sec80211.c'' if nothing else needs it. | + | I now offer an interlude of Cool Linker Tricks. |
| + | |||
| + | One of the things I did today was move all the helper functions that will only be needed when some encryption method is supported into a separate file, ''sec80211.c'', so they don't bloat the code size in wireless builds that don't use encryption. There's one chink in that: the main wireless probe code needs to be able to differentiate fully between the various types of secured network even if they're not all supported, as WPA looks like WEP to a client that knows nothing about WPA. So ''net80211_probe_step()'' has to call ''sec80211_detect()'', but we don't want that call to pull in ''sec80211.c'' if nothing else needs it. | ||
| Enter a very handy and underused linker feature: weak symbols! | Enter a very handy and underused linker feature: weak symbols! | ||
| Line 133: | Line 135: | ||
| If ''snazzy.o'' would not be pulled into the link by an ordinary ("strong") symbol reference, a weak reference alone isn't going to be enough to pull it in. Instead, the linker defines ''snazzy.o'''s referenced weak symbols to be ''NULL'' pointers, and code that wants to conditionally use ''check_snazzy()'' just needs to test it against ''NULL'' before using it. While this example is obviously contrived, the technique can be very useful. | If ''snazzy.o'' would not be pulled into the link by an ordinary ("strong") symbol reference, a weak reference alone isn't going to be enough to pull it in. Instead, the linker defines ''snazzy.o'''s referenced weak symbols to be ''NULL'' pointers, and code that wants to conditionally use ''check_snazzy()'' just needs to test it against ''NULL'' before using it. While this example is obviously contrived, the technique can be very useful. | ||
| - | This is rather messy, of course; the fewer symbols with an implicit "might-be-NULL" attached the better. But for fairly tightly-coupled source files that need to be separated for size reasons, one or two weak functions can provide an excellent interface between the two. If nothing else, it's another tool in our bag of code-size reduction tricks :-) | + | This is rather messy, of course; the fewer symbols with an implicit "might-be-NULL" attached the better. But for fairly tightly-coupled source files that need to be separated for size reasons, one or two weak functions can provide an excellent interface between the two. |
| + | While we're in the Cool Linker Tricks department, there's also something called a "weak alias", which serves a completely different purpose: providing one implementation of an API function while allowing it to be superseded without complaint by another object file. I haven't seen anything in gPXE that really needs this, but to give an example of how it //could// be used, gPXE core defines a simple ''memcpy()'' function that doesn't know about any architecture-specific optimizations, but only declares its prototype if the preprocessor macro ''%%__HAVE_ARCH_MEMCPY%%'' hasn't been defined by architecture-specific includes; that allows architecture-specific string functions to be used instead, using either ''#define'' or an inline implementation, but no symbol can be named ''memcpy'' because the linker would complain. A way around that would be: | ||
| + | /* in core string code */ | ||
| + | void * core_memcpy ( void *dest, const void *src, int len ) { | ||
| + | /* ... */ | ||
| + | } | ||
| + | | ||
| + | void * memcpy ( void *dest, const void *src, int len ) | ||
| + | __attribute__ (( weak, alias ( "core_memcpy" ) )); | ||
| + | Then architecture-specific code could just define ''memcpy'' directly, no preprocessor tricks needed, and it would supersede the core version. Again, I don't think anything needs this at this point, but it's cool to know - maybe it'll even come in handy someday! :-) | ||
