<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=koi8-r">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>><span style="color: rgb(33, 33, 33); font-size: 12pt;">I</span><span style="color: rgb(33, 33, 33); font-size: 12pt;">f you're interested in things you can do in the linker for this - you might consider something more aggressive: Fully DWARF aware deduplication.</span></p>
<div style="color: rgb(33, 33, 33);">
<div>
<div dir="ltr">><br>
>This could be done hopefully by reusing some of the code in the dsymutil implementation in LLVM.<br>
><br>
>This would be much more effective (and without the possible context-sensitive tradeoffs) than using type units. </div>
<div dir="ltr">>Though it'd possibly have a big tradeoff in link time and/or linker memory usage (I'm not sure how much dsymutil needs/uses of either).<br>
<br>
<span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">+ Rui.</span></div>
<div dir="ltr"><br>
I think LLD development direction vector currently is to avoid teaching linker about things it naturally should not be aware off.</div>
<div dir="ltr">Like it should ideally work with sections as pieces and should not know about content. That is not always possible,</div>
<div dir="ltr">for example we have to look inside .eh_frame to deuplicate FDEs, but that is probably what we would want to avoid in general.<br>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">>It doesn't seem especially important to implement the DWARF5 types -> debug_info thing for this situation, the type units</div>
<div dir="ltr">>as they are (in debug_types) offer the same size benefits here. But sure, if anyone wanted to implement it at some point, that'd be fine.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">But there is no .debug_types in DWARF5, so it is depricated approach as far I understand.<br>
<br>
>I think Paul covered some of the reasons type units might not be a reasonable default.<br>
><br>
>One additional reason is that if you use Split DWARF (another great way to massively reduce the amount of debug info going to the linker)</div>
<div dir="ltr">>type units are mostly /just/ overhead in the .dwo files: since the debug info is not linked, there's no opportunity to remove the</div>
<div dir="ltr">>duplication anyway (unless you're making a DWP - like a >dsym file)<br>
<br>
Yeah. Looks <span style="font-family: monospace; font-size: 13px; background-color: rgb(255, 255, 255);">-gsplit-dwarf</span> and -fdebug-types-section are harmfull together. Probably it worth to restrict using of them together or<br>
</div>
<div dir="ltr">emit a warning (both clang and gcc silently allows the combination and output has size penalty you describing).<br>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">But then does it make sence to emit multiple .debug_info sections with <span style="color: rgb(33, 33, 33); font-family: monospace; font-size: 13px; background-color: rgb(255, 255, 255);">-gsplit-dwarf</span>, so that objects will contain skeleton
.debug_info and<br>
</div>
<div dir="ltr">.debug_info sections with type units as described in DWARF5. So that linker will be able to do deduplication of<br>
</div>
<div dir="ltr">types on a sections level as expected ?<br>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">George.<br>
</div>
</div>
</div>
</body>
</html>