Re: [lldb-dev] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback
Hello,
Yeah you are right Mikhail, thanks for pointing it out, I
must ask, is there any bug already logged for this issue ?
Ravi
On Mon, Nov 16, 2015 at 5:24 PM, Mikhail Filimonov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi guys and thank you for the excellent community project!
>
>
>
> Recently I’ve stumbled on a pesky, but trivial Invalid iterator
> dereference bug in SymbolContext and TypeMap implementations at revisions
>
>
> https://github.com/llvm-mirror/lldb/blob/e528da256d14ecac7df858462b44dca931879509/source/Symbol/SymbolContext.cpp#L823
>
> and
>
>
> https://github.com/llvm-mirror/lldb/blob/5ac1fc5bc961688505334395598a2bb174eabd3b/source/Symbol/TypeMap.cpp#L172
>
>
>
> From the code below it is obvious that TypeMap::ForEach calls the
> pre-increment operator on m_types iterator right after it has been
> invalidated by m_types.erase
>
>
>
> SymbolContext::SortTypeList(TypeMap &type_map, TypeList &type_list ) const
>
> {
>
> TypeMaptoList callbackM2L (type_map, type_list);
>
> type_map.ForEach(callbackM2L);
>
> return ;
>
> }
>
>
>
> void
>
> TypeMap::ForEach (std::function const
> &callback)
>
> {
>
> for (auto pos = m_types.begin(), end = m_types.end(); pos != end;
> ++pos)
>
> {
>
> if (!callback(pos->second))
>
> break;
>
> }
>
> }
>
>
>
> bool
>
> TypeMap::RemoveTypeWithUID (user_id_t uid)
>
> {
>
> iterator pos = m_types.find(uid);
>
>
>
> if (pos != m_types.end())
>
> {
>
> m_types.erase(pos);
>
> return true;
>
> }
>
> return false;
>
> }
>
>
>
> class TypeMaptoList
>
> {
>
> public:
>
> TypeMaptoList(TypeMap &typem, TypeList &typel) :
>
> type_map(typem),type_list(typel)
>
> {
>
> }
>
>
>
> bool
>
> operator() (const lldb::TypeSP& type)
>
> {
>
> if(type)
>
> {
>
> type_list.Insert(type);
>
> type_map.RemoveTypeWithUID(type->GetID());
>
> if (type_map.Empty())
>
> return false;
>
> }
>
> return true;
>
> }
>
>
>
> private:
>
> TypeMap &type_map;
>
> TypeList &type_list;
>
> };
>
>
>
> Regards,
>
> Mikhail Filimonov
>
>
>
>
>
>
> --
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information. Any unauthorized review, use,
> disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
> --
>
> ___
> 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] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback
Hello,
Pavel- my question is how do we solve it ? should Mikhail log a bug ?
for this issue
BR,
A Ravi Theja
On Tue, Nov 17, 2015 at 10:42 AM, Ravitheja Addepally <
ravithejaw...@gmail.com> wrote:
> Hello,
>
> Yeah you are right Mikhail, thanks for pointing it out, I
> must ask, is there any bug already logged for this issue ?
>
> Ravi
>
> On Mon, Nov 16, 2015 at 5:24 PM, Mikhail Filimonov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi guys and thank you for the excellent community project!
>>
>>
>>
>> Recently I’ve stumbled on a pesky, but trivial Invalid iterator
>> dereference bug in SymbolContext and TypeMap implementations at revisions
>>
>>
>> https://github.com/llvm-mirror/lldb/blob/e528da256d14ecac7df858462b44dca931879509/source/Symbol/SymbolContext.cpp#L823
>>
>> and
>>
>>
>> https://github.com/llvm-mirror/lldb/blob/5ac1fc5bc961688505334395598a2bb174eabd3b/source/Symbol/TypeMap.cpp#L172
>>
>>
>>
>> From the code below it is obvious that TypeMap::ForEach calls the
>> pre-increment operator on m_types iterator right after it has been
>> invalidated by m_types.erase
>>
>>
>>
>> SymbolContext::SortTypeList(TypeMap &type_map, TypeList &type_list ) const
>>
>> {
>>
>> TypeMaptoList callbackM2L (type_map, type_list);
>>
>> type_map.ForEach(callbackM2L);
>>
>> return ;
>>
>> }
>>
>>
>>
>> void
>>
>> TypeMap::ForEach (std::function const
>> &callback)
>>
>> {
>>
>> for (auto pos = m_types.begin(), end = m_types.end(); pos != end;
>> ++pos)
>>
>> {
>>
>> if (!callback(pos->second))
>>
>> break;
>>
>> }
>>
>> }
>>
>>
>>
>> bool
>>
>> TypeMap::RemoveTypeWithUID (user_id_t uid)
>>
>> {
>>
>> iterator pos = m_types.find(uid);
>>
>>
>>
>> if (pos != m_types.end())
>>
>> {
>>
>> m_types.erase(pos);
>>
>> return true;
>>
>> }
>>
>> return false;
>>
>> }
>>
>>
>>
>> class TypeMaptoList
>>
>> {
>>
>> public:
>>
>> TypeMaptoList(TypeMap &typem, TypeList &typel) :
>>
>> type_map(typem),type_list(typel)
>>
>> {
>>
>> }
>>
>>
>>
>> bool
>>
>> operator() (const lldb::TypeSP& type)
>>
>> {
>>
>> if(type)
>>
>> {
>>
>> type_list.Insert(type);
>>
>> type_map.RemoveTypeWithUID(type->GetID());
>>
>> if (type_map.Empty())
>>
>> return false;
>>
>> }
>>
>> return true;
>>
>> }
>>
>>
>>
>> private:
>>
>> TypeMap &type_map;
>>
>> TypeList &type_list;
>>
>> };
>>
>>
>>
>> Regards,
>>
>> Mikhail Filimonov
>>
>>
>>
>>
>>
>>
>> --
>> This email message is for the sole use of the intended recipient(s) and
>> may contain confidential information. Any unauthorized review, use,
>> disclosure or distribution is prohibited. If you are not the intended
>> recipient, please contact the sender by reply email and destroy all copies
>> of the original message.
>> --
>>
>> ___
>> 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] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback
Thanx, The invalid iterator problem was only in the last iteration, but I
think you modified all the For Loops.
On Fri, Nov 20, 2015 at 12:13 AM, Greg Clayton wrote:
> I fixed this:
>
> % svn commit
> Sendinginclude/lldb/Symbol/TypeMap.h
> Sendingsource/Symbol/SymbolContext.cpp
> Sendingsource/Symbol/TypeMap.cpp
> Transmitting file data ...
> Committed revision 253618.
>
>
> > On Nov 18, 2015, at 12:54 AM, Ravitheja Addepally via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hello,
> > Pavel- my question is how do we solve it ? should Mikhail log a bug
> ? for this issue
> >
> > BR,
> > A Ravi Theja
> >
> > On Tue, Nov 17, 2015 at 10:42 AM, Ravitheja Addepally <
> ravithejaw...@gmail.com> wrote:
> > Hello,
> >
> > Yeah you are right Mikhail, thanks for pointing it out,
> I must ask, is there any bug already logged for this issue ?
> >
> > Ravi
> >
> >
> > On Mon, Nov 16, 2015 at 5:24 PM, Mikhail Filimonov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > Hi guys and thank you for the excellent community project!
> >
> >
> >
> > Recently I’ve stumbled on a pesky, but trivial Invalid iterator
> dereference bug in SymbolContext and TypeMap implementations at revisions
> >
> >
> https://github.com/llvm-mirror/lldb/blob/e528da256d14ecac7df858462b44dca931879509/source/Symbol/SymbolContext.cpp#L823
> >
> > and
> >
> >
> https://github.com/llvm-mirror/lldb/blob/5ac1fc5bc961688505334395598a2bb174eabd3b/source/Symbol/TypeMap.cpp#L172
> >
> >
> >
> > From the code below it is obvious that TypeMap::ForEach calls the
> pre-increment operator on m_types iterator right after it has been
> invalidated by m_types.erase
> >
> >
> >
> > SymbolContext::SortTypeList(TypeMap &type_map, TypeList &type_list )
> const
> >
> > {
> >
> > TypeMaptoList callbackM2L (type_map, type_list);
> >
> > type_map.ForEach(callbackM2L);
> >
> > return ;
> >
> > }
> >
> >
> >
> > void
> >
> > TypeMap::ForEach (std::function const
> &callback)
> >
> > {
> >
> > for (auto pos = m_types.begin(), end = m_types.end(); pos != end;
> ++pos)
> >
> > {
> >
> > if (!callback(pos->second))
> >
> > break;
> >
> > }
> >
> > }
> >
> >
> >
> > bool
> >
> > TypeMap::RemoveTypeWithUID (user_id_t uid)
> >
> > {
> >
> > iterator pos = m_types.find(uid);
> >
> >
> >
> > if (pos != m_types.end())
> >
> > {
> >
> > m_types.erase(pos);
> >
> > return true;
> >
> > }
> >
> > return false;
> >
> > }
> >
> >
> >
> > class TypeMaptoList
> >
> > {
> >
> > public:
> >
> > TypeMaptoList(TypeMap &typem, TypeList &typel) :
> >
> > type_map(typem),type_list(typel)
> >
> > {
> >
> > }
> >
> >
> >
> > bool
> >
> > operator() (const lldb::TypeSP& type)
> >
> > {
> >
> > if(type)
> >
> > {
> >
> > type_list.Insert(type);
> >
> > type_map.RemoveTypeWithUID(type->GetID());
> >
> > if (type_map.Empty())
> >
> > return false;
> >
> > }
> >
> > return true;
> >
> > }
> >
> >
> >
> > private:
> >
> > TypeMap &type_map;
> >
> > TypeList &type_list;
> >
> > };
> >
> >
> >
> > Regards,
> >
> > Mikhail Filimonov
> >
> >
> >
> >
> >
> >
> >
> > This email message is for the sole use of the intended recipient(s) and
> may contain confidential information. Any unauthorized review, use,
> disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
> >
> > ___
> > 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
[lldb-dev] Inquiry about .debug_frame
Hello, While compiling with clang for i386, I notice that the CFI information is distributed between the .eh_frame section and the .debug_frame section, meaning for some functions the CFI info is present in the .debug_frame section whereas for some it is present in the .eh_frame. Now looking at the lldb code, I see that this information is only read from the .eh_frame section and not from the .debug_frame section. My questions are the following -> 1) Is there something that I missing ? is the information that I provided in this email correct ? 2) If it is correct, is this expected behavior ? I mean if the CFI info is present in the .debug_frame then I think it should be read ? coz it maybe useful in unwinding scenarios ? BR, A Ravi ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inquiry about .debug_frame
Yes sure. On Wed, Nov 25, 2015 at 8:00 AM, wrote: > lldb should be able to read both. Can you file a bug please? > On Tue, Nov 24, 2015 at 02:50:20PM +0100, Ravitheja Addepally via lldb-dev > wrote: > > Hello, > >While compiling with clang for i386, I notice that the CFI > > information is distributed between the .eh_frame section and the > > .debug_frame section, meaning for some functions the CFI info is present > in > > the .debug_frame section whereas for some it is present in the .eh_frame. > > Now looking at the lldb code, I see that this information is only read > > from the .eh_frame section and not from the .debug_frame section. My > > questions are the following -> > > 1) Is there something that I missing ? is the information that I > provided > > in this email correct ? > > 2) If it is correct, is this expected behavior ? I mean if the CFI info > is > > present in the .debug_frame then I think it should be read ? coz it maybe > > useful in unwinding scenarios ? > > > > > > BR, > > A Ravi > > > ___ > > 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] Inquiry for performance monitors
r)? > >> > >> As Pavel said, how are you planning to present the information to the > user? Through some sort of top level command like "perfcount > instructions_retired"? > >> > >> On Wed, Oct 21, 2015 at 8:16 AM Pavel Labath via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> [ Moving this discussion back to the list. I pressed the wrong button > >> when replying.] > >> > >> Thanks for the explanation Ravi. It sounds like a very useful feature > >> indeed. I've found a reference to the debugserver profile data in > >> GDBRemoteCommunicationClient.cpp:1276, so maybe that will help with > >> your investigation. Maybe also someone more knowledgeable can explain > >> what those A packets are used for (?). > >> > >> > >> On 21 October 2015 at 15:48, Ravitheja Addepally > >> wrote: > >>> Hi, > >>> Thanx for your reply, some of the future processors to be released by > >>> Intel have this hardware support for recording the instructions that > were > >>> executed by the processor and this recording process is also quite > fast and > >>> does not add too much computational load. Now this hardware is made > >>> accessible via the perf_event_interface where one could map a region of > >>> memory for this purpose by passing it as an argument to this > >>> perf_event_interface. The recorded instructions are then written to the > >>> memory region assigned. Now this is basically the raw information, > which can > >>> be obtained from the hardware. It can be interpreted and presented to > the > >>> user in the following ways -> > >>> > >>> 1) Instruction history - where the user gets basically a list of all > >>> instructions that were executed > >>> 2) Function Call History - It is also possible to get a list of all the > >>> functions called in the inferior > >>> 3) Reverse Debugging with limited information - In GDB this is only the > >>> functions executed. > >>> > >>> This raw information also needs to decoded (even before you can > disassemble > >>> it ), there is already a library released by Intel called libipt which > can > >>> do that. At the moment we plan to work with Instruction History. > >>> I will look into the debugserver infrastructure and get back to you. I > guess > >>> for the server client communication we would rely on packets only. In > case > >>> of concerns about too much data being transferred, we can limit the > number > >>> of entries we report because anyway the amount of data recorded is too > big > >>> to present all at once so we would have to resort to something like a > >>> viewport. > >>> > >>> Since a lot of instructions can be recorded this way, the function call > >>> history can be quite useful for debugging and especially since it is a > lot > >>> faster to collect function traces this way. > >>> > >>> -ravi > >>> > >>> On Wed, Oct 21, 2015 at 3:14 PM, Pavel Labath > wrote: > >>>> > >>>> Hi, > >>>> > >>>> I am not really familiar with the perf_event interface (and I suspect > >>>> others aren't also), so it might help if you explain what kind of > >>>> information do you plan to collect from there. > >>>> > >>>> As for the PtraceWrapper question, I think that really depends on > >>>> bigger design decisions. My two main questions for a feature like this > >>>> would be: > >>>> - How are you going to present this information to the user? (I know > >>>> debugserver can report some performance data... Have you looked into > >>>> how that works? Do you plan to reuse some parts of that > >>>> infrastructure?) > >>>> - How will you get the information from the server to the client? > >>>> > >>>> pl > >>>> > >>>> > >>>> On 21 October 2015 at 13:41, Ravitheja Addepally via lldb-dev > >>>> wrote: > >>>>> Hello, > >>>>> I want to implement support for reading Performance measurement > >>>>> information using the perf_event_open system calls. The motive is to > add > >>>>> support for Intel PT hardware feature, which is available through the > >>>>> perf_event interface. I was thinking of implementing a new Wrapper > like > >>>>> PtraceWrapper in NativeProcessLinux files. My query is that, is this > a > >>>>> correct place to start or not ? in case not, could someone suggest me > >>>>> another place to begin with ? > >>>>> > >>>>> BR, > >>>>> A Ravi Theja > >>>>> > >>>>> > >>>>> ___ > >>>>> 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 > > > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inquiry for performance monitors
> > >>> This raw information also needs to decoded (even before you can > disassemble > > >>> it ), there is already a library released by Intel called libipt > which can > > >>> do that. At the moment we plan to work with Instruction History. > > >>> I will look into the debugserver infrastructure and get back to you. > I guess > > >>> for the server client communication we would rely on packets only. > In case > > >>> of concerns about too much data being transferred, we can limit the > number > > >>> of entries we report because anyway the amount of data recorded is > too big > > >>> to present all at once so we would have to resort to something like a > > >>> viewport. > > >>> > > >>> Since a lot of instructions can be recorded this way, the function > call > > >>> history can be quite useful for debugging and especially since it is > a lot > > >>> faster to collect function traces this way. > > >>> > > >>> -ravi > > >>> > > >>> On Wed, Oct 21, 2015 at 3:14 PM, Pavel Labath > wrote: > > >>>> > > >>>> Hi, > > >>>> > > >>>> I am not really familiar with the perf_event interface (and I > suspect > > >>>> others aren't also), so it might help if you explain what kind of > > >>>> information do you plan to collect from there. > > >>>> > > >>>> As for the PtraceWrapper question, I think that really depends on > > >>>> bigger design decisions. My two main questions for a feature like > this > > >>>> would be: > > >>>> - How are you going to present this information to the user? (I know > > >>>> debugserver can report some performance data... Have you looked into > > >>>> how that works? Do you plan to reuse some parts of that > > >>>> infrastructure?) > > >>>> - How will you get the information from the server to the client? > > >>>> > > >>>> pl > > >>>> > > >>>> > > >>>> On 21 October 2015 at 13:41, Ravitheja Addepally via lldb-dev > > >>>> wrote: > > >>>>> Hello, > > >>>>> I want to implement support for reading Performance > measurement > > >>>>> information using the perf_event_open system calls. The motive is > to add > > >>>>> support for Intel PT hardware feature, which is available through > the > > >>>>> perf_event interface. I was thinking of implementing a new Wrapper > like > > >>>>> PtraceWrapper in NativeProcessLinux files. My query is that, is > this a > > >>>>> correct place to start or not ? in case not, could someone suggest > me > > >>>>> another place to begin with ? > > >>>>> > > >>>>> BR, > > >>>>> A Ravi Theja > > >>>>> > > >>>>> > > >>>>> ___ > > >>>>> 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 > > > > > > > > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inquiry for performance monitors
gt;> > >> > >> There is also the question of this third party library. Do we > take a > >> > >> hard dependency on libipt (probably a non-starter), or only use it > if it's > >> > >> available (much better)? > >> > >> > >> > >> As Pavel said, how are you planning to present the information to > the > >> > >> user? Through some sort of top level command like "perfcount > >> > >> instructions_retired"? > >> > >> > >> > >> On Wed, Oct 21, 2015 at 8:16 AM Pavel Labath via lldb-dev > >> > >> wrote: > >> > >> [ Moving this discussion back to the list. I pressed the wrong > button > >> > >> when replying.] > >> > >> > >> > >> Thanks for the explanation Ravi. It sounds like a very useful > feature > >> > >> indeed. I've found a reference to the debugserver profile data in > >> > >> GDBRemoteCommunicationClient.cpp:1276, so maybe that will help with > >> > >> your investigation. Maybe also someone more knowledgeable can > explain > >> > >> what those A packets are used for (?). > >> > >> > >> > >> > >> > >> On 21 October 2015 at 15:48, Ravitheja Addepally > >> > >> wrote: > >> > >>> Hi, > >> > >>> Thanx for your reply, some of the future processors to be > released > >> > >>> by > >> > >>> Intel have this hardware support for recording the instructions > that > >> > >>> were > >> > >>> executed by the processor and this recording process is also quite > >> > >>> fast and > >> > >>> does not add too much computational load. Now this hardware is > made > >> > >>> accessible via the perf_event_interface where one could map a > region > >> > >>> of > >> > >>> memory for this purpose by passing it as an argument to this > >> > >>> perf_event_interface. The recorded instructions are then written > to > >> > >>> the > >> > >>> memory region assigned. Now this is basically the raw information, > >> > >>> which can > >> > >>> be obtained from the hardware. It can be interpreted and presented > >> > >>> to the > >> > >>> user in the following ways -> > >> > >>> > >> > >>> 1) Instruction history - where the user gets basically a list of > all > >> > >>> instructions that were executed > >> > >>> 2) Function Call History - It is also possible to get a list of > all > >> > >>> the > >> > >>> functions called in the inferior > >> > >>> 3) Reverse Debugging with limited information - In GDB this is > only > >> > >>> the > >> > >>> functions executed. > >> > >>> > >> > >>> This raw information also needs to decoded (even before you can > >> > >>> disassemble > >> > >>> it ), there is already a library released by Intel called libipt > >> > >>> which can > >> > >>> do that. At the moment we plan to work with Instruction History. > >> > >>> I will look into the debugserver infrastructure and get back to > you. > >> > >>> I guess > >> > >>> for the server client communication we would rely on packets only. > >> > >>> In case > >> > >>> of concerns about too much data being transferred, we can limit > the > >> > >>> number > >> > >>> of entries we report because anyway the amount of data recorded is > >> > >>> too big > >> > >>> to present all at once so we would have to resort to something > like > >> > >>> a > >> > >>> viewport. > >> > >>> > >> > >>> Since a lot of instructions can be recorded this way, the function > >> > >>> call > >> > >>> history can be quite useful for debugging and especially since it > is > >> > >>> a lot > >> > >>> faster to collect function traces this way. > >> > >>> > >> > >>> -ravi > >> > >>> > >> > >>> On Wed, Oct 21, 2015 at 3:14 PM, Pavel Labath > >> > >>> wrote: > >> > >>>> > >> > >>>> Hi, > >> > >>>> > >> > >>>> I am not really familiar with the perf_event interface (and I > >> > >>>> suspect > >> > >>>> others aren't also), so it might help if you explain what kind of > >> > >>>> information do you plan to collect from there. > >> > >>>> > >> > >>>> As for the PtraceWrapper question, I think that really depends on > >> > >>>> bigger design decisions. My two main questions for a feature like > >> > >>>> this > >> > >>>> would be: > >> > >>>> - How are you going to present this information to the user? (I > >> > >>>> know > >> > >>>> debugserver can report some performance data... Have you looked > >> > >>>> into > >> > >>>> how that works? Do you plan to reuse some parts of that > >> > >>>> infrastructure?) > >> > >>>> - How will you get the information from the server to the client? > >> > >>>> > >> > >>>> pl > >> > >>>> > >> > >>>> > >> > >>>> On 21 October 2015 at 13:41, Ravitheja Addepally via lldb-dev > >> > >>>> wrote: > >> > >>>>> Hello, > >> > >>>>> I want to implement support for reading Performance > >> > >>>>> measurement > >> > >>>>> information using the perf_event_open system calls. The motive > is > >> > >>>>> to add > >> > >>>>> support for Intel PT hardware feature, which is available > through > >> > >>>>> the > >> > >>>>> perf_event interface. I was thinking of implementing a new > Wrapper > >> > >>>>> like > >> > >>>>> PtraceWrapper in NativeProcessLinux files. My query is that, is > >> > >>>>> this a > >> > >>>>> correct place to start or not ? in case not, could someone > suggest > >> > >>>>> me > >> > >>>>> another place to begin with ? > >> > >>>>> > >> > >>>>> BR, > >> > >>>>> A Ravi Theja > >> > >>>>> > >> > >>>>> > >> > >>>>> ___ > >> > >>>>> 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 > >> > > > >> > > >> > > >> > > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inquiry for performance monitors
but it's worth considering whether this could be >> >> >> > >> designed in a >> >> >> > >> way to support both (i.e. even if you don't do both yourself, >> at >> >> >> > >> least make >> >> >> > >> the machinery reusable and apply to both for when someone else >> >> >> > >> wanted to >> >> >> > >> come through and add OS perf counters). >> >> >> > >> >> >> >> > >> There is also the question of this third party library. Do we >> >> >> > >> take a >> >> >> > >> hard dependency on libipt (probably a non-starter), or only >> use it >> >> >> > >> if it's >> >> >> > >> available (much better)? >> >> >> > >> >> >> >> > >> As Pavel said, how are you planning to present the information >> to >> >> >> > >> the >> >> >> > >> user? Through some sort of top level command like "perfcount >> >> >> > >> instructions_retired"? >> >> >> > >> >> >> >> > >> On Wed, Oct 21, 2015 at 8:16 AM Pavel Labath via lldb-dev >> >> >> > >> wrote: >> >> >> > >> [ Moving this discussion back to the list. I pressed the wrong >> >> >> > >> button >> >> >> > >> when replying.] >> >> >> > >> >> >> >> > >> Thanks for the explanation Ravi. It sounds like a very useful >> >> >> > >> feature >> >> >> > >> indeed. I've found a reference to the debugserver profile data >> in >> >> >> > >> GDBRemoteCommunicationClient.cpp:1276, so maybe that will help >> >> >> > >> with >> >> >> > >> your investigation. Maybe also someone more knowledgeable can >> >> >> > >> explain >> >> >> > >> what those A packets are used for (?). >> >> >> > >> >> >> >> > >> >> >> >> > >> On 21 October 2015 at 15:48, Ravitheja Addepally >> >> >> > >> wrote: >> >> >> > >>> Hi, >> >> >> > >>> Thanx for your reply, some of the future processors to be >> >> >> > >>> released >> >> >> > >>> by >> >> >> > >>> Intel have this hardware support for recording the >> instructions >> >> >> > >>> that >> >> >> > >>> were >> >> >> > >>> executed by the processor and this recording process is also >> >> >> > >>> quite >> >> >> > >>> fast and >> >> >> > >>> does not add too much computational load. Now this hardware is >> >> >> > >>> made >> >> >> > >>> accessible via the perf_event_interface where one could map a >> >> >> > >>> region >> >> >> > >>> of >> >> >> > >>> memory for this purpose by passing it as an argument to this >> >> >> > >>> perf_event_interface. The recorded instructions are then >> written >> >> >> > >>> to >> >> >> > >>> the >> >> >> > >>> memory region assigned. Now this is basically the raw >> >> >> > >>> information, >> >> >> > >>> which can >> >> >> > >>> be obtained from the hardware. It can be interpreted and >> >> >> > >>> presented >> >> >> > >>> to the >> >> >> > >>> user in the following ways -> >> >> >> > >>> >> >> >> > >>> 1) Instruction history - where the user gets basically a list >> of >> >> >> > >>> all >> >> >> > >>> instructions that were executed >> >> >> > >>> 2) Function Call History - It is also possible to get a list >> of >> >> >> > >>> all >> >> >> > >>> the >> >> >> > >>> functions called in the inferior >> >> >> > >>> 3) Reverse Debugging with limited information - In GDB this is >> >> >> > >>> only >> >> >> > >>> the >> >> >> > >>> functions executed. >> >> >> > >>> >> >> >> > >>> This raw information also needs to decoded (even before you >> can >> >> >> > >>> disassemble >> >> >> > >>> it ), there is already a library released by Intel called >> libipt >> >> >> > >>> which can >> >> >> > >>> do that. At the moment we plan to work with Instruction >> History. >> >> >> > >>> I will look into the debugserver infrastructure and get back >> to >> >> >> > >>> you. >> >> >> > >>> I guess >> >> >> > >>> for the server client communication we would rely on packets >> >> >> > >>> only. >> >> >> > >>> In case >> >> >> > >>> of concerns about too much data being transferred, we can >> limit >> >> >> > >>> the >> >> >> > >>> number >> >> >> > >>> of entries we report because anyway the amount of data >> recorded >> >> >> > >>> is >> >> >> > >>> too big >> >> >> > >>> to present all at once so we would have to resort to something >> >> >> > >>> like >> >> >> > >>> a >> >> >> > >>> viewport. >> >> >> > >>> >> >> >> > >>> Since a lot of instructions can be recorded this way, the >> >> >> > >>> function >> >> >> > >>> call >> >> >> > >>> history can be quite useful for debugging and especially >> since it >> >> >> > >>> is >> >> >> > >>> a lot >> >> >> > >>> faster to collect function traces this way. >> >> >> > >>> >> >> >> > >>> -ravi >> >> >> > >>> >> >> >> > >>> On Wed, Oct 21, 2015 at 3:14 PM, Pavel Labath < >> lab...@google.com> >> >> >> > >>> wrote: >> >> >> > >>>> >> >> >> > >>>> Hi, >> >> >> > >>>> >> >> >> > >>>> I am not really familiar with the perf_event interface (and I >> >> >> > >>>> suspect >> >> >> > >>>> others aren't also), so it might help if you explain what >> kind >> >> >> > >>>> of >> >> >> > >>>> information do you plan to collect from there. >> >> >> > >>>> >> >> >> > >>>> As for the PtraceWrapper question, I think that really >> depends >> >> >> > >>>> on >> >> >> > >>>> bigger design decisions. My two main questions for a feature >> >> >> > >>>> like >> >> >> > >>>> this >> >> >> > >>>> would be: >> >> >> > >>>> - How are you going to present this information to the user? >> (I >> >> >> > >>>> know >> >> >> > >>>> debugserver can report some performance data... Have you >> looked >> >> >> > >>>> into >> >> >> > >>>> how that works? Do you plan to reuse some parts of that >> >> >> > >>>> infrastructure?) >> >> >> > >>>> - How will you get the information from the server to the >> >> >> > >>>> client? >> >> >> > >>>> >> >> >> > >>>> pl >> >> >> > >>>> >> >> >> > >>>> >> >> >> > >>>> On 21 October 2015 at 13:41, Ravitheja Addepally via lldb-dev >> >> >> > >>>> wrote: >> >> >> > >>>>> Hello, >> >> >> > >>>>> I want to implement support for reading Performance >> >> >> > >>>>> measurement >> >> >> > >>>>> information using the perf_event_open system calls. The >> motive >> >> >> > >>>>> is >> >> >> > >>>>> to add >> >> >> > >>>>> support for Intel PT hardware feature, which is available >> >> >> > >>>>> through >> >> >> > >>>>> the >> >> >> > >>>>> perf_event interface. I was thinking of implementing a new >> >> >> > >>>>> Wrapper >> >> >> > >>>>> like >> >> >> > >>>>> PtraceWrapper in NativeProcessLinux files. My query is >> that, is >> >> >> > >>>>> this a >> >> >> > >>>>> correct place to start or not ? in case not, could someone >> >> >> > >>>>> suggest >> >> >> > >>>>> me >> >> >> > >>>>> another place to begin with ? >> >> >> > >>>>> >> >> >> > >>>>> BR, >> >> >> > >>>>> A Ravi Theja >> >> >> > >>>>> >> >> >> > >>>>> >> >> >> > >>>>> ___ >> >> >> > >>>>> 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 >> >> >> > > >> >> >> > >> >> >> > >> >> >> >> >> > >> > >> > >> ___ >> 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] Inquiry for performance monitors
Yes, thanx for the clarification. On Thu, Feb 4, 2016 at 11:24 AM, Pavel Labath wrote: > On 4 February 2016 at 10:04, Ravitheja Addepally > wrote: > > Hello Pavel, > > In the case of expression evaluation approach you > mentioned > > that: > > 1. The data could be accessible only when the target is stopped. why is > that > > ? > If I understand the approach correctly, the idea is the run all perf > calls as expressions in the debugger. Something like > lldb> expr perf_event_open(...) > We need to stop the target to be able to do something like that, as we > need to fiddle with its registers. I don't see any way around that... > > > 2. What sort of noise were you referring to ? > Since now all the perf calls will be expressions executed within the > context of the process being traced, they themselves will show up in > the trace. I am sure we could filter that out somehow, but it feels > like an added complication.. > > Does that make it any clearer? > > pl > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Inquiry about Load Address
Hello, I wanted to know if there is any existing API or a set of API's that could be used to retrieve the load addresses of the Modules ? secondly Can we obtain the dumps of the loaded Elf 's like in the remote case transporting them from the target to the host ? BR, A Ravi Theja ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inquiry about Load Address
Ok, I am currently in the process of developing Intel Processor trace support for LLDB , I need the virtual address mappings for the Elf's for decoding the trace data. I will check if SBSection.GetSectionData will work or not , Thanks for the info. On Tue, Mar 8, 2016 at 12:11 PM, Pavel Labath wrote: > Hi, > > could you give us a bit more background about what are you trying to > do? It's hard to answer the question without knowing a bit more... > > On 8 March 2016 at 10:42, Ravitheja Addepally via lldb-dev > wrote: > > Hello, > > I wanted to know if there is any existing API or a set of API's > that > > could be used to retrieve the load addresses of the Modules ? > > There is a GetLoadAddress function on SBSection > <http://lldb.llvm.org/cpp_reference/html/classlldb_1_1SBSection.html>. > I don't see one on SBModule though. What do you need this for? > > > secondly Can > > we obtain the dumps of the loaded Elf 's like in the remote case > > transporting them from the target to the host ? > > > > What kind of "dumps" are you looking for? Will > SBSection.GetSectionData() work? A lot of other data is available in > the other SB classes, but it's hard to answer this without knowing > what exactly you are looking for. > > pl > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Inquiry about LLDB remote protocol
Hello, I wanted to know if the remote protocol of LLDB is state less or not ? When i say state I am referring to if LLDB remembers the current process or thread being debugged (which would mean we dont need to specify that in the client to server packets ) . I was looking at the GDBRemoteCommunicationServerLLGS and found that most of the packets did not have the pid or thread id being passed to the server , so is it safe to assume that the protocol is statefull ? is this assumption also valid for all OS's ? ---Ravi ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inquiry about LLDB remote protocol
Thank you all for the information. On Tue, Mar 29, 2016 at 7:25 PM, Greg Clayton wrote: > > > On Mar 29, 2016, at 2:57 AM, Ravitheja Addepally via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hello, > > I wanted to know if the remote protocol of LLDB is state less or > not ? When i say state I am referring to if LLDB remembers the current > process or thread being debugged (which would mean we dont need to specify > that in the client to server packets ) . I was looking at the > GDBRemoteCommunicationServerLLGS and found that most of the packets did not > have the pid or thread id being passed to the server , so is it safe to > assume that the protocol is statefull ? > > Yes. There is the notion that you have one process that may or may not be > there when you connect. When and if a process does exist, it assumes it > won't change. Threads can be selected and many packets operate of the > current thread. We have also added new packets to allow us to append a > thread ID suffix to existing packets, like reading and writing registers. > This allows us to save a packet round trip so we don't always have to say > "set thread to thread 123" and then "read register 12". > > > is this assumption also valid for all OS's ? > > Yep. Very stateful. > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Review of API and remote packets
Hello all,
I am currently working on enabling Intel (R) Processor Trace
collection for lldb. I have done some previous discussions in this mailing
list on this topic but just to summarize , the path we chose was to
implement raw trace collection in lldb and the trace will be decoded
outside LLDB. I wanted to expose this feature through the SB API's and for
trace data transfer I wish to develop new communication packets. Now I want
to get the new API's and packet specifications reviewed by the dev list.
Please find the specification below ->
lldb::SBError SBProcess::StartTrace(lldb::tid_t threadId, const
SBTraceConfig &config)
Start tracing for thread - threadId with trace configuration config.
SBTraceConfig would contain the following fields-
-> TraceType - ProcessorTrace, SoftwareTrace , any trace
technology etc
-> size of trace buffer
-> size of meta data buffer
Returns error in case starting trace was unsuccessful, which could
occur by reasons such as
picking non existent thread, target does not support TraceType selected
etc.
lldb::SBError SBProcess::StopTrace(lldb::tid_t threadId)
Stop tracing for thread - threadId. Tracing should be enabled already
for thread, else error is returned.
size_t SBProcess::DumpTraceData(lldb::tid_t threadId, void *buf, size_t
size, SBError &sberror)
Dump the raw trace data for threadId in buffer described by pointer buf
and size. Tracing should be enabled already for thread else error
is sent in sberror. The actual size of filled buffer is returned by API.
size_t SBProcess::DumpTraceMetaData(lldb::tid_t threadId, void *buf, size_t
size, SBError &sberror)
Dump the raw trace meta data for threadId in buffer described by
pointer buf and size. Tracing should be enabled already for thread
else error is sent in sberror. The actual size of filled buffer is
returned by API.
LLDB Trace Packet Specification
QTrace:1:,,,
Packet for starting tracing, where -
-> threadid - stands for thread to trace
-> type - Type of tracing to use, it will be like type of trace
mechanism to use.
For e.g ProcessorTrace, SoftwareTrace , any trace
technology etc and if
that trace is not supported by target error will be
returned. In Future
we can also add more parameters in the packet
specification, which can be type specific
and the server can parse them based on what type it
read in the beginning.
-> buffersize - Size for trace buffer
-> metabuffersize - Size of Meta Data
QTrace:0:
Stop tracing thread with threadid,{Trace needs to be started of-course
else error}
qXfer:trace:buffer:read:annex:,
Packet for reading the trace buffer
-> threadid - thread ID, of-course if tracing is not
started for this thread error will be returned.
-> byte_count - number of bytes to read, in case trace captured is
less than byte_count, then only that much trace will
be returned in response packet.
qXfer:trace:meta:read:annex:,
Similar Packet as above except it reads meta data
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Inquiry about SBFileSpec
Hello, The SBFileSpec class of APIs can be used to read files on the local file system right ? I want to know if it can be used for reading files on the remote file system ? or do we need to use some other API ? BR, A Ravi Theja ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Review of API and remote packets
Hello, Regarding the packet definitions for tracing, how about reusing the existing btrace packets ? https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton wrote: > We also need to think about all other types of tracing. It might make more > sense to keep these calls on SBProcess and have the calls simply be: > > > lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions &trace_options, > lldb::SBError &error); > > And you would need to specify which threads in the SBTraceOptions object > itself?: > > SBTraceOptions trace_options; > > And then do some like: > > trace_options.SetTraceAllThreads(); > > And maybe tracing all threads is the default. Or one can limit this to one > thread: > > trace_options.SetThreadID (tid); > > Then you start tracing using the "trace_options" which has the notion of > which threads to trace. > > lldb::SBError error; > lldb::SBTrace trace = process.StartTrace(trace_options, error); > > It really depends on how all different forms of trace are enabled for > different kinds of tracing. It takes kernel support to trace only specific > threads, but someone might be debugging a bare board that only has the > option tracing all threads on each core. When making an API we can't assume > we can limit this to any threads and even to any process. > > Greg > > > On Apr 1, 2016, at 2:00 AM, Pavel Labath wrote: > > > > I second Greg's suggestions, and I have some thoughts of my own: > > > > - with the proposed API, it is not possible to get a trace for newly > > created threads - the process needs to be stopped first, so you can > > enable trace collection. There certainly are cases where this could be > > problematic, e.g. if you get a crash early during thread creation and > > you want to figure out how you got there. For this to work, we might > > need an API like > > SBProcess::TraceNewThreads(...) > > or > > SBProcess::TraceAllThreads(...) > > with the assumption that "all" also includes newly created threads in > > the future. > > > > I'm not saying this needs to be done in the first implementation, but > > I think that we should at least design the API in a way that will not > > make adding this unnecessarily hard in the future (e.g. the idea of > > returning an SBTrace object might be problematic, since you don't know > > if/how many threads will be created). > > > > > > > > Also, thinking about new APIs, should we have a way to mark an API as > > incubating/experimental? Maybe it would be good to mark these new APIs > > as experimental for a while, so we have an option of changing them in > > the future, if it turns out we have made the wrong decision. I was > > thinking of either a naming convention > > (SBThread::StartTraceExperimental) or some annotation/comment on the > > methods. When we are confident this design is good, we can remove the > > promote the api into the "stable" set. > > > > pl > > > > > > > > > > On 31 March 2016 at 18:59, Greg Clayton via lldb-dev > > wrote: > >> > >>> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >>> > >>> Hello all, > >>> I am currently working on enabling Intel (R) Processor > Trace collection for lldb. I have done some previous discussions in this > mailing list on this topic but just to summarize , the path we chose was to > implement raw trace collection in lldb and the trace will be decoded > outside LLDB. I wanted to expose this feature through the SB API's and for > trace data transfer I wish to develop new communication packets. Now I want > to get the new API's and packet specifications reviewed by the dev list. > Please find the specification below -> > >>> > >>> lldb::SBError SBProcess::StartTrace(lldb::tid_t threadId, const > SBTraceConfig &config) > >>>Start tracing for thread - threadId with trace configuration config. > >>>SBTraceConfig would contain the following fields- > >>>-> TraceType - ProcessorTrace, SoftwareTrace , any trace > technology etc > >>>-> size of trace buffer > >>>-> size of meta data buffer > >>>Returns error in case starting trace was unsuccessful, which could > occur by reasons such as > >>>picking non existent thread, target does not support TraceType > sel
Re: [lldb-dev] Review of API and remote packets
One of the downsides of using the gdb protocol is that these packets are stateful meaning the thread id option is not there and the word btrace stands for branch trace which basically suggests execution tracing. On Mon, Apr 11, 2016 at 4:50 PM, Pavel Labath wrote: > I think we should reuse packets from the gdb protocol whereever it > makes sense. So, if they fit your needs (and a quick glance seems to > confirm that), then I think you should use them. > > On 11 April 2016 at 15:28, Ravitheja Addepally > wrote: > > Hello, > >Regarding the packet definitions for tracing, how about reusing > the > > existing btrace packets ? > > > > > https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read > > > > On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton wrote: > >> > >> We also need to think about all other types of tracing. It might make > more > >> sense to keep these calls on SBProcess and have the calls simply be: > >> > >> > >> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions &trace_options, > >> lldb::SBError &error); > >> > >> And you would need to specify which threads in the SBTraceOptions object > >> itself?: > >> > >> SBTraceOptions trace_options; > >> > >> And then do some like: > >> > >> trace_options.SetTraceAllThreads(); > >> > >> And maybe tracing all threads is the default. Or one can limit this to > one > >> thread: > >> > >> trace_options.SetThreadID (tid); > >> > >> Then you start tracing using the "trace_options" which has the notion of > >> which threads to trace. > >> > >> lldb::SBError error; > >> lldb::SBTrace trace = process.StartTrace(trace_options, error); > >> > >> It really depends on how all different forms of trace are enabled for > >> different kinds of tracing. It takes kernel support to trace only > specific > >> threads, but someone might be debugging a bare board that only has the > >> option tracing all threads on each core. When making an API we can't > assume > >> we can limit this to any threads and even to any process. > >> > >> Greg > >> > >> > On Apr 1, 2016, at 2:00 AM, Pavel Labath wrote: > >> > > >> > I second Greg's suggestions, and I have some thoughts of my own: > >> > > >> > - with the proposed API, it is not possible to get a trace for newly > >> > created threads - the process needs to be stopped first, so you can > >> > enable trace collection. There certainly are cases where this could be > >> > problematic, e.g. if you get a crash early during thread creation and > >> > you want to figure out how you got there. For this to work, we might > >> > need an API like > >> > SBProcess::TraceNewThreads(...) > >> > or > >> > SBProcess::TraceAllThreads(...) > >> > with the assumption that "all" also includes newly created threads in > >> > the future. > >> > > >> > I'm not saying this needs to be done in the first implementation, but > >> > I think that we should at least design the API in a way that will not > >> > make adding this unnecessarily hard in the future (e.g. the idea of > >> > returning an SBTrace object might be problematic, since you don't know > >> > if/how many threads will be created). > >> > > >> > > >> > > >> > Also, thinking about new APIs, should we have a way to mark an API as > >> > incubating/experimental? Maybe it would be good to mark these new APIs > >> > as experimental for a while, so we have an option of changing them in > >> > the future, if it turns out we have made the wrong decision. I was > >> > thinking of either a naming convention > >> > (SBThread::StartTraceExperimental) or some annotation/comment on the > >> > methods. When we are confident this design is good, we can remove the > >> > promote the api into the "stable" set. > >> > > >> > pl > >> > > >> > > >> > > >> > > >> > On 31 March 2016 at 18:59, Greg Clayton via lldb-dev > >> > wrote: > >> >> > >> >>> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev > >> >>> wrote: > >> >>> > >> >>> Hello all, >
Re: [lldb-dev] Review of API and remote packets
ion that "all" also includes newly created threads > in > >> >> > the future. > >> >> > > >> >> > I'm not saying this needs to be done in the first implementation, > but > >> >> > I think that we should at least design the API in a way that will > not > >> >> > make adding this unnecessarily hard in the future (e.g. the idea of > >> >> > returning an SBTrace object might be problematic, since you don't > >> >> > know > >> >> > if/how many threads will be created). > >> >> > > >> >> > > >> >> > > >> >> > Also, thinking about new APIs, should we have a way to mark an API > as > >> >> > incubating/experimental? Maybe it would be good to mark these new > >> >> > APIs > >> >> > as experimental for a while, so we have an option of changing them > in > >> >> > the future, if it turns out we have made the wrong decision. I was > >> >> > thinking of either a naming convention > >> >> > (SBThread::StartTraceExperimental) or some annotation/comment on > the > >> >> > methods. When we are confident this design is good, we can remove > the > >> >> > promote the api into the "stable" set. > >> >> > > >> >> > pl > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > On 31 March 2016 at 18:59, Greg Clayton via lldb-dev > >> >> > wrote: > >> >> >> > >> >> >>> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev > >> >> >>> wrote: > >> >> >>> > >> >> >>> Hello all, > >> >> >>> I am currently working on enabling Intel (R) > Processor > >> >> >>> Trace collection for lldb. I have done some previous discussions > in > >> >> >>> this > >> >> >>> mailing list on this topic but just to summarize , the path we > >> >> >>> chose was to > >> >> >>> implement raw trace collection in lldb and the trace will be > >> >> >>> decoded outside > >> >> >>> LLDB. I wanted to expose this feature through the SB API's and > for > >> >> >>> trace > >> >> >>> data transfer I wish to develop new communication packets. Now I > >> >> >>> want to get > >> >> >>> the new API's and packet specifications reviewed by the dev list. > >> >> >>> Please > >> >> >>> find the specification below -> > >> >> >>> > >> >> >>> lldb::SBError SBProcess::StartTrace(lldb::tid_t threadId, const > >> >> >>> SBTraceConfig &config) > >> >> >>>Start tracing for thread - threadId with trace configuration > >> >> >>> config. > >> >> >>>SBTraceConfig would contain the following fields- > >> >> >>>-> TraceType - ProcessorTrace, SoftwareTrace , any > trace > >> >> >>> technology etc > >> >> >>>-> size of trace buffer > >> >> >>>-> size of meta data buffer > >> >> >>>Returns error in case starting trace was unsuccessful, which > >> >> >>> could > >> >> >>> occur by reasons such as > >> >> >>>picking non existent thread, target does not support TraceType > >> >> >>> selected etc. > >> >> >> > >> >> >> If you are going to trace on a thread, we should be putting this > API > >> >> >> on > >> >> >> SBThread. Also we have other config type classes in our public API > >> >> >> and we > >> >> >> have suffixed them with Options so SBTraceConfig should actually > be > >> >> >> SBTraceOptions. Also don't bother using "const" on any public APIs > >> >> >> since the > >> >> >> mean nothing and only cause issues. Why? All public classes > usually > >> >> >> contain > >> >> >> a std::unique_ptr or
Re: [lldb-dev] Review of API and remote packets
SBTrace trace = process.StartTrace(trace_options, error); > >> >> >> > >> >> >> It really depends on how all different forms of trace are enabled > >> >> >> for > >> >> >> different kinds of tracing. It takes kernel support to trace only > >> >> >> specific > >> >> >> threads, but someone might be debugging a bare board that only has > >> >> >> the > >> >> >> option tracing all threads on each core. When making an API we > can't > >> >> >> assume > >> >> >> we can limit this to any threads and even to any process. > >> >> >> > >> >> >> Greg > >> >> >> > >> >> >> > On Apr 1, 2016, at 2:00 AM, Pavel Labath > >> >> >> > wrote: > >> >> >> > > >> >> >> > I second Greg's suggestions, and I have some thoughts of my own: > >> >> >> > > >> >> >> > - with the proposed API, it is not possible to get a trace for > >> >> >> > newly > >> >> >> > created threads - the process needs to be stopped first, so you > >> >> >> > can > >> >> >> > enable trace collection. There certainly are cases where this > >> >> >> > could > >> >> >> > be > >> >> >> > problematic, e.g. if you get a crash early during thread > creation > >> >> >> > and > >> >> >> > you want to figure out how you got there. For this to work, we > >> >> >> > might > >> >> >> > need an API like > >> >> >> > SBProcess::TraceNewThreads(...) > >> >> >> > or > >> >> >> > SBProcess::TraceAllThreads(...) > >> >> >> > with the assumption that "all" also includes newly created > threads > >> >> >> > in > >> >> >> > the future. > >> >> >> > > >> >> >> > I'm not saying this needs to be done in the first > implementation, > >> >> >> > but > >> >> >> > I think that we should at least design the API in a way that > will > >> >> >> > not > >> >> >> > make adding this unnecessarily hard in the future (e.g. the idea > >> >> >> > of > >> >> >> > returning an SBTrace object might be problematic, since you > don't > >> >> >> > know > >> >> >> > if/how many threads will be created). > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > Also, thinking about new APIs, should we have a way to mark an > API > >> >> >> > as > >> >> >> > incubating/experimental? Maybe it would be good to mark these > new > >> >> >> > APIs > >> >> >> > as experimental for a while, so we have an option of changing > them > >> >> >> > in > >> >> >> > the future, if it turns out we have made the wrong decision. I > was > >> >> >> > thinking of either a naming convention > >> >> >> > (SBThread::StartTraceExperimental) or some annotation/comment on > >> >> >> > the > >> >> >> > methods. When we are confident this design is good, we can > remove > >> >> >> > the > >> >> >> > promote the api into the "stable" set. > >> >> >> > > >> >> >> > pl > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > On 31 March 2016 at 18:59, Greg Clayton via lldb-dev > >> >> >> > wrote: > >> >> >> >> > >> >> >> >>> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev > >> >> >> >>> wrote: > >> >> >> >>> > >> >> >> >>> Hello all, > >> >> >> >>> I am currently working on enabling Intel (R) > >> >> >> >>> Processor > >&g
[lldb-dev] Inquiry regarding AddOneMoreFrame function in UnWindLLDB
Hello, I am currently working on Bug 27687 (PrintStackTraces), so the reason for the failure is the erroneous unwinding of the frames from the zeroth frame. The error is not detected in AddOneMoreFrame, since it only checks for 2 more frames, if it was checking more frames in AddOneMoreFrame, it would have detected the error. Now my questions are -> -> is that is there any specific reason for only checking 2 frames instead of more ? -> Is is safe to assume that in the absence of prologue and epilogue the assembly unwinder will always fail ? Best Regards, A Ravi Theja ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Fwd: Inquiry regarding AddOneMoreFrame function in UnWindLLDB
Hello, I posted this query a while ago, i still have no answers, I am currently working on Bug 27687 (PrintStackTraces), so the reason for the failure is the erroneous unwinding of the frames from the zeroth frame. The error is not detected in AddOneMoreFrame, since it only checks for 2 more frames, if it was checking more frames in AddOneMoreFrame, it would have detected the error. Now my questions are -> -> is that is there any specific reason for only checking 2 frames instead of more ? -> Why no make the EH CFI based unwinder the default one and make the assembly the fallback ? Best Regards, A Ravi Theja ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inquiry regarding AddOneMoreFrame function in UnWindLLDB
Ok , currently the problem that I am facing is that there are cases in which eh_frame should have been used for frame 0 but it isn't and the assembly unwind just gives wrong information which could only be detected if the debugger tried to extract more frames. Now the usage of AddOneMoreFrame in UnwindLLDB is to try to get more than one frames in the stack. I want to run both the unwinders and select the one that gives more number of frames. On Wed, Jun 1, 2016 at 12:27 AM, Jason Molenda wrote: > > > On May 31, 2016, at 11:31 AM, jing...@apple.com wrote: > > > > > >> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> > >> Hello, > >> I posted this query a while ago, i still have no answers, I am > currently working on Bug 27687 (PrintStackTraces), so the reason for the > failure is the erroneous unwinding of the frames from the zeroth frame. The > error is not detected in AddOneMoreFrame, since it only checks for 2 more > frames, if it was checking more frames in AddOneMoreFrame, it would have > detected the error. Now my questions are -> > >> > >> -> is that is there any specific reason for only checking 2 frames > instead of more ? > > > > The stepping machinery uses the unwinder on each stop to figure out > whether it has stepped in or out, which is fairly performance sensitive, so > we don't want AddOneMoreFrame to do more work than it has to. > > > Most common case for a bad unwind, where the unwinder is stuck in a loop, > is a single stack frame repeating. I've seen loops as much as six frames > repeating (which are not actually a series of recursive calls) but it's > less common. > > > > >> -> Why no make the EH CFI based unwinder the default one and make the > assembly the fallback ? > > > Sources of unwind information fall into two categories. They can describe > the unwind state at every instruction of a function (asynchronous) or they > can describe the unwind state only at function call boundaries > (synchronous). > > Think of "asynchronous" here as the fact that the debugger can interrupt > the program at any point in time. > > Most unwind information is designed for exception handling -- it is > synchronous, it can only throw an exception in the body of the function, or > an exception is passed up through it when it is calling another function. > > For exception handling, there is no need/requirement to describe the > prologue or epilogue instructions, for instance. > > eh_frame (and DWARF's debug_frame from which it derives) splits the > difference and makes things quite unclear. It is guaranteed to be correct > for exception handling -- it is synchronous, and is valid in the middle of > the function and when it is calling other functions -- but it is a general > format that CAN be asynchronous if the emitter includes information about > the prologue or epilogue or mid-function stack changes. But eh_frame is > not guaranteed to be that way, and in fact there's no way for it to > indicate what it describes, beyond the required unwind info for exception > handling. > > On x86, gcc and clang have always described the prologue unwind info in > their eh_frame. gcc has recently started describing the epilogue too > (clang does not). There's code in lldb (e.g. > UnwindAssembly_x86::AugmentUnwindPlanFromCallSite) written by Tong Shen > when interning at Google which will try to detect if the eh_frame describes > the prologue and epilogue. If it does, it will use eh_frame for frame 0. > If it only describes the prologue, it will use the instruction emulation > code to add epilogue instructions and use that at frame 0. > > > There are other sources of unwind information similar to eh_frame that are > only for exception handling. Tamas added ArmUnwindInfo last year which > reads the .ARM.exidx unwind tables. I added compact unwind importing - an > Apple specific format that uses a single 4-byte word to describe the unwind > state for each function, which can't describe anything in the > prologue/epilogue. These formats definitely can't be used to unwind at > frame 0 because we could be stopped anywhere in the prologue/epilogue where > they are not accurate. > > > It's unfortunate that eh_frame doesn't include a way for the producer to > declare how async the unwind info is, it makes the debugger's job a lot > more difficult. > > > J ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inquiry regarding AddOneMoreFrame function in UnWindLLDB
Hello, This is happening in TestPrintStackTraces, where we can end up here: ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2: 0x77df04e0 <+0>: 48 83 ec 38 subq $0x38, %rsp 0x77df04e4 <+4>: 48 89 04 24 movq %rax, (%rsp) 0x77df04e8 <+8>: 48 89 4c 24 08 movq %rcx, 0x8(%rsp) 0x77df04ed <+13>: 48 89 54 24 10 movq %rdx, 0x10(%rsp) 0x77df04f2 <+18>: 48 89 74 24 18 movq %rsi, 0x18(%rsp) 0x77df04f7 <+23>: 48 89 7c 24 20 movq %rdi, 0x20(%rsp) 0x77df04fc <+28>: 4c 89 44 24 28 movq %r8, 0x28(%rsp) 0x77df0501 <+33>: 4c 89 4c 24 30 movq %r9, 0x30(%rsp) 0x77df0506 <+38>: 48 8b 74 24 40 movq 0x40(%rsp), %rsi 0x77df050b <+43>: 48 8b 7c 24 38 movq 0x38(%rsp), %rdi 0x77df0510 <+48>: e8 4b 8f ff ff callq 0x77de9460; ___lldb_unnamed_symbol54$$ld-linux-x86-64.so.2 0x77df0515 <+53>: 49 89 c3 movq %rax, %r11 0x77df0518 <+56>: 4c 8b 4c 24 30 movq 0x30(%rsp), %r9 0x77df051d <+61>: 4c 8b 44 24 28 movq 0x28(%rsp), %r8 0x77df0522 <+66>: 48 8b 7c 24 20 movq 0x20(%rsp), %rdi 0x77df0527 <+71>: 48 8b 74 24 18 movq 0x18(%rsp), %rsi 0x77df052c <+76>: 48 8b 54 24 10 movq 0x10(%rsp), %rdx 0x77df0531 <+81>: 48 8b 4c 24 08 movq 0x8(%rsp), %rcx -> 0x77df0536 <+86>: 48 8b 04 24 movq (%rsp), %rax 0x77df053a <+90>: 48 83 c4 48 addq $0x48, %rsp 0x77df053e <+94>: 41 ff e3 jmpq *%r11 0x77df0541 <+97>: 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 nopw %cs:(%rax,%rax) image show-unwind --address 0x77df0536 UNWIND PLANS for ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2 (start addr 0x77df04e0) Asynchronous (not restricted to call-sites) UnwindPlan is 'assembly insn profiling' Synchronous (restricted to call-sites) UnwindPlan is 'eh_frame CFI' Assembly language inspection UnwindPlan: This UnwindPlan originally sourced from assembly insn profiling This UnwindPlan is sourced from the compiler: no. This UnwindPlan is valid at all instruction locations: yes. Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text + 88576-0x00015a70) row[0]:0: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8] row[1]:4: CFA=rsp+64 => rsp=CFA+0 rip=[CFA-8] row[2]: 94: CFA=rsp -8 => rsp=CFA+0 rip=[CFA-8] eh_frame UnwindPlan: This UnwindPlan originally sourced from eh_frame CFI This UnwindPlan is sourced from the compiler: yes. This UnwindPlan is valid at all instruction locations: no. Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text + 88576-0x00015a61) row[0]:0: CFA=rsp+24 => rip=[CFA-8] row[1]:4: CFA=rsp+80 => rip=[CFA-8] row[2]: 94: CFA=rsp +8 => rip=[CFA-8] On Wed, Jun 1, 2016 at 11:38 PM, Jason Molenda wrote: > It gets so tricky! It's hard for the unwinder to tell the difference > between a real valid stack unwind and random data giving lots of "frames". > > It sounds like the problem that needs fixing is to figure out why the > assembly unwind is wrong for frame 0. What do you get for > > disass -a > > image show-unwind -a > > ? > > > > On Jun 1, 2016, at 12:56 AM, Ravitheja Addepally < > ravithejaw...@gmail.com> wrote: > > > > Ok , currently the problem that I am facing is that there are cases in > which eh_frame should have been used for frame 0 but it isn't and the > assembly unwind just gives wrong information which could only be detected > if the debugger tried to extract more frames. Now the usage of > AddOneMoreFrame in UnwindLLDB is to try to get more than one frames in the > stack. I want to run both the unwinders and select the one that gives more > number of frames. > > > > On Wed, Jun 1, 2016 at 12:27 AM, Jason Molenda > wrote: > > > > > On May 31, 2016, at 11:31 AM, jing...@apple.com wrote: > > > > > > > > >> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > >> > > >> Hello, > > >> I posted this query a while ago, i still have no answers, I am > currently working on Bug 27687 (PrintStackTraces), so the reason for the > failure is the erroneous unwinding of the frames from the zeroth frame. The > error is not detected in AddOneMoreFrame, since it only checks for 2 more > frames, if it was checking more frames in AddOneMoreFrame, it would have > detected the error. Now my questions are -> > > >> > > >> -> is that is there any specific reason for only checking 2 frames > instead of more ? > > > > > >
Re: [lldb-dev] Inquiry regarding AddOneMoreFrame function in UnWindLLDB
dPlan is valid at all instruction locations: yes. > > Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text + > 88576-0x00015a70) > > row[0]:0: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8] > > row[1]:4: CFA=rsp+64 => rsp=CFA+0 rip=[CFA-8] > > row[2]: 94: CFA=rsp -8 => rsp=CFA+0 rip=[CFA-8] > > > > eh_frame UnwindPlan: > > This UnwindPlan originally sourced from eh_frame CFI > > This UnwindPlan is sourced from the compiler: yes. > > This UnwindPlan is valid at all instruction locations: no. > > Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text + > 88576-0x00015a61) > > row[0]:0: CFA=rsp+24 => rip=[CFA-8] > > row[1]:4: CFA=rsp+80 => rip=[CFA-8] > > row[2]: 94: CFA=rsp +8 => rip=[CFA-8] > > > > > > > > On Wed, Jun 1, 2016 at 11:38 PM, Jason Molenda > wrote: > > It gets so tricky! It's hard for the unwinder to tell the difference > between a real valid stack unwind and random data giving lots of "frames". > > > > It sounds like the problem that needs fixing is to figure out why the > assembly unwind is wrong for frame 0. What do you get for > > > > disass -a > > > > image show-unwind -a > > > > ? > > > > > > > On Jun 1, 2016, at 12:56 AM, Ravitheja Addepally < > ravithejaw...@gmail.com> wrote: > > > > > > Ok , currently the problem that I am facing is that there are cases in > which eh_frame should have been used for frame 0 but it isn't and the > assembly unwind just gives wrong information which could only be detected > if the debugger tried to extract more frames. Now the usage of > AddOneMoreFrame in UnwindLLDB is to try to get more than one frames in the > stack. I want to run both the unwinders and select the one that gives more > number of frames. > > > > > > On Wed, Jun 1, 2016 at 12:27 AM, Jason Molenda > wrote: > > > > > > > On May 31, 2016, at 11:31 AM, jing...@apple.com wrote: > > > > > > > > > > > >> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > >> > > > >> Hello, > > > >> I posted this query a while ago, i still have no answers, I am > currently working on Bug 27687 (PrintStackTraces), so the reason for the > failure is the erroneous unwinding of the frames from the zeroth frame. The > error is not detected in AddOneMoreFrame, since it only checks for 2 more > frames, if it was checking more frames in AddOneMoreFrame, it would have > detected the error. Now my questions are -> > > > >> > > > >> -> is that is there any specific reason for only checking 2 frames > instead of more ? > > > > > > > > The stepping machinery uses the unwinder on each stop to figure out > whether it has stepped in or out, which is fairly performance sensitive, so > we don't want AddOneMoreFrame to do more work than it has to. > > > > > > > > > Most common case for a bad unwind, where the unwinder is stuck in a > loop, is a single stack frame repeating. I've seen loops as much as six > frames repeating (which are not actually a series of recursive calls) but > it's less common. > > > > > > > > > > >> -> Why no make the EH CFI based unwinder the default one and make > the assembly the fallback ? > > > > > > > > > Sources of unwind information fall into two categories. They can > describe the unwind state at every instruction of a function (asynchronous) > or they can describe the unwind state only at function call boundaries > (synchronous). > > > > > > Think of "asynchronous" here as the fact that the debugger can > interrupt the program at any point in time. > > > > > > Most unwind information is designed for exception handling -- it is > synchronous, it can only throw an exception in the body of the function, or > an exception is passed up through it when it is calling another function. > > > > > > For exception handling, there is no need/requirement to describe the > prologue or epilogue instructions, for instance. > > > > > > eh_frame (and DWARF's debug_frame from which it derives) splits the > difference and makes things quite unclear. It is guaranteed to be correct > for exception handling -- it is synchronous, and is valid in the middle of > the function and when it is calling other functions -- but it is a general > format that CAN be asynchronous if the emitter includes informati
[lldb-dev] Is lldb-server compatible with GDB ?
Hello, Can we use GDB with lldb-server ? I see the vice-versa wroks i.e LLDB with gdbserver. I did try using lldb-server with GDB but I got errors (incompatible packet length). I was wondering if there is some special tweaking needed for lldb-server to work with GDB ? BR, A Ravi Theja ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] What's the latest version of gdbserver supported by LLDB
Hello, Debugging with gdbserver is supported by LLDB, but does it support all the features that are present in the latest version of gdbserver ? If not till what version of gdbserver does it support ? and are there any future plans to support the latest gdbserver ? Best Regards, A Ravi Theja ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Review of API and remote packets
gt; >> >> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions >> >> >> >> &trace_options, >> >> >> >> lldb::SBError &error); >> >> >> >> >> >> >> >> And you would need to specify which threads in the SBTraceOptions >> >> >> >> object >> >> >> >> itself?: >> >> >> >> >> >> >> >> SBTraceOptions trace_options; >> >> >> >> >> >> >> >> And then do some like: >> >> >> >> >> >> >> >> trace_options.SetTraceAllThreads(); >> >> >> >> >> >> >> >> And maybe tracing all threads is the default. Or one can limit >> this >> >> >> >> to >> >> >> >> one >> >> >> >> thread: >> >> >> >> >> >> >> >> trace_options.SetThreadID (tid); >> >> >> >> >> >> >> >> Then you start tracing using the "trace_options" which has the >> >> >> >> notion >> >> >> >> of >> >> >> >> which threads to trace. >> >> >> >> >> >> >> >> lldb::SBError error; >> >> >> >> lldb::SBTrace trace = process.StartTrace(trace_options, error); >> >> >> >> >> >> >> >> It really depends on how all different forms of trace are enabled >> >> >> >> for >> >> >> >> different kinds of tracing. It takes kernel support to trace only >> >> >> >> specific >> >> >> >> threads, but someone might be debugging a bare board that only >> has >> >> >> >> the >> >> >> >> option tracing all threads on each core. When making an API we >> can't >> >> >> >> assume >> >> >> >> we can limit this to any threads and even to any process. >> >> >> >> >> >> >> >> Greg >> >> >> >> >> >> >> >> > On Apr 1, 2016, at 2:00 AM, Pavel Labath >> >> >> >> > wrote: >> >> >> >> > >> >> >> >> > I second Greg's suggestions, and I have some thoughts of my >> own: >> >> >> >> > >> >> >> >> > - with the proposed API, it is not possible to get a trace for >> >> >> >> > newly >> >> >> >> > created threads - the process needs to be stopped first, so you >> >> >> >> > can >> >> >> >> > enable trace collection. There certainly are cases where this >> >> >> >> > could >> >> >> >> > be >> >> >> >> > problematic, e.g. if you get a crash early during thread >> creation >> >> >> >> > and >> >> >> >> > you want to figure out how you got there. For this to work, we >> >> >> >> > might >> >> >> >> > need an API like >> >> >> >> > SBProcess::TraceNewThreads(...) >> >> >> >> > or >> >> >> >> > SBProcess::TraceAllThreads(...) >> >> >> >> > with the assumption that "all" also includes newly created >> threads >> >> >> >> > in >> >> >> >> > the future. >> >> >> >> > >> >> >> >> > I'm not saying this needs to be done in the first >> implementation, >> >> >> >> > but >> >> >> >> > I think that we should at least design the API in a way that >> will >> >> >> >> > not >> >> >> >> > make adding this unnecessarily hard in the future (e.g. the >> idea >> >> >> >> > of >> >> >> >> > returning an SBTrace object might be problematic, since you >> don't >> >> >> >> > know >> >> >> >> > if/how many threads will be created). >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > Also,
[lldb-dev] Inquiry about Error codes sent by lldb-server
Hello, The lldb-server sends hard coded values like 0x78 etc in case of error, so does the ProcessGDBRemote use these numbers anyway except for just detecting error ? ( in my understanding it doesn't seem to use the value of the number please correct me if i am wrong ). Is there some special meaning to these numbers ? Regards, A Ravi Theja ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Code Coverage with GCOV
Hello, I was trying to get Code Coverage for LLDB with GCOV on Linux by adding the corresponding flags in the CMake files, but I am facing problem with lldb-server, which does not give seem to generate the gcda files. The host side does generate the gcov files although. The lldb-server does generate the gcov files if it is started in Standalone mode but it does not generate the gcov files if started by LLDB. Has anyone tried this already ? How can I get Code Coverage for lldb / lldb-server on Linux ? Best Regards, A Ravi Theja ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Code Coverage with GCOV
Hello,
I added the following lines to the lldb-server and lldb
CMakeLists.txt
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fprofile-arcs -ftest-coverage")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fprofile-arcs
-ftest-coverage")
I am able to get the lldb-server gcov files when I start its instance and
then connect to it. But since lldb starts the lldb-server in different way,
the files are not written, because I do see that the gcov instrumentation
functions are present in the lldb-server.
Best Regards,
A Ravi Theja
On Tue, Aug 16, 2016 at 7:27 PM, Vedant Kumar wrote:
> Hi Ravitheja,
>
> Could you show us the diff to your cmake configuration? You may want to
> take a
> look at how the LLVM_BUILD_INSTRUMENTED cmake option is implemented to
> double-check that you've got something reasonable (see:
> llvm/CMakeLists.txt and
> cmake/modules/HandleLLVMOptions.cmake).
>
> Also, you may want to double-check that the gcda files are being written
> to the
> right directory.
>
> best,
> vedant
>
>
> > On Aug 16, 2016, at 7:58 AM, Ravitheja Addepally via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hello,
> >I was trying to get Code Coverage for LLDB with GCOV on Linux by
> adding the corresponding flags in the CMake files, but I am facing problem
> with lldb-server, which does not give seem to generate the gcda files. The
> host side does generate the gcov files although. The lldb-server does
> generate the gcov files if it is started in Standalone mode but it does not
> generate the gcov files if started by LLDB. Has anyone tried this already ?
> How can I get Code Coverage for lldb / lldb-server on Linux ?
> >
> >
> > Best Regards,
> > A Ravi Theja
> > ___
> > 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] Support for Error Strings in remote protocol
Hello all, Currently the remote protocol in LLDB does not allow sending Error Strings in response to remote packets, it only allows for "ENN" format where N is a hex integer. In our current ongoing work, we would like to have support for Sending Error Strings from lldb-server. I would like to invite any opinions or suggestions in this matter ? A very simple proposal would be to just attach an error string maybe as a Name:Value Pair ? like so -> EXX;"Error String" or EXX;M"Error String" I guess removing EXX would make it incompatible with gdb-server. Also adding new packets to query errors might not be desired ? Regards, A Ravi Theja ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Support for Error Strings in remote protocol
That's the other option of decoding error codes at the client, there is the obvious downside of the common error table to become very big ? considering the number of OS's and Targets ? Also the lldb-server already knows the target, would be useful if it could generate an error message as well ? The use case is as follows -> we are currently implementing support for Intel Processor Trace for lldb, the way it is structured is that the lldb-server gathers trace data and we have a tool running on top of SB API's which does all the trace specific handling. So basically the client is sort of transparent. We choose such a design so as to do the least amount of changes in lldb. On Thu, Jun 22, 2017 at 1:54 AM, Jim Ingham wrote: > Right. I wasn't actually arguing one method over the other. Mostly > pointing out that you can't take error numbers seriously in general, and > that consequently if we go the error number route, you have to know you are > talking to lldb-server and particularly one that has rational error > numbers. Maybe have a qUsesLLDBSERVERErrorNumbers packet as part of the > handshake. > > Jim > > > > On Jun 21, 2017, at 4:35 PM, Stephane Sezer wrote: > > > > True, but the error strings would be only available with lldb-server as > well. Keeping a common table of error numbers seems like a good solution. > > > > On Wed, Jun 21, 2017 at 4:33 PM Jim Ingham wrote: > > Because the gdb remote protocol docs explicitly state: > > > > The error response returned for some packets includes a two character > error number. That number is not well defined. > > > > we don't put much stock in the actual error numbers. > > > > If you can determine that you are talking to lldb-server, then we could > actually make these meaningful by keeping a common table. But that would > only work for lldbserver. > > > > Jim > > > > > > > On Jun 21, 2017, at 4:18 PM, Stephane Sezer via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > What's the specific use case that you're trying to support with error > messages in the protocol? My initial thought on this is that it's not > really the debug server's job to generate human-readable error messages and > that the debugger is better suited to do the job. > > > > > > Can this problem be solved by extending the current integer list used > for errors? > > > > > > On Wed, Jun 21, 2017 at 8:31 AM Ravitheja Addepally via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > Hello all, > > >Currently the remote protocol in LLDB does not allow sending > Error Strings in response to remote packets, it only allows for "ENN" > format where N is a hex integer. In our current ongoing work, we would like > to have support for Sending Error Strings from lldb-server. I would like to > invite any opinions or suggestions in this matter ? > > > > > > A very simple proposal would be to just attach an error string maybe > as a Name:Value Pair ? like so -> > > > > > > EXX;"Error String" > > > or > > > EXX;M"Error String" > > > > > > I guess removing EXX would make it incompatible with gdb-server. Also > adding new packets to query errors might not be desired ? > > > > > > > > > Regards, > > > A Ravi Theja > > > > > > > > > ___ > > > lldb-dev mailing list > > > lldb-dev@lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > -- > > > -- > > > Stephane Sezer > > > ___ > > > lldb-dev mailing list > > > lldb-dev@lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > -- > > -- > > Stephane Sezer > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Support for Error Strings in remote protocol
Hello, From my understanding (please correct me if i am wrong) , currently the error codes returned by lldb-server are completely arbitrary. Now the SBError class in the public API interface of lldb does contain a string. I think in erroneous cases, lldb seems to set the String in the lldb Status class more often than the error code. I seriously doubt if there is a coherent structure in the error classes. This whole error structure is borrowed from GDB, which is vague about error codes. Now there are two questions we need to answer -> 1) Do we want to have ability to send error strings in the error packets ? 2) If Yes then how ? On Fri, Jun 23, 2017 at 1:01 AM, Chris Quenelle wrote: > I’m just a new lurker here, so maybe this is obvious… > > Is the string part of the programmatic interface? Or just a comment? > Does the same numeric code always have the same string? > If the same numeric code can have different strings, then the string > represents a specialization of the error code? If clients depend on > the data that’s in the string, then they may not work correctly in > modes of operation where the string is not available from the server. > > If it’s intended to be part of the API then maybe a structured name/value > approach might be better? > > Or maybe it’s just supposed to be a form self-documentation so that > inspection > of the raw error codes is easier to diagnose? In that case maybe the > string > is always 1-to-1 with the error code? > > > On Jun 21, 2017, at 8:31 AM, Ravitheja Addepally via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hello all, > >Currently the remote protocol in LLDB does not allow sending > Error Strings in response to remote packets, it only allows for "ENN" > format where N is a hex integer. In our current ongoing work, we would like > to have support for Sending Error Strings from lldb-server. I would like to > invite any opinions or suggestions in this matter ? > > > > A very simple proposal would be to just attach an error string maybe as > a Name:Value Pair ? like so -> > > > > EXX;"Error String" > > or > > EXX;M"Error String" > > > > I guess removing EXX would make it incompatible with gdb-server. Also > adding new packets to query errors might not be desired ? > > > > > > Regards, > > A Ravi Theja > > > > > > ___ > > 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] Support for Error Strings in remote protocol
Hello, I would just like to add one more point to this discussion about error strings being human readable or not, I guess the whole purpose of having error strings, is to present them to human users right ? i mean a use case of sending strings, that are not human readable won't be required. So I can work on this point and upload a patch for review. I will add all people in this discussion in the review as well. On Tue, Jun 27, 2017 at 11:27 AM, Pavel Labath wrote: > On 26 June 2017 at 18:19, Chris Quenelle via lldb-dev > wrote: > > > > My main concern was that *if* strings are added, there's some > > clear documentation about the relationship between the string > > and the number to explain what's going on. Based on other > > emails in this thread it seems like the numbers are so unreliable that > > it might not be worth the trouble. > > > > What about this approach instead? > > > > Define a new mode of operation called something like "extended error > > response" > > and invent some way for the client to 1) detect if it's supported in the > > server and then > > 2) to enable the mode in the server. > > > > Then define a better error interface. You'd want it to resemble the > > existing one > > to make it easy for clients to enable it without having to write a bunch > of > > new code. > > > > If many things can go wrong in the server, then you might want to have > some > > arbitrary > > lines of text that can be retrieved by the client, and which are defined > as > > "human readable only" In other words, warn clients not to parse this > > extended > > "Error log" type of string stuff. The client could dump that to the > human > > on request. > > > > That would give a lot of flexibility for the server to spit ad-hoc > strings > > into the error buffer. > > I think that pretty much sums up what we were talking about. The > client would enable the packet via e.g. QEnableStringErrors packet > (the servers already know to reply "unsupported packet" to any packets > they don't understand). Then the server can send > "Exx;some_error_string" (instead of the usual "Exx"). Later, when the > client converts that into a Status object he will use that string to > initialize the error string. If the error string is not present he > will simply initialize the error string to "Error 47". All of this > would be completely invisible to all but the lowest layers of the gdb > protocol code. > > > > > You could also define a strict set of numeric codes for things that are > > supposed to > > common and stable between server versions and implementations. But that > > would > > still be within the "extended error response" mode. > > > > Right I don't think we have a use case for these extended error codes, > so I'd postpone that discussion until a need arises. (Mainly because > maintaining a set of backward/forward compatible set of numeric error > codes is a pain). > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inquiry for performance monitors
Hello, I want to implement support for reading Performance measurement information using the perf_event_open system calls. The motive is to add support for Intel PT hardware feature, which is available through the perf_event interface. I was thinking of implementing a new Wrapper like PtraceWrapper in NativeProcessLinux files. My query is that, is this a correct place to start or not ? in case not, could someone suggest me another place to begin with ? BR, A Ravi Theja ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
