{"id":100165,"date":"2018-11-08T07:00:00","date_gmt":"2018-11-08T22:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=100165"},"modified":"2021-02-13T07:33:17","modified_gmt":"2021-02-13T15:33:17","slug":"20181108-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20181108-00\/?p=100165","title":{"rendered":"Gotchas when using linker sections to arrange data, part 1"},"content":{"rendered":"

We saw last time<\/a> that you can use linker sections to arrange the order in which data appears in the module. We ended with a diagram like this:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
mydata$a<\/code><\/td>\nfirstInitializer<\/code><\/td>\nmain.obj<\/code><\/td>\n\u00a0<\/td>\n<\/tr>\n
mydata$g<\/code><\/td>\nDoThisSooner3<\/code><\/td>\nfile3.obj<\/code><\/td>\nunspecified
\norder<\/td>\n<\/tr>\n
DoThisSooner4<\/code><\/td>\nfile4.obj<\/code><\/td>\n\u00a0<\/td>\n<\/tr>\n
mydata$m<\/code><\/td>\nFunction2<\/code><\/td>\nfile2.obj<\/code><\/td>\nunspecified
\norder<\/td>\n<\/tr>\n
Function1<\/code><\/td>\nfile1.obj<\/code><\/td>\n<\/tr>\n
Function3<\/code><\/td>\nfile3.obj<\/code><\/td>\n<\/tr>\n
mydata$t<\/code><\/td>\nDoThisLater2<\/code><\/td>\nfile2.obj<\/code><\/td>\nunspecified
\norder<\/td>\n<\/tr>\n
DoThisLater4<\/code><\/td>\nfile4.obj<\/code><\/td>\n<\/tr>\n
mydata$z<\/code><\/td>\nlastInitializer<\/code><\/td>\nmain.obj<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Based on this table, we would be tempted to write code like this:<\/p>\n

\/\/ Code in italics is wrong.\r\nvoid NaiveInitializeAllTheThings()\r\n{\r\n    const INITIALIZER* initializer = &firstInitializer + 1;\r\n    while (initializer < &lastInitializer) {\r\n      (*initializer++)();\r\n    }\r\n}<\/i>\r\n<\/pre>\n
From a language lawyer standpoint, this code is not valid because it dereferences a pointer beyond the end of an object, and because it compares two pointers which are not part of the same aggregate. We can fix this by switching to uintptr_t<\/code> as our currency.<\/p>\n
\/\/ Code in italics is still wrong.\r\nvoid LessNaiveInitializeAllTheThings()\r\n{\r\n    auto begin = (uintptr_t)&firstInitializer\r\n                 + sizeof(firstInitializer);\r\n    auto end = (uintptr_t)&lastInitializer;\r\n    for (auto current = begin; current < end;\r\n         current += sizeof(INITIALIZER)) {\r\n      auto initializer = *(const INITIALIZER*)current;\r\n      initializer();\r\n    }\r\n}<\/i>\r\n<\/pre>\n
The conversion between pointers and uintptr_t<\/code> is implementation-defined (rather than undefined), so this avoids the undefined behavior problems of using pointers to walk between two global variables.<\/p>\n
But the code is still not right, because it fails to take into account another detail of linker sections: intra-section padding.<\/p>\n
The linker will add padding after a fragment in order to satisfy any alignment requirements of the subsequent fragment. That’s expected.<\/p>\n
What most people aren’t aware of is that the linker is permitted but not required to add padding after each fragment, up to the section’s alignment. In practice, you are likely to see this “unnecessary” padding when using  incremental linking<\/a>.<\/p>\n
In all cases, the padding bytes (if any) will be zero.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
mydata$a<\/code><\/td>\nfirstInitializer<\/code><\/td>\nmain.obj<\/code><\/td>\n\u00a0<\/td>\n<\/tr>\n
Optional padding<\/td>\n\u00a0<\/td>\n<\/tr>\n
mydata$g<\/code><\/td>\nDoThisSooner3<\/code><\/td>\nfile3.obj<\/code><\/td>\nunspecified
\norder<\/td>\n<\/tr>\n
Optional padding<\/td>\n\u00a0<\/td>\n<\/tr>\n
DoThisSooner4<\/code><\/td>\nfile4.obj<\/code><\/td>\n\u00a0<\/td>\n<\/tr>\n
Optional padding<\/td>\n\u00a0<\/td>\n<\/tr>\n
mydata$m<\/code><\/td>\nFunction2<\/code><\/td>\nfile2.obj<\/code><\/td>\nunspecified
\norder<\/td>\n<\/tr>\n
Optional padding<\/td>\n\u00a0<\/td>\n<\/tr>\n
Function1<\/code><\/td>\nfile1.obj<\/code><\/td>\n<\/tr>\n
Optional padding<\/td>\n\u00a0<\/td>\n<\/tr>\n
Function3<\/code><\/td>\nfile3.obj<\/code><\/td>\n<\/tr>\n
Optional padding<\/td>\n\u00a0<\/td>\n<\/tr>\n
mydata$t<\/code><\/td>\nDoThisLater2<\/code><\/td>\nfile2.obj<\/code><\/td>\nunspecified
\norder<\/td>\n<\/tr>\n
Optional padding<\/td>\n\u00a0<\/td>\n<\/tr>\n
DoThisLater4<\/code><\/td>\nfile4.obj<\/code><\/td>\n<\/tr>\n
Optional padding<\/td>\n\u00a0<\/td>\n<\/tr>\n
mydata$z<\/code><\/td>\nlastInitializer<\/code><\/td>\nmain.obj<\/code><\/td>\n<\/tr>\n
Optional padding<\/td>\n\u00a0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
To accommodate padding, we need to skip over any possible null pointers.<\/p>\n
void InitializeAllTheThings()\r\n{\r\n    auto begin = (uintptr_t)&firstInitializer\r\n                 + sizeof(firstInitializer);\r\n    auto end = (uintptr_t)&lastInitializer;\r\n    for (auto current = begin; current < end;\r\n         current += sizeof(INITIALIZER)) {\r\n      auto initializer = *(const INITIALIZER*)current;\r\n      if (initializer)<\/span> initializer();\r\n    }\r\n}\r\n<\/pre>\n
We’ll look at another consequence of padding  next time<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
Nulls can show up in unexpected places.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25,131],"class_list":["post-100165","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code","tag-linker"],"acf":[],"blog_post_summary":"
Nulls can show up in unexpected places.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/100165","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=100165"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/100165\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=100165"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=100165"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=100165"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}