Re: [lldb-dev] fate of TimeValue

[Pavel Labath via lldb-dev]

My current plan is to first clean up the usage of llvm::TimeValue and
replace it with std::chrono, then proceed on to LLDB. I have the llvm
stuff mostly done locally, I just need to find a bit of time to test
it out on windows. Will update when that is done.

pl

On 11 October 2016 at 19:36, Greg Clayton  wrote:
> I am fine with TimeValue going away. I would love to just use STL std::chrono 
> stuff if we can get away with it. If there is a bunch of code that gets 
> re-written all of the time, then using the LLVM TimeValue class is fine if it 
> is needed.
>
> Greg
>
>> On Oct 7, 2016, at 10:29 PM, Mehdi Amini via lldb-dev 
>>  wrote:
>>
>>>
>>> On Oct 7, 2016, at 10:19 PM, Pavel Labath  wrote:
>>>
>>> On 7 October 2016 at 21:42, Mehdi Amini  wrote:

> On Oct 7, 2016, at 9:30 PM, Pavel Labath via lldb-dev 
>  wrote:
>
> The llvm-dev thread seems to have fizzed out - I would assume they are
> not interested in std::chrono.

 I suggest a totally different course of action: any utility (except 
 specific to the debugger for some reason) should be submitted into LLVM 
 (Support?).
 I may be happy to have it available next months in LLVM, and I may not 
 think about looking in every subproject.

 The question is not if “they” (I rather have you guys say “we”) are not 
 interested, but rather “is anyone opposing to having utilities wrapping / 
 manipulating std::chrono in LLVM”.

>>>
>>> I like that idea. I've added you to the reviews so you can see what
>>> kind of utility functions I am talking about. BTW, LLVM seems to have
>>> a TimeValue class as well (presumably because not all compilers used
>>> to support std::chrono)
>>
>> I believe TimeValue was created before std::chrono was standardized (first 
>> committed in 2004!)
>>
>>> - one possibility would be to start using that
>>> instead, although I would prefer std::chrono.
>>
>> Indeed, I believe we tend to move to the standard version of our utilities 
>> when the feature is complete in the compiler versions we support.
>>
>> It is also possible that not all of TimeValue features are supported by 
>> std::chrono, I haven't compared in detail.
>>
>> —
>> Mehdi
>>
>> ___
>> 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] get function name from dwarf info

[Greg Clayton via lldb-dev]

> On Oct 7, 2016, at 7:32 AM, Carlo Kok via lldb-dev  
> wrote:
> 
> 
>>> How do I get the dw_at_name field? I don't need lldb to decypher the
>>> mangling I use, I just want access to the linkage name and real encoded
>>> name?
>>> 
>>> Also how do I get the type this is contained in (presuming there is one
>>> ofc)?
>> I am not sure what you are trying to do. Can you elaborate a little.
> 
> I have a custom language where it's ~ equivalent to the c++ class:
> 
> class TEST{
>private:
>int INSTANCEFIELD;
>static int STATICFIELD;
>public:
>void INSTANCEMETHOD() {
>INSTANCEFIELD++;
>}
>static void STATICMETHOD() {
>STATICFIELD++;
>}
> };
> 
> the name "STATICMETHOD" is properly encoded in the dwarf debug info (where 
> linkage name is the mangled name). I want "STATICMETHOD" back as it would be 
> encoded in DW_AT_NAME.
> 
> I also want to get the SBType for "TEST" when I have the SBFunction for 
> INSTANCEMETHOD/STATICMETHOD.
> 
> Both things are properly encoded in dwarf (as matching the c++ output), 
> however I can't seem to find the right SB method to get it.

We currently have a way for you to find the SBType for "TEST" and then ask that 
type for its member functions:



SBType test_type = module.FindFirstType("TEST");
const uint32_t num_member_functions = test_type.GetNumberOfMemberFunctions();
for (uint32_t i=0; i 
> 
>> 
>>> 
>>> Lastly: How do I encode if a method is static or not, I couldn't find
>>> any difference in what C++ does for instance vs static.

You can already ask a member function for its kind:

  lldb::MemberFunctionKind lldb::SBTypeMemberFunction::GetKind();

This should help for member functions.

>> 
>> There is  "DW_AT_object_pointer". Debuggers can also make that decision
>> based on presence of "this" parameter.
>> 


The member function type should be correctly encoded and can be accessed by 
lldb::SBTypeMemberFunction::GetKind(). 

> 
> Thanks.
> 
> -- 
> Carlo Kok
> RemObjects Software
> ___
> 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