[lldb-dev] Dealing with executable libraries
Greg Clayton via lldb-dev
lldb-dev at lists.llvm.org
Mon Oct 5 17:02:05 PDT 2015
It would be ok to relax the test for eTypeExecutable to also allow eTypeSharedLibrary if, on many systems, it is possible to run a binary of type shared library as an executable. If it changes from system to system, then we could ask the platform (PlatformLinux if your case?) to verify if a binary can be an executable. So adding a virtual method to lldb_private::Platform:
namespace lldb_private
{
class Platform
{
virtual bool
IsValidExecutable (lldb_private::Module &module);
};
}
The default could check for eTypeExecutable only and the PlatformLinux could check for eTypeExecutable or eTypeSharedLibrary...
Greg
> On Oct 5, 2015, at 3:43 AM, Stefan Kratochwil via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>
> Hi,
>
> I am wondering how to deal with binaries that are both executable and
> dynamic objects, such as many executables under /usr/sbin.
>
> When I try to attach to a process (e.g. apache2) using the method
> lldb::SBTarget::AttachToProcessWithID() (C++ flavor of the LLDB
> ScriptingBridge), the method ObjectFileELF::CalculateType() returns
> eTypeSharedLibrary, which results in an error in my application.
>
> The error object, which is given by
> lldb::SBTarget::AttachToProcessWithID() has the Fail() flag set, but no
> CString() with an actual cause. The lldb::SBProcess::IsValid() method
> returns false.
>
> Right now I am short circuiting CalculateType() by returning
> eTypeExecutable when LLDB detects a dynamically linked object, but there
> must be a less intrusive solution. Is there a way to force LLDB to
> recognize such executables as "real" executables, without tampering LLDB
> internals?
>
> Thanks in advance!
>
> Cheers,
> Stefan
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
More information about the lldb-dev
mailing list