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


On Jan 15, 2014, at 8:37 AM, Steve Pucci <[email protected]> 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
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to