Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision Both sides next revision
soc:2009:oremanj:journal:week5 [2009/06/26 21:47]
rwcr
soc:2009:oremanj:journal:week5 [2009/06/26 21:48]
rwcr
Line 137: Line 137:
 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. 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:+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 */   /* in core string code */
   void * core_memcpy ( void *dest, const void *src, int len ) {   void * core_memcpy ( void *dest, const void *src, int len ) {

Navigation

* [[:start|Home]] * [[:about|About our Project]] * [[:download|Download]] * [[:screenshots|Screenshots]] * Documentation * [[:howtos|HowTo Guides]] * [[:appnotes|Application Notes]] * [[:faq:|FAQs]] * [[:doc|General Doc]] * [[:talks|Videos, Talks, and Papers]] * [[:hardwareissues|Hardware Issues]] * [[:mailinglists|Mailing lists]] * [[http://support.etherboot.org/|Bugtracker]] * [[:contributing|Contributing]] * [[:editing_permission|Wiki Edit Permission]] * [[:wiki:syntax|Wiki Syntax]] * [[:contact|Contact]] * [[:relatedlinks|Related Links]] * [[:commerciallinks|Commercial Links]] * [[:acknowledgements|Acknowledgements]] * [[:logos|Logo Art]]

QR Code
QR Code soc:2009:oremanj:journal:week5 (generated for current page)