This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> An alternative would be to do some canonicalization - not > gdb_realpath, which accesses the filesystem, but just string > manipulation - on the subfile names iff nothing matches the main > file. You could remove the ".." there. Aleksandar liked this option best, but I think I liked your first suggestion more: > > Would this not introduce a bit of guessing? Consider a case where there are > > several files with the same basename but different paths (possibly specified > > using relative path elements, i.e. different pathnames like in my case). In > > this case none of the files with the same base name would perfectly fit and > > picking the first one will likely not give the correct answer. > > It's a guess, but a good one. 99.9% of the time, a C file does not > include another C file with the same basename. If the compiler is > going to generate debug info which refers to the same file by two > different names, I don't see what else we can do. I looked at the whole discussion and at the patches, and they seem pretty simple in the idea, but pretty complex in the implementation. If I undertand the problem correctly, the problem is matching our main.cc entry in the linetable back to the main unit subfile where the name&comp_unit don't exactly match character for character. Right? Going further with the idea that 99.9% of the time, one file does not depend on another file with the same name, then how about doing the matching using basenames? As a starting point, I propose the following idea: Modify start_subfile so that: 1. file name is reduced to a basename only If there is any path information inside name (such as ".." or "/foo/bar/"), it is appended to the dir name. As a special case, if name was an absolute path, then we ignore the dirname and use the dirname from the filename only. 2. subfile matching is done using the basename only. I am attaching a patch that illustrates roughly what I have in mind (not compiled, not tested). The great advantage (if it works :), is that no rewriting is necessary. The reason why I agree that the changes should be done inside start-subfiles is that we don't want to have to handle this sort of problem with every debug info reader. This was, the handling is centralized. It also looks a lot simpler than the patches I have seen that touch the DWARF reader. The one thing that this might break, however, is when the user provides a relative path in the break command: (gdb) break bar/main.c As a matter of fact, this is already broken if DW_AT_name is main.c and not bar/main.c. So I'm pretty sure that it'll break it more. But the good news is that it would be easy to fix it: Modify the matching to concat the dirname and basename and do the match with that. Does this sound like it would work? -- Joel
Attachment:
buildsym.c.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |