Re: [lldb-dev] Can someone help me getting the thread local variable tests on Linux passing after my changes in 274366?
The correct incantation for the behavior you want should be now:
@expectedFailureAll(oslist=no_match(lldbplatformutil.getDarwinOSTriples())).
We are trying do drop the "Unless" versions of the decorators, as the
approach does not scale well. I've put the decorator in place now.
I'll put the tls issue on our radar. I don't think we've been aware of
it until now, and it's sounds like it would be a good idea to make it
work.
Thanks for fixing the breakage. BTW, you can get the cmake we are
using to build via "git clone
https://android.googlesource.com/platform/prebuilts/cmake/linux-x86 -b
lldb-master-dev". There is no installation required, just check it out
somewhere and run it.
cheers,
pl
On 1 July 2016 at 22:34, Greg Clayton via lldb-dev
wrote:
> So it turns out that TLS variables on linux have been broken all along. I
> backed out my changes and the test still failed. The test had a decorator:
>
> @unittest2.expectedFailure("rdar://7796742")
>
> That was causing it to expected fail for everyone. I fixed 7796742 and took
> off the decorator, but then the buildbots had errors. I added back a
> decorator:
>
> @unittest2.expectedFailure("now works on Darwin, but not linux")
>
> As I am not aware of a "expectedFailureExceptDarwin" decorator. Someone on
> linux should have a look when they get the chance.
>
> Greg Clayton
>
>> On Jul 1, 2016, at 12:40 PM, Greg Clayton via lldb-dev
>> wrote:
>>
>> I don't have access to a linux machine that can currently build LLVM, Clang
>> and LLDB (all are machines that are administered by others and the cmake is
>> too old to build top of tree). It should be trivial to get working if you
>> can debug it.
>>
>> Greg Clayton
>> ___
>> 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] [llvm-dev] [cfe-dev] Sequential ID Git hook
On 4 July 2016 at 06:01, NAKAMURA Takumi via llvm-dev wrote: > "git-describe -t" works also for lw tags. But it doesn't work if there are no tags, I just tested on LLVM and I get: $ git describe fatal: No names found, cannot describe anything. Should be easy enough to create the tags on each branching point, though. "describe" also seems to be available at least since Git 1.9, so it should be pretty safe. And since tagging *every* commit doesn't scale for long ranges, and anything else will need scripting on the client side, I think we can get rid *completely* of any server side hook, and let the client side scripts deal with the output of "git describe". Or am I just too optimistic? cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
On 4 July 2016 at 00:42, Robinson, Paul wrote: > Daniel claimed it was not different, even though he proposed the text. > I think it is better, as "egregious" (even though it is qualitative) > helps identify what "rare" circumstances would come under the policy. > As a non-lawyer I do think it's different. I personally agree with you, both on helping identify "rare" (as what, not when), and for easing non-lawyers minds. 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-foundation] [llvm-dev] [cfe-dev] Sequential ID Git hook
On 4 Jul 2016, at 12:13, Renato Golin via llvm-foundation wrote: > > And since tagging *every* commit doesn't scale for long ranges, and > anything else will need scripting on the client side, I think we can > get rid *completely* of any server side hook, and let the client side > scripts deal with the output of "git describe". > > Or am I just too optimistic? One of the nice features of GitHub is that it provides a download link to grab tarballs for any specific version. These are easy to se with other workflows (for example, the FreeBSD ports collection has infrastructure for grabbing a release and building it). It would be a shame if you needed a full git clone to get the revision information, as that would mean that anyone who built from a tarball would lose it. David ___ 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
What doesn't scale about tagging every commit? True, every tag creates a small file on disk, but then so does every commit. If you're worried about lots of files in a directory then you can put tags in nested directories by putting one or more /'s in the tag name. So you can hide all the commit tags in, say .git/refs/tags/commits and put release tags in the root tags directory, or another subdirectory. i.e. "git tag commit/23456 HEAD". Things such as shell command autocomplete (e.g. git checkout) deal intelligently with the tags directory structure, so you're not overwhelmed by 1 commit tags when you just want to see the 40 release tags. Also the files are only a short term thing anyway. When a "git gc" or "git pack" happens, tags get added to the compressed pack file just the same as objects do and the .git/refs/tags directory is cleared out. On Mon, Jul 4, 2016 at 11:13 PM, Renato Golin via llvm-dev < llvm-...@lists.llvm.org> wrote: > On 4 July 2016 at 06:01, NAKAMURA Takumi via llvm-dev > wrote: > > "git-describe -t" works also for lw tags. > > But it doesn't work if there are no tags, I just tested on LLVM and I get: > > $ git describe > fatal: No names found, cannot describe anything. > > Should be easy enough to create the tags on each branching point, though. > > "describe" also seems to be available at least since Git 1.9, so it > should be pretty safe. > > And since tagging *every* commit doesn't scale for long ranges, and > anything else will need scripting on the client side, I think we can > get rid *completely* of any server side hook, and let the client side > scripts deal with the output of "git describe". > > Or am I just too optimistic? > > cheers, > --renato > ___ > 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] [cfe-dev] Sequential ID Git hook
On 4 July 2016 at 15:21, Bruce Hoult wrote: > What doesn't scale about tagging every commit? Both Jim and Takumi have reported problems with thousands of tags. Even though neither of them responded to your enquiries for additional data, we can't assume there isn't any. Furthermore, "git describe" seems to be the "mixed mode" I asked about, and it's already in git since an old version, so I'm not sure why we'd even need to create one tag per commit anyway. People should be using Git for bisects, in which case it works out of the box. The incremental version was mostly to tag the build with something meaningful, which "git describe" is. Even if you want to use the result of describe to bisect like SVN, it works because our history is linear (and you can count the number of commits between A and B, and even store a local list of the hashes in between. I really can't see why would we need to tag every commit. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Stack variables in lldb with custom generated metadata
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* %t1), !dbg !64
store %Object* %t2, %Object** %$r2, !dbg !45
%t3 = load %Object** %$r2, !dbg !65
%t4 = call i8 @"checknull"(%Env* %p0, %Object* %t3), !dbg !43
call void
@"[j]test.sub.SubClass.throwSomething()V[Invokevirtual(Main,test/sub/SubClass)]"(%Env*
%p0, %Object* %t3), !dbg !50
%t5 = call %Object* @"[j]str_777_00[ldcstring]"(%Env* %p0), !dbg !49
store %Object* %t5, %Object** %$r3, !dbg !46
%t6 = load %Object** %$r3, !dbg !67
%t7 = call i32
@"[j]java.lang.String.length()I[Invokevirtual(Main,java/lang/String)]"(%Env*
%p0, %Object* %t6), !dbg !54
store i32 %t7, i32* %$i1, !dbg !59
%t8 = load %Object** %r1, !dbg !55
%t9 = call i32
@"[j]java.lang.String.length()I[Invokevirtual(Main,java/lang/String)]"(%Env*
%p0, %Object* %t8), !dbg !44
store i32 %t9, i32* %$i2, !dbg !60
%t11 = load i32* %$i1, !dbg !53
%t12 = load i32* %$i2, !dbg !61
%t10 = add i32 %t11, %t12, !dbg !47
store i32 %t10, i32* %$i3, !dbg !62
%t13 = load i32* %$i3, !dbg !66
ret i32 %t13, !dbg !48
}
Debugging Metadata:
!llvm.dbg.cu = !{!7}
!llvm.module.flags = !{!3, !4}
!0 = !{}
!1 = !{!"Main.java",
!"/Users/generalsolutions/Documents/runtime-EclipseApplication/RobovmConsole/src/main/java/"}
!2 = !{!18, !38, !68, !78}
!3 = !{i32 2, !"Dwarf Version", i32 2}
!4 = !{i32 2, !"Debug Info Version", i32 2}
!5 = !{!"0x29", !1} ; [ DW_TAG_file_type ] [
/Users/generalsolutions/Documents/runtime-EclipseApplication/RobovmConsole/src/main/java/Main.java
]
!6 = !{!"0x258"} ; [ DW_TAG_expression ]
!7 = !{!"0x11\0011\00RoboVM 2.2.0-SNAPSHOT\001\00\000\00\001", !1, !0, !0,
!2, !0, !0} ; [ DW_TAG_compile_unit ] [
/Users/generalsolutions/Documents/runtime-EclipseApplication/RobovmConsole/src/main/java/Main.java
] [ DW_LANG_Java ]
!8 = !{!"0x24\00boolean\000\008\008\000\000\002", null, null} ; [
DW_TAG_base_type ] [ boolean ] [ line 0, size 8, align 8, offset 0, enc
DW_ATE_boolean ]
!9 = !{!"0x24\00byte\000\008\008\000\000\006", null, null} ; [
DW_TAG_base_type ] [ byte ] [ line 0, size 8, align 8, offset 0, enc
DW_ATE_signed_char ]
!10 = !{!"0x24\00short\000\0016\0016\000\000\005", null, null} ; [
DW_TAG_base_type ] [ short ] [ line 0, size 16, align 16, offset 0, enc
DW_ATE_signed ]
!11 = !{!"0x24\00char\000\0016\0016\000\000\007", null, null} ; [
DW_TAG_base_type ] [ char ] [ line 0, size 16, align 16, offset 0, enc
DW_ATE_unsigned ]
!12 = !{!"0x24\00int\000\0032\0032\000\000\005", null, null} ; [
DW_TAG_base_type ] [ int ] [ line 0, size 32, align 32, offset 0, enc
DW_ATE_signed ]
!13 = !{!"0x24\00long\000\0064\0064\000\000\005", null, null} ; [
DW_TAG_base_type ] [ long ] [ line 0, size 64, align 64, offset 0, enc
DW_ATE_signed ]
!14 = !{!"0x24\00float\000\0032\0032\000\000\004", null, null} ; [
DW_TAG_base_type ] [ float ] [ line 0, size 32, align
Re: [lldb-dev] [llvm-dev] [cfe-dev] Sequential ID Git hook
> El jul. 4, 2016, a las 11:15, Renato Golin escribió: > > On 4 July 2016 at 15:21, Bruce Hoult wrote: >> What doesn't scale about tagging every commit? > > Both Jim and Takumi have reported problems with thousands of tags. > Even though neither of them responded to your enquiries for additional > data, we can't assume there isn't any. Agreed. Adding a tag to every commit (especially in something with as many commits as LLVM/clang) would be a nightmare for anyone that the pretty forms of git-log (eg, "git log --graph --abbrev-commit --pretty=oneline --decorate --color") or GUI-based programs for Git. I imagine the dropdown menus on Github wouldn't be fun to use either. > Furthermore, "git describe" seems to be the "mixed mode" I asked > about, and it's already in git since an old version, so I'm not sure > why we'd even need to create one tag per commit anyway. > > People should be using Git for bisects, in which case it works out of > the box. The incremental version was mostly to tag the build with > something meaningful, which "git describe" is. > > Even if you want to use the result of describe to bisect like SVN, it > works because our history is linear (and you can count the number of > commits between A and B, and even store a local list of the hashes in > between. > > I really can't see why would we need to tag every commit. > > cheers, > --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
>From my perspective: Do whatever makes y'all happy here :) On Mon, Jul 4, 2016 at 4:27 AM, Renato Golin wrote: > On 4 July 2016 at 00:42, Robinson, Paul wrote: > > Daniel claimed it was not different, even though he proposed the text. > > I think it is better, as "egregious" (even though it is qualitative) > > helps identify what "rare" circumstances would come under the policy. > > As a non-lawyer I do think it's different. > > I personally agree with you, both on helping identify "rare" (as what, > not when), and for easing non-lawyers minds. > > 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
Very few operations search for commit objects by reading every single commit file. Most operations that read commit objects already know what they are looking for based on their hash. Plus, over time commit objects are packed into well indexed archive files, so the total number of commits stored in the filesystem never becomes an issue. On the other hand, there are many commonly used git commands that might load and parse the entire set of references in order to function. git describe, git log (--decorate|--all), git fetch, git push, ... On Mon, Jul 4, 2016 at 11:51 PM, Bruce Hoult via llvm-dev < llvm-...@lists.llvm.org> wrote: > What doesn't scale about tagging every commit? > > True, every tag creates a small file on disk, but then so does every > commit. > > If you're worried about lots of files in a directory then you can put tags > in nested directories by putting one or more /'s in the tag name. So you > can hide all the commit tags in, say .git/refs/tags/commits and put release > tags in the root tags directory, or another subdirectory. i.e. "git tag > commit/23456 HEAD". Things such as shell command autocomplete (e.g. git > checkout) deal intelligently with the tags directory structure, so you're > not overwhelmed by 1 commit tags when you just want to see the 40 > release tags. > > Also the files are only a short term thing anyway. When a "git gc" or "git > pack" happens, tags get added to the compressed pack file just the same as > objects do and the .git/refs/tags directory is cleared out. > > On Mon, Jul 4, 2016 at 11:13 PM, Renato Golin via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> On 4 July 2016 at 06:01, NAKAMURA Takumi via llvm-dev >> wrote: >> > "git-describe -t" works also for lw tags. >> >> But it doesn't work if there are no tags, I just tested on LLVM and I get: >> >> $ git describe >> fatal: No names found, cannot describe anything. >> >> Should be easy enough to create the tags on each branching point, though. >> >> "describe" also seems to be available at least since Git 1.9, so it >> should be pretty safe. >> >> And since tagging *every* commit doesn't scale for long ranges, and >> anything else will need scripting on the client side, I think we can >> get rid *completely* of any server side hook, and let the client side >> scripts deal with the output of "git describe". >> >> Or am I just too optimistic? >> >> cheers, >> --renato >> ___ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > ___ > 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
