Re: [lldb-dev] Too many ModuleSP references
Thank you for the feedback. I'll look into how to get the expressions cleared when the breakpoint locations get unresolved. I can also switch the breakpoints to a weak_ptr if you think that is worthwhile, but one of the two fixes is enough for me at the moment. regards, pavel On 22 February 2017 at 01:08, Jim Ingham via lldb-dev wrote: > >> On Feb 21, 2017, at 4:49 PM, Jim Ingham via lldb-dev >> wrote: >> >> >>> On Feb 21, 2017, at 4:24 PM, Greg Clayton via lldb-dev >>> wrote: >>> - StepOverBreakpointTestCase: Have the test not store the breakpoints in the test case object. Basically, declare that this is not a bug, and it's the users responsibility to clean up necessary objects. >>> >>> It would be nice to avoid this. >>> >> >> I don't agree with this. I think trying to force folks using the API from >> Python to manually clear all stored objects would be really obnoxious. If >> anything, we should figure out how to make this accidental failure into an >> intended failure so we can make sure we don't end up requiring this kind of >> micro-management. > > It's possible you meant "it would be nice to avoid it's being the user's > responsibility to clean up necessary objects", in which case sorry for > mis-reading but happy we agree... > > Jim > > >> >> Jim >> >> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Debugging ELF relocatable files using LLDB
I uploaded a CL for review what fixes the crash you are experimenting at
https://reviews.llvm.org/D30251 (we are mapping the files into memory as
read only and then trying to write into it) but I think nobody tests LLDB
with relocable object files so you might run into a lot of bugs in the way.
Also I suggest to switch to a newer version of LLDB (preferably ToT) as 3.6
is fairly old and known to have a lot of bugs on Linux and on ARM.
Tamas
On Wed, Feb 22, 2017 at 4:56 AM Ramana via lldb-dev
wrote:
> On Thu, Feb 16, 2017 at 10:26 PM, Greg Clayton wrote:
> >
> > On Feb 16, 2017, at 3:51 AM, Ramana via lldb-dev <
> lldb-dev@lists.llvm.org>
> > wrote:
> >
> > It looks like LLDB doesn't like ELF relocatable files for debugging
> > and asserts with the following message when tried
> >
> > /lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2228:
> > unsigned int ObjectFileELF::RelocateSection(.): Assertion `false
> > && "unexpected relocation type"' failed.
> >
> > Are we not supposed to debug ELF relocatable files on LLDB or am I
> > missing something?
> >
> > If we cannot debug the relocatable files, is it _simply_ because those
> > files lack program headers (program memory map) and relocations are
> > yet to be processed (for debug info) or there are other reasons?
> >
> > For our target, the assembler output itself is a self contained ELF
> > and hence will not have external references (both code and data). I am
> > wondering if I can debug these ELF files on LLDB with minimal changes
> > which does not require a full (or proper) linking step and would
> > appreciate any pointers on that.
> >
> > Thanks,
> > Ramana
> >
> >
> > Looks like you just need to add support for the 32 bit relocations:
> >
> >
> > if (hdr->Is32Bit()) {
> > switch (reloc_type(rel)) {
> > case R_386_32:
> > case R_386_PC32:
> > default:
> > assert(false && "unexpected relocation type");
> > }
> > } else {
> > switch (reloc_type(rel)) {
> > case R_X86_64_64: {
> > symbol = symtab->FindSymbolByID(reloc_symbol(rel));
> > if (symbol) {
> > addr_t value = symbol->GetAddressRef().GetFileAddress();
> > DataBufferSP &data_buffer_sp =
> debug_data.GetSharedDataBuffer();
> > uint64_t *dst = reinterpret_cast(
> > data_buffer_sp->GetBytes() + rel_section->GetFileOffset() +
> > ELFRelocation::RelocOffset64(rel));
> > *dst = value + ELFRelocation::RelocAddend64(rel);
> > }
> > break;
> > }
> > case R_X86_64_32:
> > case R_X86_64_32S: {
> > symbol = symtab->FindSymbolByID(reloc_symbol(rel));
> > if (symbol) {
> > addr_t value = symbol->GetAddressRef().GetFileAddress();
> > value += ELFRelocation::RelocAddend32(rel);
> > assert(
> > (reloc_type(rel) == R_X86_64_32 && (value <= UINT32_MAX))
> ||
> > (reloc_type(rel) == R_X86_64_32S &&
> >((int64_t)value <= INT32_MAX && (int64_t)value >=
> > INT32_MIN)));
> > uint32_t truncated_addr = (value & 0x);
> > DataBufferSP &data_buffer_sp =
> debug_data.GetSharedDataBuffer();
> > uint32_t *dst = reinterpret_cast(
> > data_buffer_sp->GetBytes() + rel_section->GetFileOffset() +
> > ELFRelocation::RelocOffset32(rel));
> > *dst = truncated_addr;
> > }
> > break;
> > }
> > case R_X86_64_PC32:
> > default:
> > assert(false && "unexpected relocation type");
> > }
> > }
> >
> >
> > I am guessing you will do something similar to the x86-64 stuff.
>
> I tried to mimic the x86_64 relocations handling for our target but
> getting segmentation fault while trying to write to the 'dst'
> location.
>
> In fact, the x86_64 also segfaults while trying to write to 'dst'
> location. I just tried to debug the following simple program for
> x86_64.
>
> main.c:
> int main () {
>return 0;
> }
>
> $ clang main.c -o main_64b.o --target=x86_64 -c -g
> $ lldb main_64b.o
> (lldb) target create "main_64b.o"
> Current executable set to 'main_64b.o' (x86_64).
> (lldb) source list
> Segmentation fault (core dumped)
>
> Am I doing something wrong or support for debugging the x86_64 ELF
> relocatable files using LLDB is broken?
>
> BTW, I am using LLVM v3.6 and LLDB v3.6.
>
> Regards,
> Ramana
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Too many ModuleSP references
> On Feb 21, 2017, at 5:08 PM, Jim Ingham wrote: > >> >> On Feb 21, 2017, at 4:49 PM, Jim Ingham via lldb-dev >> wrote: >> >> >>> On Feb 21, 2017, at 4:24 PM, Greg Clayton via lldb-dev >>> wrote: >>> - StepOverBreakpointTestCase: Have the test not store the breakpoints in the test case object. Basically, declare that this is not a bug, and it's the users responsibility to clean up necessary objects. >>> >>> It would be nice to avoid this. >>> >> >> I don't agree with this. I think trying to force folks using the API from >> Python to manually clear all stored objects would be really obnoxious. If >> anything, we should figure out how to make this accidental failure into an >> intended failure so we can make sure we don't end up requiring this kind of >> micro-management. > > It's possible you meant "it would be nice to avoid it's being the user's > responsibility to clean up necessary objects", in which case sorry for > mis-reading but happy we agree... Yep, that is what I meant. No one should have to worry about cleansing any variables. It should just work. So we need to pick the lldb::SB objects that have strong reference very carefully.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [4.0.0 Release] Current status
According to the schedule on llvm.org, we should have tagged 'final' yesterday, so the release is now officially a little behind schedule. There are currently seven blockers (llvm.org/pr31622). Several of them have patches. If you can help reviewing them, please do so. - PR30256: Assert in llvm::ReassociatePass::OptimizeAdd There's a patch in progress that looks promising. - PR30284: Assertion `!B->isCollapsed() && "Cannot merge from collapsed There's a patch (D30242) but it needs more attention. - PR31181: wrong code with "opt [..] -correlated-propagation [..] -indvars" The problem seems somewhat understood but there is no patch. - PR31729: GVNHoist illegally hoists div instruction There is a patch (D29092) that looks promising but currently stuck(?). - PR31847: After r288115: Assertion failed: (isLoopInvariant(Operands[i], L) There is a patch (D29641) but no recent progress. - PR31863: Clang can't read back a PCH just produced There is a patch (D29753) but it's stuck. - PR31864: incorrect _GCC_ATOMIC_LLONG_LOCK_FREE values on i386-freebsd There is a patch (D29542) but it lacks active review. There are also a few patches in my merge queue waiting for approvals. Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] problem question, LLDB: process launch failed: Lost debug server connection
Hello. I am Lee. I have trouble to run lldb. My system is Ubutu 16.10-server & downloaded lldb version 3.8.1 via apt-get install. I wand just local debugging. But err message is like below. tt@ttt:~/trunk$ lldb /system/bin/cwm Traceback (most recent call last): File "", line 1, in ImportError: No module named lldb.embedded_interpreter (lldb) target create "/system/bin/cwm" Current executable set to '/system/bin/cwm' (i386). (lldb) r error: process launch failed: Lost debug server connection (lldb) Plz answer about this problem Thank you. --- 이 이메일은 Avast 안티바이러스 소프트웨어로 바이러스 검사를 완료했습니다. https://www.avast.com/antivirus ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] problem question, LLDB: process launch failed: Lost debug server connection
Hello. I am Lee. I have trouble to run lldb. My system is Ubutu 16.10-server & downloaded lldb version 3.8.1 via apt-get install. I wand just local debugging. But err message is like below. tt@ttt:~/trunk$ lldb /system/bin/cwm Traceback (most recent call last): File "", line 1, in ImportError: No module named lldb.embedded_interpreter (lldb) target create "/system/bin/cwm" Current executable set to '/system/bin/cwm' (i386). (lldb) r error: process launch failed: Lost debug server connection (lldb) Plz answer about this problem Thank you. --- 이 이메일은 Avast 안티바이러스 소프트웨어로 바이러스 검사를 완료했습니다. https://www.avast.com/antivirus ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
