<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/65098>65098</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Tool to build `.build-id` and/or debuginfod directory layouts by scanning binaries
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            enhancement,
            llvm-tools,
            debuginfod
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
            mysterymath
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          mysterymath
      </td>
    </tr>
</table>

<pre>
    Tools that look up debug binaries by their build IDs usually do so by making a request with some path including the build ID. Consider a build ID: `abcdef`. For the older GDB-style lookups, the debug binary is to be found at `.build-id/ab/cdef` relative to some configured or built-in directory. For debuginfod lookups, this is e.g. a HTTP GET request path `/buildid/abcdef/debuginfo`. Notably, if a directory were laid out with this path schema, then a regular HTTP file server would function as a debuginfod server.

Accordingly, it would be nice if there were a LLVM utility that could automatically create such structures. This could be useful either when creating older `.build-id` paths as part of the build step, or to prepare a package to be served as debuginfod using a HTTP file server.

The latter usage is already provided by the debuginfod server, which scans a directory for object files and prepares internally a mapping from debuginfod path to found binary. This scanning is expensive, and the mapping produced is ephemeral in our implementation, and maintained as a implementation-defined SQ cache in elfutils debuginfod. Neither is particularly amenable to analysis. Accordingly, this scanning logic could be separated out and form the basis of this tool; it would scan a directory using the same logic, and place the results into an output directory with a layout that captures the relationship between binary and build ID.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJxkVU9v5LYP_TSeCxHDkZNB5jCH7OY3-yuwXbRo0Dst0WN1ZckVpUz97QvKnn_pZQawSL7Hx0cJme3RE-2r5y-VUuPMieI8Yhoqparntw3mNIS4vznYdMHM-_cQHEMaMIEL4SfkCQx1-Qid9RgtMXQzpIFshC5bZ-CXN4bMGZ2bwQTgIAEj_rT-CAiR_s7ECU42DcBhJJgwDWC9dtlISBroUqiGr8GzNRQBLx-r9hWqbYOdNtRX26aGQ4glLTiJ_Pb25YHT7KjwzRNX6ms5vqE9g2VIATqCPmRvAJPUrAvGgzWVOmBXqcMKAZEcJvtBklNI6-B7e8yRDISl8fRgPRgbSacQ54VUQbS-D-aei2XBp_pYA8L_399_g2__e79IUwSptk2lDoXPSqdwUYdLzdL6j5Cwc7OUtT3glQCcKBI4tAZCXuUuwKU664FGXIXxZSzH7DAuZHrrCJjiB0U4hewM9NnrZIMHZAG5trVE1VXzVjWvy--r1iHKKFdaaa3REXirSXimQcgVhgjfv__5K-RknU3z4jNd4jGnMGKyujhJR8JEwFkPwClmnXIkruFdetJngMzUZwdkBQFO0ltJFGMt7rib8rYpcrC0NWFMEPob_3GiSToQdwWYIk1YCE-of-KRVv8UBYxUuJEl8-L2z3LeCfU-yIBSogiZpaBlQBcJzQxTDB_WkFmX67-SC7HTYEUNjZ7vRt-HCKH7i3Qq2AzozZk_g_WJoi-iIow4TUK1j2G8BSkuSWHdjmVnVrEFz0uOWPifiTzbDxI6giJczzWnGEzWZErgNNBIER1YDyFHsOPkaCSfUHx1Th_R-oTWL4Lip6gHQ305--N30KgHkmLkejHPrfw1_FgdYJe5Wi3mloZH8ti5Mjv06Ga2XMMnx6a7Ll04Wn11GIuKmGhZK-HchzgurkG2vFio3C7BVe2Xq_-l4t2YFpNIJuNIC9BZiMmhpnIWibNLZWzCWWCnnG4XXVYbweEsjJYFwqmsx1rAFfV4sBN0lE5E_nwLCtTlst2YfWt27Q43tH_c7tr2aff48rwZ9kYjUrvbPW6xeWx0p3YdPpIyLxqfnvQjbexeNaptXtROqaetauvnl61RjVbYomr1c189NTSidbVzH2Md4nFjmTPtt8_N7mXjsCPH68tEfkCvy9DlZVJfK6Uk60EE5cun67TX9yvuS1SXj1w9Nc5y4itasslRecrK1paOP98E6OWevb-1ryov8pbH7mKN8wu4ydHth5QmrtrXSh0qdTjaNOSu1mGs1EForH8PUwyymJU6FAW4Uociwr8BAAD__1FWrZM">