Platform::GetFile overloaded virtual function

Subprojects LLDB
1

Hi all,

Platform::GetFile is an overloaded method with two signatures:

virtual Error
GetFile (const FileSpec &platform_file,
const UUID *uuid_ptr,
FileSpec &local_file);
…
virtual Error
GetFile (const FileSpec& source,
const FileSpec& destination);

The first has a large comment block and a working base-class implementation. The second has an error implementation in the base class and no documentation. Only PlatformPosix redefines the second one, but API/SBPlatform.cpp uses it, which seems to imply that SBPlatform.cpp will only work with PosixPlatform. I’m not sure what SBPlatform’s intended use is but it uses base-class PlatformSP pointers so it seems like this might be a bug.

As you may know this situation results in the second signature being hidden in all derived classes that implement the first signature but not the second, which is most of them. gcc gives a warning about this hiding, which is one reason I’m trying to track it down, but it seems like something’s not quite right about this anyway… I could silence gcc’s warnings by a “using Platform::GetFile” in the derived classes, but I want to verify if there’s a real problem before I do that.

Thanks,
Steve

2

Oops, sorry, “make -k” wasn’t doing what I thought it would. There are in fact other places that use the first signature, for example “CommandObjectPlatformGetFile” (implementing 'lldb platform get-file"). This also seems like a bug somewhere, as it won’t work with all platforms (since the base class just gives an error).

3

It might be easier to rename the GetFile that takes a UUID to be GetFileWithUUID(...) to avoid having to use the using directives.

On MacOSX we have UUIDs built into all mach-o files for each architecture slice and we sometimes know we are looking for an executable with a specific UUID after the dynamic loader tell use we want /usr/lib/libfoo.dylib with UUID XXXXX. We also have system services that we can query saying "please locate a debug symbol file for UUID XXXX", so even if the path is wrong, we might be able to find the file we are looking for if the "platform_file" path is incorrect.

Greg

4

Thanks, Greg. I'm still a bit confused about the implementation of GetFile
without the UUID, though. Is it a bug that this method isn't implemented
on all of the Platform implementations? I guess, in any case, it would be
better to avoid the confusion by renaming the other method, though, as you
propose. I'll do that.

Thanks again,
   Steve

5

Thanks, Greg. I'm still a bit confused about the implementation of GetFile without the UUID, though. Is it a bug that this method isn't implemented on all of the Platform implementations?

The other platforms _should_ be implementing this and yes it is a bug on those platforms that require this support. Platforms are optional and not all functions need to be supported just to call a platform a platform. So this is desired, but not mandatory. It is required if you want to support getting remote files, so any platform that wants to support running a remote test suite should support this function.

I guess, in any case, it would be better to avoid the confusion by renaming the other method, though, as you propose. I'll do that.

Sounds good.

6

OK, thanks.