[lldb-dev] Platform::GetFile overloaded virtual function

Greg Clayton gclayton at apple.com
Wed Jan 15 10:05:34 PST 2014

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.


On Jan 15, 2014, at 8:37 AM, Steve Pucci <spucci at google.com> wrote:

> 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
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

More information about the lldb-dev mailing list