https://github.com/labath commented:
It seems rather wasteful (and error-prone) to repeat the search through the support files of a compile unit, given that ResolveSymbolContextForFilePath has already searched through them and told us that the CU really does contain a file with the given name. The problem is that the return value is just the CU itself, so all the information we get is "the file is *somewhere* in this CU". However, this function is also (and primarily) used for setting file+line breakpoints, and you definitely can set breakpoints in the header files. So, how does that work? When setting a breakpoint, we pass eSymbolContextLineEntry to the function so that it returns a line entry matching the query. In this case, we're not really interested in the entire line entry, but I think it should be possible the line entry as a carrier for the file name: we ask for the function to fill it out, and then fetch the file from there. Can you see if that works? I also think that changing `0` to `start_line` was not right change. Since we're not actually line entry (just the file name, we'll extract the lines ourselves), we want to maximize our chances of finding a matching line entry. If it cannot find an exact file+line match, `ResolveSymbolContextForFilePath` will return a line entry for any line that comes after it. Using zero ensures we don't skip any line entries. https://github.com/llvm/llvm-project/pull/139002 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
