Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/30844 )
Change subject: string.h: allow to compile strdup in romstage ......................................................................
Patch Set 6:
So strategy from here, move the bigger implementations into their own compilation unit? I wouldn't mind keeping some of the lighter functions inline. But would we then add the new compilation unit to romstage just for the `dead_code` mes- sage?
I'd say that's probably a good idea to get more in line with what other codebases (e.g. libpayload) do. I think these string functions aren't actually *that* short or that important that they deserve special treatment over all the other short functions that we don't inline. If you're really worried about performance for those, the better thing to do would probably be to transform them into real functions and provide faster assembly versions. Linking a .c version into romstage shouldn't be a problem because if you don't call strdup(), the whole function will still be garbage-collected out (but if you do call it, you still get the nicer compile-time error from dead_code()).
But that's not really related to this patch... I found the issue that's causing the include problems. Fix at CB:31084.