This is the mail archive of the gdb-patches@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] |
On 18.04.2019 16:49, Eli Zaretskii wrote: > If you put the separate debug file in a global debug directory, GDB on > MS-Windows will currently fail to find it. This happens because we > obtain the directory to look up the debug file by concatenating the > debug directory name with the leading directories of the executable, > and the latter includes the drive letter on MS-Windows. So we get an > invalid file name like > > d:/usr/lib/debug/d:/usr/bin/foo.debug > > + /* MS-Windows/MS-DOS don't allow colons in file names; we must strip > + the drive letter, so that the file name resulting from splicing > + below will be valid. */ > + if (HAS_DRIVE_SPEC (dir_notarget)) > + { > + dir_notarget = STRIP_DRIVE_SPEC (dir_notarget); > + /* We will append a slash to debugdir, so remove the leading > + slash as well. */ > + if (IS_DIR_SEPARATOR (dir_notarget[0])) > + dir_notarget++; > + } > + While this is *a* fix, the result, AFAIU is: d:/usr/lib/debug/usr/bin/foo.debug This is a functional filename, but is it correct? What if the path to "foo" is: c:/some/directory/bin/foo ? In that case your patch will produce: d:/usr/lib/debug/some/directory/bin/foo Actually, no, that's not right. If gdb and 'foo' are in the same tree (this is a valid case, for example, if you're dealing with a mingw installation), then gdb will autodetect debug directory as 'c:/some/directory/lib/debug', and the debug path will be: c:/some/directory/lib/debug/some/directory/bin/foo To make it more obvious: c:/some/directory/mingw/bin/foo + c:/some/directory/mingw/bin/gdb (meaning c:/some/directory/mingw/lib/debug debug directory) will produce c:/some/directory/mingw/lib/debug/some/directory/mingw/bin/foo , if i'm not mistaken. So the problems i see with this approach are: 1) Drive letters are lost (meaning that you can't have two paths with equal names on two different drives be mapped to different debug tree paths - they only differ in the drive letter, and you make that letter disappear) A more correct way to fix this is to replace 'X:/' with 'X/'. 2) This doesn't take runtime tree location into account. Your debug tree has to reflect the absolute, Windows path to the binary (since you're not doing any other adjustments, and since gdb gives you an asbolute, Windows path to begin with), otherwise gdb won't find the debug files. I.e. in the 'c:/some/directory/mingw/lib/debug/some/directory/mingw/bin/foo' example above the second '/some/directory' is clearly incidental, as the user just used that as a root of an installation. The package maintainer can't know where the binaries will end up, and can only predict the '/mingw/bin/foo' part. I.e. the path that gdb should look for should be: c:/some/directory/mingw/lib/debug/mingw/bin/foo or c:/some/directory/mingw/lib/debug/bin/foo (depending on whether we consider '/mingw' or '/' as the root directory; probably the former, although some people might make a case for the latter), and this is where a package manager can put the files (the package will contain '/mingw/lib/debug/bin/foo' debug file, and the package manager will prepend the install root to that path when installing). Note that (1) and (2) somewhat contradict one another. One way to satisfy everyone is to implement all lookups (with the prefix first, then with the absolute path with a drive letter; after that it might even try the without-drive-letter case, or something else, as long as the debug info file isn't found). This is not unheard of - for example, gcc can look for include files in multiple non-existing directories, to support different installation schemes. (the reason why i have such a detailed opinion on the matter is that i've debugged this very code for my latest gdb patch[0], which i submitted last month, and back then i noticed the same behaviour you did). [0]: https://www.sourceware.org/ml/gdb-patches/2019-03/msg00082.html
Attachment:
signature.asc
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |