
<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;">>Postprocessing (ie: running a tool on the fully linked binary with the debug info we have today, and having the tool reprocess the debug info to make it more >compact) is an option, but wouldn't help

 address the problem you started with - that the output can't fit the large offsets, so the output is invalid/broken. So that >output would be broken before the postprocessing step could run to compact things.</span><br>

</p>

<p><br>

</p>

<p>Right. So then it could be some API that takes .debug_* sections from linker, takes relocations, additional info,<br>

</p>

<p>like info about GCed/ICFed sections. It could rebuild debug data, rebuild relocations and return it back to linker,<br>

</p>

<p>so it could take deduplicated debug info, perform updated relocations and produce output.<br>

</p>

<p><br>

</p>

<p>Does not feel nice honestly. It is definetely seems easier to do all of that on linker side instead.<br>

</p>

<p><br>

</p>

<p>George.<br>

</p>

<p><br>

</p>

<p><br>

</p>

</body>

</html>