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.

View Change

To view, visit change 30844. To unsubscribe, or for help writing mail filters, visit settings.