<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in locate-pdb.lldbinit</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>479f5bfd - [LLDB] Improve PDB discovery</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/lldb/test/Shell/SymbolFile/NativePDB/Inputs/locate-pdb.lldbinit#479f5bfd</link>
        <description>[LLDB] Improve PDB discoveryWhen loading a PE/COFF target, the associated PDB file often wasn&apos;tfound.  The executable module contains a path for the associated PDBfile, but people often debug from a different directory than the onetheir build system uses.  (This is especially common in post-mortemand cross platform debugging.)Suppose the COFF executable being debugged is `~/proj/foo.exe`, butit was built elsewhere and refers to `D:\remote\build\env\foobar.pdb`,LLDB wouldn&apos;t find it.With this change, if no file exists at the PDB path, LLDB will lookin the executable directory for a PDB file that matches the name ofthe one it expected (e.g., `~/proj/foobar.pdb`).  If found, the PDBis subject to the same matching criteria (GUIDs and age) as wouldhave been used had it been in the original location.This same-directory-as-the-binary rule is commonly used by debuggerson Windows.Differential Review: https://reviews.llvm.org/D84815

            List of files:
            /llvm-project-15.0.7/lldb/test/Shell/SymbolFile/NativePDB/Inputs/locate-pdb.lldbinit</description>
        <pubDate>Wed, 29 Jul 2020 00:45:33 +0000</pubDate>
        <dc:creator>Adrian McCarthy &lt;amccarth@google.com&gt;</dc:creator>
    </item>
</channel>
</rss>
