Re: [lldb-dev] Sequential ID Git hook
Quick re-cap. After a few rounds, not only the "external server" proposal got obliterated as totally unnecessary, but the idea that we may even need a hook at all is now challenged. Jared's idea to use "git describe" is in line with previous proposals to use rev-list --count and to do so only up to the previous tag, but all in one nice and standard little feature. There were concerns by applying one tag per commit, but most of them offered weak evidence. However, if "describe" can cover all our needs, there is no point in even discussing tags. Just for reference, GitHub *does* have an SVN interface [1], and you can already checkout a specific revision with "svn checkout -r NNN repo", which *is already* using "git rev-list --count". This means that, for SVN based bisects, using GitHub will make it *completely transparent* for SVN users. You can also base your releases off an SVN view of the Git repo. So, to clear up this discussion and finish my proposal to move to GitHub, my final questions, only to those that *want* SVN compatibility: 1. Is there anything in the SVN view of GitHub that *doesn't* work for you? (ie. same as using "rev-list --count") 2. If so, can "git describe" solve the problem? 3. If not, please describe, in details, why <> would be the *only* way forward. I'll let this sit for a few days, and if no one has any serious issue, I'll write up the final proposal and start the voting process with the Foundation. cheers, --renato [1] https://github.com/blog/626-announcing-svn-support ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-foundation] Sequential ID Git hook
On 5 Jul 2016, at 11:44, Renato Golin via llvm-foundation wrote: > > Just for reference, GitHub *does* have an SVN interface [1], and you > can already checkout a specific revision with "svn checkout -r NNN > repo", which *is already* using "git rev-list --count". > > This means that, for SVN based bisects, using GitHub will make it > *completely transparent* for SVN users. You can also base your > releases off an SVN view of the Git repo. Note that GitHub (currently, at least) doesn’t export submodules sensibly with their svn version. I don’t intend to use the svn thing (the only time that I have used it in anger was to replace a project that moved to GitHub with an svn:external that referred to the GitHub repo so people could easily find the new location), but that would cause problems if anyone wants to do an svn bisect. I think it would help to have a description of how to bisect for a clang or lldb (or some other subproject) regression. For downstream users, it would also be nice if tools like git-imerge let you merge clang and llvm together, though that’s a nice-to-have feature that we currently lack so shouldn’t in any way block the migration. David smime.p7s Description: S/MIME cryptographic signature ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 28428] New: lldb.SBProcess.is_running and lldb.SBProcess.is_stopped Python accessors
https://llvm.org/bugs/show_bug.cgi?id=28428 Bug ID: 28428 Summary: lldb.SBProcess.is_running and lldb.SBProcess.is_stopped Python accessors Product: lldb Version: 3.8 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: marius.tranda...@live.com CC: llvm-b...@lists.llvm.org Classification: Unclassified lldb.SBProcess.is_running and lldb.SBProcess.is_stopped Python accessors are not working as expected given that they're defined incorrectly. Both is_running and is_stopped are mapped to __get_is_running__, which is defined twice. In %LLDB_SOURCES%/scripts/interface/SBProcess.i there are the following lines of code: // Line 434 def __get_is_running__(self): '''Returns "True" if the process is currently running, "False" otherwise''' state = self.GetState() if state == eStateRunning or state == eStateStepping: return True return False def __get_is_running__(self): '''Returns "True" if the process is currently stopped, "False" otherwise''' state = self.GetState() if state == eStateStopped or state == eStateCrashed or state == eStateSuspended: return True return False // Line 474 __swig_getmethods__["is_running"] = __get_is_running__ if _newclass: is_running = property(__get_is_running__, None, doc='''A read only property that returns a boolean value that indicates if this process is currently running.''') __swig_getmethods__["is_stopped"] = __get_is_running__ if _newclass: is_stopped = property(__get_is_running__, None, doc='''A read only property that returns a boolean value that indicates if this process is currently stopped.''') -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB-MI from Eclipse hangs
You should sample lldb-mi to see what it is doing. Also if you can get a more
complete packet log of the traffic between Eclipse and lldb-mi we might be able
to see what is going on. Another thing to note: if you are remote debugging to
a Mac from another machine and don't have any files cached (all shared
libraries from the remote machine), they will be read from memory when the
DynamicLoaderMachOSX figures out which shared libraries the process has. This
might be slow and take quite a while and it might delay your debugging as you
download a few hundred shared libraries for the first time. So you might see
long delays as you debug. You might try and wait for a few minutes to see if
the process stops correctly after reading everything from memory.
Greg Clayton
> On Jul 1, 2016, at 1:13 AM, via lldb-dev wrote:
>
> Hi All,
>
> I am trying to simple "Hello World" program remotely on a MAC OS using
> eclipse and lldb-mi. I followed the instructions available here:
> "https://www.codeplay.com/portal/lldb-mi-driver---part-2-setting-up-the-driver";.
> I am facing below issue. Any suggestions would be of great help.
>
> It is simple helloWorld C++ program. he program is running on machine A and I
> am debugging it from machine B. When I remote debug from command prompt using
> lldb-mi, I am able to debug it properly. But when I try to do it via Eclipse
> from machine B:
>
> - lldb-mi is tarting
>
> - netstat on machine A shows that “debugserver" has ESTABLISHED connection
> with machine B.
>
> - But on Eclipse console it hangs after below command:
>
> 461,432 (gdb)
>
> 461,432 22^done,threads=[{id="1",target-id="Thread 1",state="stopped"}]
>
> 461,432 (gdb)
>
> 461,434 24-stack-info-depth --thread 1 11
>
> If you have any suggestions please let me know. Thanks.
>
>
>
> --
> Have a nice day!
> Regards,
> Dipti
> ___
> 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] Stack variables in lldb with custom generated metadata
Since your compile unit is Java:
> 0x000b: TAG_compile_unit [1] *
> AT_producer( "RoboVM 2.2.0-SNAPSHOT" )
> AT_language( DW_LANG_Java )
> AT_name( "Main.java" )
> AT_stmt_list( 0x )
> AT_comp_dir(
> "/Users/generalsolutions/Documents/runtime-EclipseApplication/RobovmConsole/src/main/java/"
> )
> AT_APPLE_optimized( 0x01 )
> AT_low_pc( 0x )
> AT_ranges( 0x
> [0x06f0 - 0x080b)
> [0x0878 - 0x0893)
> [0x0893 - 0x0901)
> End )
The "DWARFASTParserJava" class will be used to parse any types. I would check
the following function:
lldb::TypeSP
DWARFASTParserJava::ParseTypeFromDWARF(
const lldb_private::SymbolContext &sc,
const DWARFDIE &die,
lldb_private::Log *log,
bool *type_is_new_ptr);
If you are doing "frame variable" and you know the variable you are trying to
view you can step through the DWARFASTParserJava::ParseTypeFromDWARF() and make
sure that a valid type is made. For example, if you are looking at the "env"
variable from:
0x002b: TAG_subprogram [2] *
AT_low_pc( 0x06f0 )
AT_high_pc( 0x076f )
AT_frame_base( rbp )
AT_name( "[J]Main.(I)V" )
AT_decl_file( "Main.java" )
AT_decl_line( 7 )
AT_external( 0x01 )
0x0045: TAG_formal_parameter [3]
AT_location( fbreg -8 )
AT_name( "env" )
AT_decl_file( "Main.java" )
AT_decl_line( 7 )
AT_type( {0x00de} ( Object ) )
0x0053: NULL
We can see that tthe type for "env" is the type AT_type is 0x00de. If we
look at 0x00de:
0x00de: TAG_pointer_type [6]
AT_name( "Object" )
After looking at DWARFASTParserJava::ParseTypeFromDWARF(), there is no handler
for "TAG_pointer_type" and thus no CompilerType will be made for "0x00de"
and this is why you aren't seeing anything. Not sure how you would re-create a
variable from this debug info? But seems like you will need to figure out how
to make a type for this and you will then see your variable. I will leave this
to the Java experts.
Greg Clayton
> On Jul 4, 2016, at 11:08 AM, Florian Falkner via lldb-dev
> wrote:
>
> Hello List!
>
> I'm trying to add LLDB/DWARF debugging information to the RoboVM opensource
> fork [1]
> Java AOT compiler. RoboVM uses the LLVM 3.6 (pre-release version) debugging
> format
> and I got the basics working, but can't get the stack variable inspection to
> work.
> The IR is generated by RoboVM's own implementation, not by the LLVM Cpp API.
>
> The "fr v" command doesn't show any local variables. Below the generated IR
> for a method, the debugging info for this CU and the dwarfdump output.
> I can't see the void* pointer argument %env in lldb. (Metadata Lines !38 -
> !42)
>
> Any hint what I'm doing wrong would be great, since I ran out of ideas.
>
> Thanks for your time, and sorry if this is the wrong place to ask!
> Florian
>
> [1] https://github.com/florianf/robovm/tree/dwarf_debugging_branch
>
> LLDB Version:
> lldb-350.0.21.9
>
> CLANG Version & Command:
> Apple LLVM version 7.3.0 (clang-703.0.31)
> clang++ -o Main -g -arch x86_64 -Wl,-filelist,objects0 -L
> vm/target/binaries/macosx/x86_64 -ObjC -exported_symbols_list
> exported_symbols -Wl,-no_implicit_dylibs -Wl,-dead_strip -fPIC
> -mmacosx-version-min=10.9 -Wl,-no_pie -lrobovm-bc-dbg -force_load
> vm/target/binaries/macosx/x86_64/librobovm-rt-dbg.a -lrobovm-debug-dbg
> -lrobovm-core-dbg -lgc-dbg -lpthread -ldl -lm -lz -liconv -lsqlite3
> -framework Foundation -framework CoreServices
>
> Generated IR for a method:
>
> define weak i32 @"[J]Main.instanceMethod(I)I"(%Env* %p0, %Object* %p1, i32
> %p2) nounwind noinline optsize {
> label0:
> %__envStack = alloca %Env*
> store %Env* %p0, %Env** %__envStack
> call void @"llvm.dbg.declare"(metadata %Env** %__envStack, metadata !39),
> !dbg !57
> %r0 = alloca %Object*
> %i0 = alloca i32
> %r1 = alloca %Object*
> %$r2 = alloca %Object*
> %$r3 = alloca %Object*
> %$i1 = alloca i32
> %$i2 = alloca i32
> %$i3 = alloca i32
> call void @"checkso"()
> store %Object* %p1, %Object** %r0, !dbg !58
> store i32 %p2, i32* %i0, !dbg !63
> %t0 = call %Object* @"[j]str_ndiiiddd_00[ldcstring]"(%Env* %p0), !dbg !51
> store %Object* %t0, %Object** %r1, !dbg !56
> %t1 = load %Object** %r0, !dbg !52
> %t2 = call %Object* @"[j]Main.scAttr(Ltest/sub/SubClass;)[get]"(%Env*
> %p0, %Object* %t
[lldb-dev] [Bug 28428] lldb.SBProcess.is_running and lldb.SBProcess.is_stopped Python accessors
https://llvm.org/bugs/show_bug.cgi?id=28428 Greg Clayton changed: What|Removed |Added Status|NEW |RESOLVED CC||clayb...@gmail.com Resolution|--- |FIXED --- Comment #1 from Greg Clayton --- % svn commit Sendingscripts/interface/SBProcess.i Transmitting file data .done Committing transaction... Committed revision 274568. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-foundation] Sequential ID Git hook
On 5 July 2016 at 12:13, David Chisnall wrote: > Note that GitHub (currently, at least) doesn’t export submodules sensibly > with their svn version. SVN users can continue using the projects directly, they *just* need to change the SVN repository location of every project to GitHub. It can't get simpler than that. > I think it would help to have a description of how to bisect for a clang or > lldb (or some other subproject) regression. There are plenty of good documentation (https://git-scm.com/book/en/v2) that teaches everything one needs to know about git (but was afraid to ask). Using the umbrella project, the sub-modules will make it trivial to bisect. Using SVN view for individual projects will make it *identical* to bisect as it was. > For downstream users, it would also be nice if tools like git-imerge let you > merge clang and llvm together, though that’s a nice-to-have feature that we > currently lack so shouldn’t in any way block the migration. Git imerge is an amazing tool, but it's not production quality yet, I think. Though, this is really an orthogonal issue, since SVN-bound people can still use the SVN view and merge their own patches downstream. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] Sequential ID Git hook
On Sat, Jul 2, 2016 at 3:18 AM, Tom Honermann via llvm-dev < llvm-...@lists.llvm.org> wrote: > We're using tags in this manner for our internal repos and LLVM/Clang > mirrors and haven't experienced any problems. We're at ~50k tags for > our most used repo, so not quite at hundreds of thousands yet. > > When I look in .git/refs/tags of one of my repos, I do *not* see 50k > files; I see ~400. I'm not sure what causes some to appear here and > others not. > You don't see many tags because tags (both heavy and lightweight) are transferred from the file system into a pack file whenever a "git repack" or "git gc" happens. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Sequential ID Git hook
> On Jul 5, 2016, at 3:44 AM, Renato Golin via llvm-dev > wrote: > > Quick re-cap. > > After a few rounds, not only the "external server" proposal got > obliterated as totally unnecessary, but the idea that we may even need > a hook at all is now challenged. This is not clear to me. How is the umbrella repository updated? — Mehdi > > Jared's idea to use "git describe" is in line with previous proposals > to use rev-list --count and to do so only up to the previous tag, but > all in one nice and standard little feature. > > There were concerns by applying one tag per commit, but most of them > offered weak evidence. However, if "describe" can cover all our needs, > there is no point in even discussing tags. > > Just for reference, GitHub *does* have an SVN interface [1], and you > can already checkout a specific revision with "svn checkout -r NNN > repo", which *is already* using "git rev-list --count". > > This means that, for SVN based bisects, using GitHub will make it > *completely transparent* for SVN users. You can also base your > releases off an SVN view of the Git repo. > > So, to clear up this discussion and finish my proposal to move to > GitHub, my final questions, only to those that *want* SVN > compatibility: > > 1. Is there anything in the SVN view of GitHub that *doesn't* work for > you? (ie. same as using "rev-list --count") > > 2. If so, can "git describe" solve the problem? > > 3. If not, please describe, in details, why < solution>> would be the *only* way forward. > > I'll let this sit for a few days, and if no one has any serious issue, > I'll write up the final proposal and start the voting process with the > Foundation. > > cheers, > --renato > > [1] https://github.com/blog/626-announcing-svn-support > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Sequential ID Git hook
On 5 Jul 2016 10:45 p.m., "Mehdi Amini" wrote: > > > > On Jul 5, 2016, at 3:44 AM, Renato Golin via llvm-dev < llvm-...@lists.llvm.org> wrote: > > > > Quick re-cap. > > > > After a few rounds, not only the "external server" proposal got > > obliterated as totally unnecessary, but the idea that we may even need > > a hook at all is now challenged. > > This is not clear to me. > How is the umbrella repository updated? Sorry, I meant no hooks for updating sequential ids. We still need a hook to update the umbrella project. Cheers, Renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] July LLVM bay-area social is this Thursday!
We'll be at Tied House as usual, starting on Thursday the 7th at 7pm! If you can, help us plan and RSVP here: http://meetu.ps/2XQyLm See everyone there! George ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
