As context (I haven't followed lldb almost at all), what's the general status of lldb on windows - generally working, or still a work in progress? Does it work with dwarf debug info in COFF (as commonly used in mingw environments), in addition to PDB? I.e. is the existing dwarf support tied to the ELF/MachO formats, or is it decoupled?
It is decoupled. As long as the ObjectFileCOFF hands out the right section for the section enumeration in lldb-enumerations.h in the lldb::SectionType, it should all just work. The enumerations in question are all of the enums that start with eSectionTypeDWARF. It seems to have support in ObjectFilePECOFF::CreateSections(...). So I think it should all just work. Let us know if there are any issues.
I took @xbolva00's suggestion one step further, and removed the usleep and the related compat code in r367814. So, some of your changes are no longer needed once you rebase past that.
I have a couple of additional small comments inline, but other than that, this seems fine. I'm not sure how active is @zturner these days (@amccarth and @stella.stamenova are probably better reviewers for windows stuff now), but this seems pretty straight-forward, so I don't think we have to wait for them.
In r346625, we deleted all/most comments like this. Probably best to not introduce new ones...
It looks like we already have the HAVE_SYS_TYPES_H macro, which we can use for this purpose, so I'd use that, and move it out of the _MSC_VER block as we should really include this header on other platforms too (but we probably haven't done that because it got included transitively already...)
Yes, zturner isn't as active here as he was before.
I'm happy to review patches regarding LLDB on Windows, even though I don't know much about Mingw.
|19 ↗||(On Diff #213175)|
+1. usleep is deprecated in POSIX and is essentially meaningless on Windows (in terms of how the scheduler works) unless you're waiting 1000 or more microseconds. At this point, sleep_for is likely to be better supported by the platforms.
I would suggest moving the #ifndef __MINGW32__ up a line to keep the NOMINMAX adjacent to the include of Windows.h. NOMINMAX is relevant only to Windows.h.
Nothing in the rest of this .cpp file uses PATH_MAX, so just delete the #define instead of executing it conditionally.
Got it. When I asked Phabricator to show me all the lines, it didn't show me _all_ the lines.
That said, it seems unfortunate that it's yet another fixed-length filename buffer instead of getting a ConstString from the FileSpec. But that's outside the scope of this change.
The problem is that you're dealing with the SBFileSpec here, and that makes things slightly complicated (stable api, not being able to return c++ objects through it, etc...).
There's no reason we couldn't add an SBString class to vend non-fixed length strings. There haven't been enough instances where we really needed it to motivate that, but we have SBStringList to wrap vectors of strings, so it wouldn't be out of place.