I meant the location of the minidump. So if you have C:\A\B\C\foo.dmp which is the dump file for bar.exe which crashed on another machine, then it would look for C:\A\B\C\bar.pdb. That actually seems like fairly intuitive behavior to me, but maybe I'm in the minority :)
We can see what Pavel, Adrian, and others think though or if they have any other suggestions. On Tue, Dec 11, 2018 at 11:21 AM Leonard Mosescu <mose...@google.com> wrote: > But if the minidump and PDBs are in the same directory, then wouldn't my >> proposed solution also work (while also being a permanent solution)? >> > > If we're looking in the same directory as the binary file (which is how I > read your suggestion) then it would not be found in this case, since the > binary path is coming from the machine where the crash occurred (so there's > no relation with the host where we run LLDB). Using the minidump location > as search path seems an even bigger hack than searching the current > directory. > > Speaking of the current directory, I still don't like to use it implicitly > in general, but it's actually consistent with what LLDB does for DWARF (see > Symbols::LocateExecutableSymbolFile). So maybe it's not the terrible hack I > made it look like. > > On Tue, Dec 11, 2018 at 10:48 AM Zachary Turner <ztur...@google.com> > wrote: > >> But if the minidump and PDBs are in the same directory, then wouldn't my >> proposed solution also work (while also being a permanent solution)? >> >> On Tue, Dec 11, 2018 at 10:47 AM Leonard Mosescu <mose...@google.com> >> wrote: >> >>> We talked about this offline, but bringing the discussion back here. >>>> Can you describe the use case that this is addressing? As you mention, >>>> this is a temporary hack until we have proper symbol searching logic, but >>>> proper symbol searching logic will do more than just look up symbols in a >>>> symbol server. It will also, for example, look in the same directory as >>>> the executable file. If we changed this logic to do that, would your use >>>> case still be addressed? At least that way, the logic we're adding is not >>>> temporary, even if it will eventually live in a different place (e.g. the >>>> SymbolVendor). >>>> >>> >>> This is intended to provide an easy way to experiment with minidumps + >>> PDBs: just copy the minidump and the PDBs in the same directory (and run >>> lldb from there). >>> >>> It's far from a general solution. I don't think that defaulting to the >>> current directory should even be a hardcoded default - it's just a >>> convenient but temporary hack. I'm open to any alternative ideas we can use >>> until we implement a SymbolVendor. >>> >>> On Tue, Dec 11, 2018 at 10:39 AM Zachary Turner via Phabricator < >>> revi...@reviews.llvm.org> wrote: >>> >>>> zturner added inline comments. >>>> >>>> >>>> ================ >>>> Comment at: >>>> source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:139-144 >>>> + llvm::consumeError(expected_binary.takeError()); >>>> + pdb_file = obj_file.GetFileSpec() >>>> + .GetFileNameStrippingExtension() >>>> + .GetStringRef() >>>> + .str(); >>>> + pdb_file += ".pdb"; >>>> ---------------- >>>> We talked about this offline, but bringing the discussion back here. >>>> Can you describe the use case that this is addressing? As you mention, >>>> this is a temporary hack until we have proper symbol searching logic, but >>>> proper symbol searching logic will do more than just look up symbols in a >>>> symbol server. It will also, for example, look in the same directory as >>>> the executable file. If we changed this logic to do that, would your use >>>> case still be addressed? At least that way, the logic we're adding is not >>>> temporary, even if it will eventually live in a different place (e.g. the >>>> SymbolVendor). >>>> >>>> >>>> CHANGES SINCE LAST ACTION >>>> https://reviews.llvm.org/D55142/new/ >>>> >>>> https://reviews.llvm.org/D55142 >>>> >>>> >>>> >>>>
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
