<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 11, 2019, at 3:35 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 3:04 PM Adrian Prantl <<a href="mailto:aprantl@apple.com" class="">aprantl@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 11, 2019, at 2:09 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>> wrote:</div><br class="m_-3886603148012731582Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 2:01 PM Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank" class="">aprantl@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class="">You'll see the sad resolution of this two commits further down. (I reverted this one, too). There was a header file with a function body that used the LLVM_DEBUG macro (which I believe fundamentally cannot work inside a non-textual header)<span class="Apple-converted-space"> </span></div></blockquote><div class=""><br class="">Right - if it depends on its inclusion state to define DEBUG_TYPE that's not modular. I assume that's the case? Oh, it looks like it is the case, that DEBUG_TYPE is defined within this file, so I don't think there's a problem with using LLVM_DEBUG here? It's not intended to consume the value of DEBUG_TYPE from its inclusion context.<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><div class="">Oh, I had missed that it did define its own DEBUG_TYPE.</div></div></div><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class="">Perhaps that's invalid in a modular context if it's ever included somewhere that also defines DEBUG_TYPE? I'm not sure there.<br class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class="">and inside of it it called a dump method, thus pulling the reference to the dump method into the link.</div></blockquote><div class=""><br class="">Missed a step here - inside of what it called a dump function? & why was that a problem? It called a dump function unconditionally rather than only under the condition that the dump function is defined? I'm not sure how modules would make/break that.<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><div class="">Perhaps the LLVM_DEBUG macro is a red herring then and just the presence of the dump() function in the function body was enough to produce the dependency on the dump function. The linker error was that that dump() method was an undefined symbol while linking llvm-lto.</div></div></div></blockquote><div class=""><br class="">I'm still not sure I follow how the modularity of this file would be related to this problem - can you explain it in further detail, to make sure we're fixing this in the right way/tracking any other bugs this might be indicative of?<br class=""> </div></div></div></div></blockquote><br class=""></div><div>I don't actually have any further knowledge about how any of this happened. We should be able to reproduce the issue by reverting my removal of the dump() calls, and doing a modular non-LSV build of llvm-lto. I've seen the same symptom before (curiously always with dump methods), and was able to "fix" it every time by moving the offending function body into a .cpp file. I never really bothered to investigate what exactly happened, though, I was mostly concerned with quickly getting the bots running again.</div><div>Something must have marked the function calling the dump method as used, which clearly also was inaccurate.</div><div><br class=""></div><div>-- adrian</div></body></html>