[lldb-dev] Not able to find process plugin for core file
Hi All, I am working on adding support for MIPS coredump file in LLDB. I tried below command: (lldb) target create "app_mips.elf" --core "core_mips" error: Unable to find process plug-in for core file '/home/battarde/test/ core_mips' Currently LLDB is not able to find a Process plugin for MIPS core file. I debugged this and found that while finding the process plugin, "ProcessElfCore::CanDebug" calls "ModuleList::GetSharedModule" to create a Module for corefile. But Module constructor in Module.cpp has this: // First extract all module specifications from the file using the local // file path. If there are no specifications, then don't fill anything in ModuleSpecList modules_specs; if (ObjectFile::GetModuleSpecifications(module_spec.GetFileSpec(), 0, 0, modules_specs) == 0) return; The issue here is that the targets like MIPS depends on elf flags to determine the actual architecture but core file doesn't contain any arch information (header.e_flags is 0) so it can't decide the arch contained in core file. As no specifications are found, Module constructor takes an early exit leaving its members uninitialized. Going further, Module also fails to get the ObjectFile representation as it doesn't contain enough information (Module::m_file, Module::m_arch) required to get ObjectFile. So, "ProcessElfCore::CanDebug" returns false and because of this LLDB gives error saying that it is unable to find process plug-in for core file. I can make mipsVariantFromElfFlags() to return some default architecture (to ensure we always have valid arch when it can't be decided from elf flags) but this won't always work (core's default arch and executable_elf's arch may not "match" always). What could be the proper fix to this issue? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Not able to find process plugin for core file
Hi Greg, I tried specifying a full triple but it's still the same issue. (lldb) target create --arch=mips64el-pc-linux "coredump.elf" --core "core_mips" error: Unable to find process plug-in for core file '/home/battarde/test/core_mips' LLDB correctly recognises that "core_mips" is a core file and creates an appropriate Process instance (i.e ProcessElfCore). But then "ProcessElfCore::CanDebug" fails as it cannot create a complete Module because it cannot find any architecture in that core file. Everything in the triple for the core file "core_mips" remains "Unknown" here i.e UnknownArch-UnknownVendor-UnknownOS/UnknownEnvironment. What happens here is, "ObjectFileELF::GetModuleSpecifications" has this: const uint32_t sub_type = subTypeFromElfHeader(header); spec.GetArchitecture().SetArchitecture(eArchTypeELF, header.e_machine, sub_type, header.e_ident[EI_OSABI]); subTypeFromElfHeader(header) returns ArchSpec::eMIPSSubType_unknown (as header.e_flags is 0). Then SetArchitecture called with cpu=llvm::ELF::EM_MIPS and sub_type=ArchSpec::eMIPSSubType_unknown fails to find a ArchDefinitionEntry because there ins't any ArchDefinitionEntry in g_elf_arch_entries for this cpu/subtype combination. This in turn leaves everything in triple as "Unknown" and the ArchSpec created for core file remains Invalid. -Bhushan -Original Message- From: Greg Clayton [mailto:gclay...@apple.com] Sent: 11 March 2016 02:31 To: Bhushan Attarde Cc: lldb-dev@lists.llvm.org Subject: Re: [lldb-dev] Not able to find process plugin for core file > On Mar 10, 2016, at 4:34 AM, Bhushan Attarde via lldb-dev > wrote: > > Hi All, > > I am working on adding support for MIPS coredump file in LLDB. > > I tried below command: > > (lldb) target create "app_mips.elf" --core "core_mips" > error: Unable to find process plug-in for core file '/home/battarde/test/ > core_mips’ > > Currently LLDB is not able to find a Process plugin for MIPS core file. I > debugged this and found that while finding the process plugin, > "ProcessElfCore::CanDebug" calls "ModuleList::GetSharedModule" > to create a Module for corefile. But Module constructor in Module.cpp has > this: > > // First extract all module specifications from the file using the local > // file path. If there are no specifications, then don't fill anything in > ModuleSpecList modules_specs; > if (ObjectFile::GetModuleSpecifications(module_spec.GetFileSpec(), 0, 0, > modules_specs) == 0) > return; > > The issue here is that the targets like MIPS depends on elf flags to > determine the actual architecture but core file doesn't contain any arch > information (header.e_flags is 0) so it can't decide the arch contained in > core file. > As no specifications are found, Module constructor takes an early exit > leaving its members uninitialized. > > Going further, Module also fails to get the ObjectFile representation as it > doesn't contain enough information (Module::m_file, Module::m_arch) required > to get ObjectFile. > > So, "ProcessElfCore::CanDebug" returns false and because of this LLDB gives > error saying that it is unable to find process plug-in for core file. > > I can make mipsVariantFromElfFlags() to return some default architecture (to > ensure we always have valid arch when it can't be decided from elf flags) but > this won't always work (core's default arch and executable_elf's arch may not > "match" always). > What could be the proper fix to this issue? Try specifying a full triple when creating the target: (lldb) target create --arch=mips32-pc-linux "app_mips.elf" --core "core_mips" If any ELF file is unable to figure out its file type, it should leave things generic so the triple for the core ELF file should be something like: "mips-*-*". If that is true, then this should match your more specific triple specified in the target of "mips32-pc-linux". Try out specifying the triple and let me know how that goes. Greg Clayton ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] llvm assertion while evaluating expressions for MIPS on Linux
Hi,
I am facing issue (llvm assertion) in evaluating expressions for MIPS on Linux.
(lldb) p fooptr(a,b)
lldb: /home/battarde/git/llvm/lib/MC/ELFObjectWriter.cpp:791: void
{anonymous}::ELFObjectWriter::computeSymbolTable(llvm::MCAssembler&, const
llvm::MCAsmLayout&, const SectionIndexMapTy&, const RevGroupMapTy&,
{anonymous}::ELFObjectWriter::SectionOffsetsTy&): Assertion `Local ||
!Symbol.isTemporary()' failed.
I debugged it and found that, LLDB inserts calls to dynamic checker function
for pointer validation at appropriate locations in expression's IR.
The issue is that this checker function's name (hard-coded in LLDB in
lldb\source\Expression\IRDynamicChecks.cpp) starts with "$" i.e
"$__lldb_valid_pointer_check".
While creating a MCSymbol (MCContext::createSymbol() in
llvm/lib/MC/MCContext.cpp) for this function llvm detects the name starts with
"$" and marks that symbol as 'temporary' symbol (PrivateGlobalPrefix is '$' for
MIPS)
Further while computing a symbol table in ELFObjectWriter::computeSymbolTable()
the assertion triggers because this symbol is 'temporary'.
I tried couple of things that solves this issue for MIPS.
1. Remove '$' from the function name.
2. Remove "C Language linkage" from the dynamic pointer validation function i.e
the below piece of code in lldb\source\Expression\IRDynamicChecks.cpp
-
static const char g_valid_pointer_check_text[] =
"extern \"C\" void\n"
"$__lldb_valid_pointer_check (unsigned char *$__lldb_arg_ptr)\n"
"{\n"
"unsigned char $__lldb_local_val = *$__lldb_arg_ptr;\n"
"}";
--
becomes
static const char g_valid_pointer_check_text[] =
"void\n"
"$__lldb_valid_pointer_check (unsigned char *$__lldb_arg_ptr)\n"
"{\n"
"unsigned char $__lldb_local_val = *$__lldb_arg_ptr;\n"
"}";
Removing C Language linkage will enable mangling and will mangle
"$__lldb_valid_pointer_check" to something like
"_Z27$__lldb_valid_pointer_checkPh".
So the mangled name won't start with '$' and the symbol will not be marked as
Temporary and hence assertion won't be triggered.
Please let me know if there is any better solution to this issue.
Regards,
Bhushan
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] llvm assertion while evaluating expressions for MIPS on Linux
Hi Greg,
Thanks for your reply.
There are different temporary symbols for different architectures and file
formats.
As far as I could see, llvm::MCAsmInfo class has a member "PrivateGlobalPrefix"
which specifies this temporary symbol.
The default value for PrivateGlobalPrefix is 'L' (for ELF it is ".L").
The subclasses of llvm::MCAsmInfo sets PrivateGlobalPrefix to whatever value
they want to use for temporary symbol.
MIPS sets this to "$". (and X86/ARM uses ".L")
Since the function name "$__lldb_valid_pointer_check" starts with "$" it
matches with PrivateGlobalPrefix for MIPS and hence it is marked as temporary.
Its fine for all x86/x86_64/arm and arm64 variants because they all use symbol
other than "$" (i.e ".L") as their PrivateGlobalPrefix.
As you mentioned we cannot remove "$" from function name because it may
conflict with symbols from system libraries or user binaries,
so do you think removing C Language linkage from function
"$__lldb_valid_pointer_check" can be a solution? or do you have a better
solution to this issue?
Regards,
Bhushan
-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com]
Sent: 20 October 2015 23:56
To: Greg Clayton
Cc: Bhushan Attarde; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] llvm assertion while evaluating expressions for MIPS on
Linux
My guess is that there is a different temporary symbol for differing
architectures and possibly depending on which file format (mach-o or ELF) you
are targeting. MIPS probably happens to use '$'. I know mach-o files use "L" as
the temporary symbol prefix, ELF tends to use '.'. Not sure where this would be
abstracted in LLVM or if it is just built into the assemblers directly for each
arch... If you can find out where this can be detected within LLVM, we can make
sure we don't use any temporary prefixes in symbol names and work around this
issue. We need to make sure that any functions we generate and JIT up and
insert into the program do not conflict with _any_ symbol that could be in any
system libraries or user binaries. This is why we used '$' in the first place.
Greg
> On Oct 20, 2015, at 11:11 AM, Greg Clayton via lldb-dev
> wrote:
>
> What is this not happening on any other architecture? Is the "$" special for
> MIPS and not for other architectures? We really don't want to remove the '$'
> as we want the symbol to be unique. The '$' symbol is fine for all
> x86/x86_64/arm and arm64 variants...
>
> Greg
>
>
>> On Oct 19, 2015, at 11:30 PM, Bhushan Attarde via lldb-dev
>> wrote:
>>
>> Hi,
>>
>> I am facing issue (llvm assertion) in evaluating expressions for MIPS on
>> Linux.
>>
>> (lldb) p fooptr(a,b)
>> lldb: /home/battarde/git/llvm/lib/MC/ELFObjectWriter.cpp:791: void
>> {anonymous}::ELFObjectWriter::computeSymbolTable(llvm::MCAssembler&, const
>> llvm::MCAsmLayout&, const SectionIndexMapTy&, const RevGroupMapTy&,
>> {anonymous}::ELFObjectWriter::SectionOffsetsTy&): Assertion `Local ||
>> !Symbol.isTemporary()' failed.
>>
>> I debugged it and found that, LLDB inserts calls to dynamic checker function
>> for pointer validation at appropriate locations in expression’s IR.
>>
>> The issue is that this checker function’s name (hard-coded in LLDB in
>> lldb\source\Expression\IRDynamicChecks.cpp) starts with “$” i.e
>> “$__lldb_valid_pointer_check”.
>> While creating a MCSymbol (MCContext::createSymbol() in
>> llvm/lib/MC/MCContext.cpp) for this function llvm detects the name starts
>> with “$” and marks that symbol as ‘temporary’ symbol (PrivateGlobalPrefix is
>> '$' for MIPS) Further while computing a symbol table in
>> ELFObjectWriter::computeSymbolTable() the assertion triggers because this
>> symbol is 'temporary'.
>>
>> I tried couple of things that solves this issue for MIPS.
>>
>> 1. Remove '$' from the function name.
>> 2. Remove "C Language linkage" from the dynamic pointer validation
>> function i.e the below piece of code in
>> lldb\source\Expression\IRDynamicChecks.cpp
>> -
>> static const char g_valid_pointer_check_text[] = "extern \"C\"
>> void\n"
>> "$__lldb_valid_pointer_check (unsigned char *$__lldb_arg_ptr)\n"
>> "{\n"
>> "unsigned char $__lldb_local_val = *$__lldb_arg_ptr;\n"
>> "}";
>> -
>> -
>>
Re: [lldb-dev] llvm assertion while evaluating expressions for MIPS on Linux
Hi Greg,
I tried using "_$" and "lldb$" as our private prefix, both of these solves the
issue and works fine for MIPS.
-Regards,
Bhushan
-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com]
Sent: 23 October 2015 22:29
To: Bhushan Attarde
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] llvm assertion while evaluating expressions for MIPS on
Linux
What happens if we go with "_$" as our private prefix? Or maybe "lldb$"? Would
this avoid the issue and fix things for MIPS? I would rather us have a
consistent private naming scheme across all architectures. Let me know if you
can try that out and let us know if this works.
Greg
> On Oct 23, 2015, at 5:03 AM, Bhushan Attarde
> wrote:
>
> Hi Greg,
>
> Thanks for your reply.
>
> There are different temporary symbols for different architectures and file
> formats.
> As far as I could see, llvm::MCAsmInfo class has a member
> "PrivateGlobalPrefix" which specifies this temporary symbol.
> The default value for PrivateGlobalPrefix is 'L' (for ELF it is ".L").
> The subclasses of llvm::MCAsmInfo sets PrivateGlobalPrefix to whatever value
> they want to use for temporary symbol.
> MIPS sets this to "$". (and X86/ARM uses ".L")
>
> Since the function name "$__lldb_valid_pointer_check" starts with "$" it
> matches with PrivateGlobalPrefix for MIPS and hence it is marked as temporary.
> Its fine for all x86/x86_64/arm and arm64 variants because they all use
> symbol other than "$" (i.e ".L") as their PrivateGlobalPrefix.
>
> As you mentioned we cannot remove "$" from function name because it
> may conflict with symbols from system libraries or user binaries, so do you
> think removing C Language linkage from function "$__lldb_valid_pointer_check"
> can be a solution? or do you have a better solution to this issue?
>
> Regards,
> Bhushan
>
>
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: 20 October 2015 23:56
> To: Greg Clayton
> Cc: Bhushan Attarde; lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] llvm assertion while evaluating expressions
> for MIPS on Linux
>
> My guess is that there is a different temporary symbol for differing
> architectures and possibly depending on which file format (mach-o or ELF) you
> are targeting. MIPS probably happens to use '$'. I know mach-o files use "L"
> as the temporary symbol prefix, ELF tends to use '.'. Not sure where this
> would be abstracted in LLVM or if it is just built into the assemblers
> directly for each arch... If you can find out where this can be detected
> within LLVM, we can make sure we don't use any temporary prefixes in symbol
> names and work around this issue. We need to make sure that any functions we
> generate and JIT up and insert into the program do not conflict with _any_
> symbol that could be in any system libraries or user binaries. This is why we
> used '$' in the first place.
>
> Greg
>
>> On Oct 20, 2015, at 11:11 AM, Greg Clayton via lldb-dev
>> wrote:
>>
>> What is this not happening on any other architecture? Is the "$" special for
>> MIPS and not for other architectures? We really don't want to remove the '$'
>> as we want the symbol to be unique. The '$' symbol is fine for all
>> x86/x86_64/arm and arm64 variants...
>>
>> Greg
>>
>>
>>> On Oct 19, 2015, at 11:30 PM, Bhushan Attarde via lldb-dev
>>> wrote:
>>>
>>> Hi,
>>>
>>> I am facing issue (llvm assertion) in evaluating expressions for MIPS on
>>> Linux.
>>>
>>> (lldb) p fooptr(a,b)
>>> lldb: /home/battarde/git/llvm/lib/MC/ELFObjectWriter.cpp:791: void
>>> {anonymous}::ELFObjectWriter::computeSymbolTable(llvm::MCAssembler&, const
>>> llvm::MCAsmLayout&, const SectionIndexMapTy&, const RevGroupMapTy&,
>>> {anonymous}::ELFObjectWriter::SectionOffsetsTy&): Assertion `Local ||
>>> !Symbol.isTemporary()' failed.
>>>
>>> I debugged it and found that, LLDB inserts calls to dynamic checker
>>> function for pointer validation at appropriate locations in expression’s IR.
>>>
>>> The issue is that this checker function’s name (hard-coded in LLDB in
>>> lldb\source\Expression\IRDynamicChecks.cpp) starts with “$” i.e
>>> “$__lldb_valid_pointer_check”.
>>> While creating a MCSymbol (MCContext::createSymbol() in
>>> llvm/lib/MC/MCContext.cpp) for this funct
