
<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 2, 2020, at 4:42 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: Menlo-Regular; 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=""><div class="">Is there/could you further explain the use-case for adding an index to an existing binary? Certainly not the worst idea/could come in handy sometimes, but you mention benchmarking - is the benefit of not recompiling/relinking that significant to such experiments?<br class=""></div></div></div></blockquote><div><br class=""></div>It is hard to get people to adopt new toolchains into their workflows. So the idea here is to allow people to use what ever toolchains they want to to produce a binary, then add accelerator tables to their linked binaries so they can "try before you buy" kind of thing. It also allows accelerator tables to be updated in case there were bugs in older versions of the tools, or as new accelerator tables come out or newer versions are available. Once we prove that the accelerator tables are viable and worth it, we get people to want to migrate to newer toolchains that have this functionality built in. <br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; 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=""><div class=""><br class="">If it's not for use in a common workflow, but only in a compiler/debugger development workflow, it doesn't seem so important to me.</div></div></div></blockquote><div><br class=""></div>It is for production workflows for people that are on older toolchains and are not able to upgrade for stability to business purposes. So it isn't just for compiler/debugger development. </div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; 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=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 2, 2020 at 3:50 PM Greg Clayton via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</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 class="">We could specify ELF support for the --update feature only for now, which adds the accelerator tables adding support. For full linking to work, we will need some sort of ELF specific of stand alone debug map file that can be read for real linking, though that won't be too hard.<br class=""></div></blockquote><div class=""><br class="">Not sure I follow here - --update would be given a fully linked binary, yes? So why would it need a debug map?</div></div></div></div></blockquote><div><br class=""></div><div>It wouldn't. If you take a look at the dsymutil code though, they did some hackery to make it pretend like it is relinking the DWARF. So no debug map is needed, but dsymutil will run it through the same kind of machinery. But that being said, it would be very easy to repurpose this code to take a linker map for ELF and become the linker for DWARF in .o files in LLD (where it does smart linking, not just concatenate and relocate like most linkers currently do).</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; 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=""><div class="gmail_quote"><div class=""> It'd have the debug info & the linked executable code available, so you'd be able to see which bits of the executable code are referred to by which bits of debug info.<br class=""></div></div></div></div></blockquote><div><br class=""></div><div><div>--update was in the original dsymutil that I wrote and it would just update the accelerator tables in the dSYM file and rewrite the binary and exit. There were a few iterations of the accelerator tables and this allowed us to quickly update older and out of date versions. The llvm-dsymutil has this feature and also allows you to specify DWARF5 or Apple accelerator tables. </div><div class=""><br class=""></div></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; 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=""><div class="gmail_quote"><div 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 class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 2, 2020, at 3:44 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank" class="">echristo@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">I'd like it... Adrian? Fred?<div class=""><br class=""></div><div class="">-eric</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 2, 2020 at 3:44 PM Greg Clayton <<a href="mailto:clayborg@gmail.com" target="_blank" class="">clayborg@gmail.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 class="">Yes. I am fine with adding ELF support to llvm-dsymutil if that is the way people think we should go?<br class=""></div></blockquote></div></div></blockquote></div></div></blockquote><div class="">Feels like a bit of a weird fit to me (equally llvm-objcopy seems like a weird fit too) - given the specific name & nature of Darwin debug info distribution being a bit different (reading object files, having input from the linker, etc) & the specific name being pretty uniquely applied to that model/output.<br class=""><br class="">(does that way lie moving dwp functionality to llvm-dsymutil too? )<br class=""><br class="">But don't feel super strongly about any of it. <br class=""></div></div></div></div></blockquote><div><br class=""></div></div>I'd be fine with making a new "llvm-dwarfld" tool if we think that is the way to go. The main issue is there would be a lot of duplicated code between llvm-dsymutil and llvm-dwarfld. </body></html>