jingham added a comment. I'm out tomorrow, so I won't get a chance for a detailed reply till Monday. But my short reactions are:
1. Setting the breakpoint search to only check base names will of course make all your file and line breakpoints work, but they will also pick up extra hits. In command line lldb that doesn't look nearly as weird as clicking on one source file window & seeing a breakpoint marker show up in a completely different window. If we didn't care about that problem and expected people to manage these extra locations by hand, then indeed just saying "only set using base-names" is fine. But it still seems weird to me that we would add an lldb setting and code to support that rather than have IDE's just only pass in the base name if that's their strategy. 2. I really don't want changing a setting to add or remove locations from an extant breakpoint. That's not how breakpoints work. If I go to the trouble of inputting a command on a location, and the I change a setting and the location goes away, I would rightly be ticked off. So I really think the locations should record whatever search are going to when they are created, and stick to it. However, I have no problem with having the breakpoint store "original path/matched path" pairs if that makes it easier to figure out what is going on. 3. The behind your back creation of source maps gives me the willies. Particularly if you have more than one module with debug information, all built originally in the phony locations so they all look like the original directories have the same root, it seems like you could start getting source maps that map everything to everything and after a while this will get hard to reason about. Maybe I'm being pessimistic, however, and if you are excited to try, more power to you. But I don't think you can drive this from breakpoints alone. Suppose I set no breakpoints, and the program crashes at /OriginalDirectory/SourceRoot/MyProject/subdir/foo.c, lldb is still going to have to figure out what to show the user, so you're still going to have to come up with the real source file. And you can't use your breakpoint tricks to help you because it's lldb providing the information and at the point where you are doing this it only knows the original location. It seems like it would be cleaner to have some kind of callback when a binary with debug information gets loaded where the UI could have a look at the CU's in the module that got loaded, and see if it knows about any of those files locally (because it has them in in directory-equivalent places in its project). The UI can then construct a source map from there. That way this would happen predictably and for all consumers, rather than relying on the user's path through breakpoint setting to set the source mapping world back to rights. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D129307/new/ https://reviews.llvm.org/D129307 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
