Re: [lldb-dev] Question about -break-insert in lldb-mi

[Jim Ingham via lldb-dev]

gdb used to try to find a symbol matching the breakpoint specification and if 
it didn't find one immediately, it would raise an error.  If you didn't want 
this behavior (in a world with many shared libraries you seldom did) then you 
could set a "future-break" which is what the -f flag turns on.  This was better 
though a bit bogus, because it would set the breakpoint the FIRST time it took, 
then never look again.

But this was quite a while ago, and I think gdb's gotten better about 
organizing breakpoints.  But I haven't used a modern gdb for a while, so I'm 
not sure how it works now-a-days.

Anyway, lldb's breakpoints don't work that way.  They stay active till you 
delete them, and keep searching for new matches every time a shared library is 
loaded.  You could make them emulate the gdb behavior by judiciously deleting & 
duplicating breakpoints from the original specification, but there's no way to 
get the native lldb breakpoints to do so (nor should there be IMHO...)

So if you are using the lldb-mi, there's no reason to bother with the -f flag.  
But also lldb-mi should probably just ignore this flag.

Jim
 

> On Jul 8, 2016, at 5:58 PM, Pierson Lee (PIE) via lldb-dev 
>  wrote:
> 
> Hi,
>  
> I’m trying to use -break-insert and the -f flag for it. 
>  
> I noticed in MICmdCmdBreak.cpp , in CmICmdCmdBreakInsert::ParseArgs() that 
> the -f has a required parameter.
>  
> m_setCmdArgs.Add(new 
> CMICmdArgValOptionShort(m_constStrArgNamedPendinfBrkPt, false, true,
>
> CMICmdArgValListBase::eArgValType_StringQuotedNumberPath, 1));
>  
>  
> Based on the GDB MI documentation (at 
> https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Breakpoint-Commands.html#GDB_002fMI-Breakpoint-Commands)
>  for -break-insert shows:
>  
> ‘-f’
> If location cannot be parsed (for example if it refers to unknown files or 
> functions), create a pending breakpoint. Without this flag, gdb will report 
> an error, and won't create a breakpoint, if location cannot be parsed. 
>  
> Is there a reason why it requires a parameter and what should this parameter 
> be ?
>  
> Thanks
> Pierson
> ___
> 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] Question about -break-insert in lldb-mi

[Pierson Lee (PIE) via lldb-dev]

Hi,

I'm trying to use -break-insert and the -f flag for it.

I noticed in MICmdCmdBreak.cpp , in CmICmdCmdBreakInsert::ParseArgs() that the 
-f has a required parameter.

m_setCmdArgs.Add(new 
CMICmdArgValOptionShort(m_constStrArgNamedPendinfBrkPt, false, true,
   
CMICmdArgValListBase::eArgValType_StringQuotedNumberPath, 1));


Based on the GDB MI documentation (at 
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Breakpoint-Commands.html#GDB_002fMI-Breakpoint-Commands)
 for -break-insert shows:

'-f'
If location cannot be parsed (for example if it refers to unknown files or 
functions), create a pending breakpoint. Without this flag, gdb will report an 
error, and won't create a breakpoint, if location cannot be parsed.

Is there a reason why it requires a parameter and what should this parameter be 
?

Thanks
Pierson
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

[Renato Golin via lldb-dev]

On 8 July 2016 at 20:12, Chris Matthews  wrote:
> If LNT is the only holdout I suggest we update the LNT model to natively
> handle git.

I could say the reverse... If improving LNT is a reason to move to
Git, than we should do it. :)


> This sort of change to the
> guts of how LNT works is weeks of work, but I think it matches LNT’s goal of
> tracking performance changes as software evolves.

I think this is a worthy goal, GitHub or not. The Git mirror is
already official, and we could very well use that today.

Also, the GitHub migration, if it happens, will be months away anyway,
and we'll have to complete all pending tasks before we move, so this
could be one of them.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

[Renato Golin via lldb-dev]

On 8 July 2016 at 21:07, Mehdi Amini  wrote:
> The problem is not that is it is not possible to work with a tuple (branch, 
> number), the problem is that a tuple (or a string) is not a number and breaks 
> existing infrastructure. It does not mean it cannot be made to work, but it 
> won’t out-of-the-box.
> (Imagine that the LNT  database needs an integer id for instance, and this id 
> is usually the SVN rev, unique across branches).

Ah, got it! Ok, sorry, I was trying to understand why it wouldn't
work, not why it wouldn't be out-of-the-box.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

[Mehdi Amini via lldb-dev]

> On Jul 8, 2016, at 1:05 PM, Renato Golin  wrote:
> 
> On 8 July 2016 at 21:04, Mehdi Amini  wrote:
>>> What about git describe?
>> 
>> Not a number.
> 
> It contains a number... "tag-number-hash"
> 
> Removing the tag and hash seems trivial.

And you end up with a number that is not unique across branch.

The problem is not that is it is not possible to work with a tuple (branch, 
number), the problem is that a tuple (or a string) is not a number and breaks 
existing infrastructure. It does not mean it cannot be made to work, but it 
won’t out-of-the-box.
(Imagine that the LNT  database needs an integer id for instance, and this id 
is usually the SVN rev, unique across branches).

— 
Mehdi

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

[Renato Golin via lldb-dev]

On 8 July 2016 at 21:04, Mehdi Amini  wrote:
>> What about git describe?
>
> Not a number.

It contains a number... "tag-number-hash"

Removing the tag and hash seems trivial.

--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

[Mehdi Amini via lldb-dev]

> On Jul 8, 2016, at 1:03 PM, Renato Golin  wrote:
> 
> On 8 July 2016 at 17:45, Mehdi Amini  wrote:
>> You missed the point that in a single instance of LNT a revision number has 
>> to be unique.
>> The rev-list thing won't provide this across branches.
>> A rev-list count number won't identify a revision, you need the tuple 
>> (branch, count), which is less easy or less compatible with existing systems.
> 
> What about git describe?

Not a number.

— 
Mehdi

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

[Renato Golin via lldb-dev]

On 8 July 2016 at 17:45, Mehdi Amini  wrote:
> You missed the point that in a single instance of LNT a revision number has 
> to be unique.
> The rev-list thing won't provide this across branches.
> A rev-list count number won't identify a revision, you need the tuple 
> (branch, count), which is less easy or less compatible with existing systems.

What about git describe?

--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

[Chris Matthews via lldb-dev]

With svn the the IDs are unique in, so r123 implies a branch.  svn log 
—revision=123:234 give the right change list when svn is directed at that 
branch. So right now, I can get the change list in one command easily without a 
script.

llvmlab bisect already encodes branch information in the build name.

If LNT is the only holdout I suggest we update the LNT model to natively handle 
git.  The order model has other problems besides this, and I think it would 
make LNT more useful to capture changes in a richer way. Something along the 
lines of registering repos with LNT, and having orders generated based on 
unique combinations of hashes. That would also allow us to track changes in the 
CI drivers, LNT and the test-suite as first class entities in the change list. 
That would also allow us to show change messages in the LNT interface. 
Basically internalizing the sequential ID as an order ID, but then usefully 
representing that in the interface. This sort of change to the guts of how LNT 
works is weeks of work, but I think it matches LNT’s goal of tracking 
performance changes as software evolves.


On July 8, 2016 at 9:45:07 AM, Mehdi Amini (mehdi.am...@apple.com) wrote:



Sent from my iPhone  

> On Jul 8, 2016, at 9:18 AM, Renato Golin  wrote:  
>  
>> On 8 July 2016 at 03:14, Robinson, Paul  wrote:  
>> I could see wanting to compare data from master and a release branch. If  
>> that means sequential IDs need to work across branches, then we're back to  
>> needing a fancier solution than 'rev-list –count'.  
>  
> How would you do this in SVN anyway?  
>  
> Branch commits are inter-twined with trunk commits, and comparing them  
> numerically doesn't yield the results you expect.  

If I give the revision that corresponds to some 3.8 branch commit and compare 
to another in master, I think I get exactly the result I expect.  
I may not understand your point here...  


>  
> At least in Git, the history is tied up via "parent" and not via  
> sequential IDs, so you can actually walk the path.  
>  
> Sequential numbers are only meaningful for linear histories. Branches,  
> whether on Git or Svn break that promise.  

SVN has monotonic increasing ids that are unique across branches.  


>  
> If we make LNT work with Git "as Git", then all problems are solved.  
> And meanwhile, we get to work with LNT "as SVN" via rev-list --count.  

You missed the point that in a single instance of LNT a revision number has to 
be unique.  
The rev-list thing won't provide this across branches.  
A rev-list count number won't identify a revision, you need the tuple (branch, 
count), which is less easy or less compatible with existing systems.  

--  
Mehdi  


>  
> cheers,  
> --renato  
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB-MI from Eclipse hangs

[Greg Clayton via lldb-dev]

From the sample I see that LLDB is in synchronous mode. It was caused by:

> 313,449 12-gdb-set target-async off
> 313,453 12^done

This sets LLDB into synchronous mode where if you say "-exec-continue", that 
command won't return until the target stops. This causes lldb-mi to not process 
any commands until your process stops or exits. Not sure that this is what we 
want. We can see the handler for "target-async" below:

//++ 

// Details: Carry out work to complete the GDB set option 'target-async' to 
prepare
//  and send back information asked for.
// Type:Method.
// Args:vrWords - (R) List of additional parameters used by this option.
// Return:  MIstatus::success - Function succeeded.
//  MIstatus::failure - Function failed.
// Throws:  None.
//--
bool
CMICmdCmdGdbSet::OptionFnTargetAsync(const CMIUtilString::VecString_t &vrWords)
{
bool bAsyncMode = false;
bool bOk = true;

if (vrWords.size() > 1)
// Too many arguments.
bOk = false;
else if (vrWords.size() == 0)
// If no arguments, default is "on".
bAsyncMode = true;
else if (CMIUtilString::Compare(vrWords[0], "on"))
bAsyncMode = true;
else if (CMIUtilString::Compare(vrWords[0], "off"))
bAsyncMode = false;
else
// Unrecognized argument.
bOk = false;

if (!bOk)
{
// Report error.
m_bGbbOptionFnHasError = true;
m_strGdbOptionFnError = MIRSRC(IDS_CMD_ERR_GDBSET_OPT_TARGETASYNC);
return MIstatus::failure;
}

// Turn async mode on/off.
CMICmnLLDBDebugSessionInfo 
&rSessionInfo(CMICmnLLDBDebugSessionInfo::Instance());
rSessionInfo.GetDebugger().SetAsync(bAsyncMode);

return MIstatus::success;
}

So we see that it sets the debugger into synchronous mode. I don't know MI well 
enough to know if this is desired, but seeing that eclipse quickly follows up 
the -exec-continue with a -list-thread-groups, I am guessing this isn't what we 
want. I would be interested to see the MI log from a GDB that actually works to 
see what the packet responses are expected to look like.

Greg

> On Jul 8, 2016, at 12:06 AM, dipt...@gmail.com wrote:
> 
> Thanks Greg. Attached is the file after sampling lldb-mi. Please let me know 
> if you can find some clue from it.
> 
> -- 
> Have a nice day!
> Regards,
> Dipti
> 
> 
> On Fri, Jul 8, 2016 at 5:49 AM, Greg Clayton  wrote:
> It looks like we continue and then ask fore thread groups? I am not sure on 
> the rules of MI. Can you ask another question before receiving a response? If 
> we say command 18 is "-exec-continue --thread-group i1", can you send command 
> 19 without receiving a response?
> 
> 314,372 18-exec-continue --thread-group i1
> 319,380 19-list-thread-groups
> 
> I would sample the lldb-mi when it is deadlocked:
> 
> % sample lldb-mi
> 
> Then attach the sample output to your response.
> 
> > On Jul 7, 2016, at 8:53 AM, dipt...@gmail.com wrote:
> >
> > 
> > 313,309 2-environment-cd "/Users/admin/Documents/workspace/Hello World C++ 
> > Project"
> > 313,314 2^done,path="/Users/admin/Documents/workspace/Hello World C++ 
> > Project"
> > 313,315 (gdb)
> > 313,321 3-gdb-set breakpoint pending on
> > 313,322 3^done
> > 313,323 (gdb)
> > 313,327 4-gdb-set detach-on-fork on
> > 313,327 4^done
> > 313,328 (gdb)
> > 313,330 5-enable-pretty-printing
> > 313,388 5^done,supported="0"
> > 313,394 (gdb)
> > 313,404 6-gdb-set python print-stack none
> > 313,404 6^done
> > 313,405 (gdb)
> > 313,407 7-gdb-set print object on
> > 313,408 7^error,msg="The request ''print' error. The option 'object' not 
> > found' failed."
> > 313,409 (gdb)
> > 313,411 8-gdb-set print sevenbit-strings on
> > 313,413 8^error,msg="The request ''print' error. The option 
> > 'sevenbit-strings' not found' failed."
> > 313,434 (gdb)
> > 313,436 9-gdb-set host-charset UTF-8
> > 313,436 9^done
> > 313,437 (gdb)
> > 313,439 10-gdb-set target-charset UTF-8
> > 313,440 10^done
> > 313,442 (gdb)
> > 313,446 11-gdb-set target-wide-charset UTF-32
> > 313,447 11^done
> > 313,447 (gdb)
> > 313,449 12-gdb-set target-async off
> > 313,453 12^done
> > 313,453 (gdb)
> > 313,454 13-gdb-set auto-solib-add on
> > 313,455 13^done
> > 313,455 (gdb)
> > 313,464 14-file-exec-and-symbols --thread-group i1 
> > "/Users/admin/Documents/workspace/Hello World C++\
> >  Project/Debug/Hello World C++ Project"
> > 313,625 14^done
> > 313,626 =library-loaded,id="/Users/admin/Documents/workspace/Hello World 
> > C++ Project/Debug/Hello Wor\
> > ld C++ Project",target-name="/Users/admin/Documents/workspace/Hello World 
> > C++ Project/Debug/Hello Wo\
> > rld C++ Project",host-name="/Users/admin/Documents/workspace/Hello World 
> > C++ Project/Debug/Hello Wor\
> > ld C++ Project",symbols-load

Re: [lldb-dev] [llvm-foundation] [llvm-dev] Sequential ID Git hook

[Chris Matthews via lldb-dev]

Sequential IDs are important for LNT and llvmlab bisection tool.

LNT uses the “order” to capture the measured software changes.  LNT does make 
the assumption that orders are unique, so if a ID was the same on two branches, 
LNT would assume that is the same change.  If you never want to compare data 
between branches, storing each branch in a different database solves that 
problem, but sometimes you do want to directly compare runs in two branches.

With both llvmlab and LNT, once you get to a range of IDs, it is needs to be 
easy to find out what commits or commit range those IDs map to.  When given 
regression between 123 and 225, I need the list of commits, and I don’t want to 
log grep for those numbers. Ideally it should also easy for those tools to link 
to a revision on a webUI like viewvc. 


On July 5, 2016 at 4:04:05 PM, Renato Golin via llvm-foundation 
(llvm-foundat...@lists.llvm.org) wrote:


On 5 Jul 2016 10:45 p.m., "Mehdi Amini"  wrote:
>
>
> > On Jul 5, 2016, at 3:44 AM, Renato Golin via llvm-dev 
> >  wrote:
> >
> > Quick re-cap.
> >
> > After a few rounds, not only the "external server" proposal got
> > obliterated as totally unnecessary, but the idea that we may even need
> > a hook at all is now challenged.
>
> This is not clear to me.
> How is the umbrella repository updated?

Sorry, I meant no hooks for updating sequential ids. We still need a hook to 
update the umbrella project.

Cheers,
Renato

___
llvm-foundation mailing list
llvm-foundat...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-foundation
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB-MI from Eclipse hangs

[Ted Woodward via lldb-dev]

A few thoughts:

1)  I think lldb-mi now takes lldb commands, so you could do the log in 
your manual copy/paste. The command you want is:

log enable gdb-remote packets

Do it after the stop, before the –break-insert. You’ll get a bunch of data 
after the –break-insert, then do the –exec-continue and –list-thread-groups, 
and send the data that comes out after those.

 

2)  I see from the log that you’re doing a –target-select remote. Are you 
running debugserver manually? What happens if you don’t run debugserver, and 
have Eclipse do –exec-run instead of –target-select remote?

The original Codeplay implementation of lldb-mi talked to the Hexagon 
Simulator, but didn’t have a way to launch it, so they only used –target-select 
remote, and not –exec-run. Debugserver can be launched automatically, so 
–exec-run should work.

 

3)  This is an answer to Greg’s question about –exec-continue and 
–list-thread-groups. I was going to ask the same thing, but I looked over some 
old logs I had. Eclipse called –list-thread-groups while the target was 
running, and it worked fine. This was with a 2 year old lldb-mi, but I’d expect 
a modern lldb-mi to work as well. The spec at 
https://sourceware.org/gdb/onlinedocs/gdb/Thread-groups.html talks about what 
this command does. It gives a list of process groups that the debugger is 
debugging, so it doesn’t matter if a certain process is running or not.

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: dipt...@gmail.com [mailto:dipt...@gmail.com] 
Sent: Friday, July 08, 2016 6:23 AM
To: Ted Woodward 
Cc: Greg Clayton ; LLDB 
Subject: Re: [lldb-dev] LLDB-MI from Eclipse hangs

 

Thanks Ted for your reply.

I tried the same command that eclipse uses manually from command prompt. It 
hangs after same last command "-exec-continue --thread-group i1". Attached is 
the lldb-mi sample at that time.

 

While debugging from Eclipse I am going to Run--> Debug Configurations--> C/C++ 
Remote Applications-->  and then click on Debug button. And 
then all the commands are executed by Eclipse automatically. I do not see two 
different steps as attach and continue. So I am not sure how to pass command 
"log enable gdb-remote packets". May be I am missing something. Can you please 
help me here, so that I can get the required log as suggested by you? Thanks.

 

 

-- 

Have a nice day!
Regards,
Dipti

On Fri, Jul 8, 2016 at 4:01 AM, Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote:

I don’t see anything in the log that looks like a problem. I’ve got 2 thoughts:

 

1)  Have you tried manual debugging with the same sequence that eclipse 
uses? You can copy/paste lines from the log, just remove some extraneous 
logging info, so

313,464 14-file-exec-and-symbols --thread-group i1 
"/Users/admin/Documents/workspace/Hello World C++\

 Project/Debug/Hello World C++ Project"

Becomes

-file-exec-and-symbols --thread-group i1 
"/Users/admin/Documents/workspace/Hello World C++ Project/Debug/Hello World C++ 
Project"

Copy/paste the exact sequence.

 

2)  A packet log after the –list-thread-groups that hangs would be useful. 
After you attach in eclipse, but before you continue, go to the GDB console tab 
and type:

log enable gdb-remote packets

You should get a line in the log that says

-interpreter-exec console “log enable gdb-remote packets”

and then get a giant spew of data after the continue. Please send that data.

 

I worked on getting lldb-mi working with Eclipse for Hexagon; there were times 
when I’d have to copy/paste what Eclipse sent over to replicate problems, and 
bisect those commands to find the combination that caused my bad behavior. You 
may need to do that here.

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org 
 ] On Behalf Of via lldb-dev
Sent: Thursday, July 07, 2016 10:53 AM
To: Greg Clayton mailto:gclay...@apple.com> >
Cc: lldb-dev@lists.llvm.org  
Subject: Re: [lldb-dev] LLDB-MI from Eclipse hangs

 

Thanks Greg for your reply.

 

Attached below is the GDB trace, please let me know if it helps in any ways.

 

It would be helpful if you can tell me on how to capture (I am really new to 
lldb, sorry for bothering you):

- sample lldb-mi to see what it is doing. 

- complete packet log of the traffic between Eclipse and lldb-mi 

 

I am trying with simple "Hello world" c++ program, so libraries should to be a 
problem. Also, same remote debugging is working fine if I manually do it using 
lldb-mi from command prompt. The hang is happening only when I try to do it via 
eclipse. 

 

I am trying via eclipse, because I am looking for some IDE based remote

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

[Mehdi Amini via lldb-dev]

Sent from my iPhone

> On Jul 8, 2016, at 9:18 AM, Renato Golin  wrote:
> 
>> On 8 July 2016 at 03:14, Robinson, Paul  wrote:
>> I could see wanting to compare data from master and a release branch.  If
>> that means sequential IDs need to work across branches, then we're back to
>> needing a fancier solution than 'rev-list –count'.
> 
> How would you do this in SVN anyway?
> 
> Branch commits are inter-twined with trunk commits, and comparing them
> numerically doesn't yield the results you expect.

If I give the revision that corresponds to some 3.8 branch commit and compare 
to another in master, I think I get exactly the result I expect. 
I may not understand your point here...


> 
> At least in Git, the history is tied up via "parent" and not via
> sequential IDs, so you can actually walk the path.
> 
> Sequential numbers are only meaningful for linear histories. Branches,
> whether on Git or Svn break that promise.

SVN has monotonic increasing ids that are unique across branches.


> 
> If we make LNT work with Git "as Git", then all problems are solved.
> And meanwhile, we get to work with LNT "as SVN" via rev-list --count.

You missed the point that in a single instance of LNT a revision number has to 
be unique. 
The rev-list thing won't provide this across branches.
A rev-list count number won't identify a revision, you need the tuple (branch, 
count), which is less easy or less compatible with existing systems.

-- 
Mehdi


> 
> cheers,
> --renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

[Renato Golin via lldb-dev]

On 8 July 2016 at 03:14, Robinson, Paul  wrote:
> I could see wanting to compare data from master and a release branch.  If
> that means sequential IDs need to work across branches, then we're back to
> needing a fancier solution than 'rev-list –count'.

How would you do this in SVN anyway?

Branch commits are inter-twined with trunk commits, and comparing them
numerically doesn't yield the results you expect.

At least in Git, the history is tied up via "parent" and not via
sequential IDs, so you can actually walk the path.

Sequential numbers are only meaningful for linear histories. Branches,
whether on Git or Svn break that promise.

If we make LNT work with Git "as Git", then all problems are solved.
And meanwhile, we get to work with LNT "as SVN" via rev-list --count.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-foundation] [llvm-dev] Sequential ID Git hook

[Renato Golin via lldb-dev]

On 8 July 2016 at 01:56, Chris Matthews  wrote:
> With both llvmlab and LNT, once you get to a range of IDs, it is needs to be
> easy to find out what commits or commit range those IDs map to.  When given
> regression between 123 and 225, I need the list of commits, and I don’t want
> to log grep for those numbers. Ideally it should also easy for those tools
> to link to a revision on a webUI like viewvc.

That's as easy as: git rev-list --count hash, relying on the fact that
our history is linear, you just have to do basic arithmetic (on the
umbrella project) to get the final sequence.

All of it can be done on the client, not the server.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB-MI from Eclipse hangs

[via lldb-dev]

Thanks Greg. But is it possible that for eclipse support some new wrapper
command is added ? [
https://www.codeplay.com/portal/lldb-mi-driver---part-4-how-to-add-a-command]
Not sure, just a thought. I am googling to see more details but not much
luck yet.

Attached is lldb-mi sample. Please let me know if you have any suggestions.
-- 
Have a nice day!
Regards,
Dipti


On Fri, Jul 8, 2016 at 5:54 AM, Greg Clayton  wrote:

> Actually you should have seen a ^running as a response from -exec-continue:
>
> -exec-continue
> ^running
> (gdb)
>
> But we don't see that here.
>
> Also, -exec-continue doesn't believe it takes any arguments in the
> lldb-mi. Check the tools/lldb-mi/MICmdCmdExec.cpp source file in the LLDB
> sources. Note that is says "Args:None.". Not sure what lldb-mi does if
> arguments are passed to a command that doesn't believe it takes any
> arguments...
>
> //++
> 
> // Details: CMICmdCmdExecContinue constructor.
> // Type:Method.
> // Args:None.
> // Return:  None.
> // Throws:  None.
> //--
> CMICmdCmdExecContinue::CMICmdCmdExecContinue()
> {
> // Command factory matches this name with that received from the stdin
> stream
> m_strMiCmd = "exec-continue";
>
> // Required by the CMICmdFactory when registering *this command
> m_pSelfCreatorFn = &CMICmdCmdExecContinue::CreateSelf;
> }
>
> //++
> 
> // Details: CMICmdCmdExecContinue destructor.
> // Type:Overrideable.
> // Args:None.
> // Return:  None.
> // Throws:  None.
> //--
> CMICmdCmdExecContinue::~CMICmdCmdExecContinue()
> {
> }
>
> //++
> 
> // Details: The invoker requires this function. The command does work in
> this function.
> //  The command is likely to communicate with the LLDB SBDebugger
> in here.
> // Type:Overridden.
> // Args:None.
> // Return:  MIstatus::success - Functional succeeded.
> //  MIstatus::failure - Functional failed.
> // Throws:  None.
> //--
> bool
> CMICmdCmdExecContinue::Execute()
> {
> const char *pCmd = "continue";
> CMICmnLLDBDebugSessionInfo
> &rSessionInfo(CMICmnLLDBDebugSessionInfo::Instance());
> const lldb::ReturnStatus rtn =
> rSessionInfo.GetDebugger().GetCommandInterpreter().HandleCommand(pCmd,
> m_lldbResult);
> MIunused(rtn);
>
> if (m_lldbResult.GetErrorSize() == 0)
> {
> // CODETAG_DEBUG_SESSION_RUNNING_PROG_RECEIVED_SIGINT_PAUSE_PROGRAM
> if (!CMIDriver::Instance().SetDriverStateRunningDebugging())
> {
> const CMIUtilString
> &rErrMsg(CMIDriver::Instance().GetErrorDescription());
>
> SetError(CMIUtilString::Format(MIRSRC(IDS_CMD_ERR_SET_NEW_DRIVER_STATE),
> m_cmdData.strMiCmd.c_str(), rErrMsg.c_str()));
> return MIstatus::failure;
> }
> }
> else
> {
> // ToDo: Re-evaluate if this is required when application near
> finished as this is parsing LLDB error message
> // which seems a hack and is code brittle
> const char *pLldbErr = m_lldbResult.GetError();
> const CMIUtilString
> strLldbMsg(CMIUtilString(pLldbErr).StripCREndOfLine());
> if (strLldbMsg == "error: Process must be launched.")
> {
> CMIDriver::Instance().SetExitApplicationFlag(true);
> }
> }
>
> return MIstatus::success;
> }
>
> //++
> 
> // Details: The invoker requires this function. The command prepares a MI
> Record Result
> //  for the work carried out in the Execute().
> // Type:Overridden.
> // Args:None.
> // Return:  MIstatus::success - Functional succeeded.
> //  MIstatus::failure - Functional failed.
> // Throws:  None.
> //--
> bool
> CMICmdCmdExecContinue::Acknowledge()
> {
> if (m_lldbResult.GetErrorSize() > 0)
> {
> const CMICmnMIValueConst miValueConst(m_lldbResult.GetError());
> const CMICmnMIValueResult miValueResult("message", miValueConst);
> const CMICmnMIResultRecord miRecordResult(m_cmdData.strMiCmdToken,
> CMICmnMIResultRecord::eResultClass_Error, miValueResult);
> m_miResultRecord = miRecordResult;
> }
> else
> {
> const CMICmnMIResultRecord miRecordResult(m_cmdData.strMiCmdToken,
> CMICmnMIResultRecord::eResultClass_Running);
> m_miResultRecord = miRecordResult;
> }
>
> return MIstatus::success;
> }
>
> //++
> 
> // Details: Required by the CMICmdFactory when registering *this command.
> The factory
> //  calls this function to create an instance of *this command.
> // Type:Static method.
> // Args:None.
> // Return:  CMICmdBase * - Pointer to a new command.

Re: [lldb-dev] Add support for OCaml native debugging

[Tamas Berghammer via lldb-dev]

Can you upload your patches to http://reviews.llvm.org/differential/ as we
do all code reviews in that system?

Tamas

On Fri, Jul 8, 2016 at 10:53 AM E BOUTALEB via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> To be frank, I do not like that either. I could add the test the DWARF
> emission feature hit OCaml packages.
>
> Anyway, here are the patches. I would be fine with just the code review if
> the absence of tests is a bother.
> I ran check-lldb before and after applying the patches, and AFAIK I didn't
> introduce any regressions.
>
> Elias
>
> --
> From: tbergham...@google.com
> Date: Thu, 7 Jul 2016 13:23:41 +
>
> Subject: Re: [lldb-dev] Add support for OCaml native debugging
> To: e.bouta...@hotmail.fr; lldb-dev@lists.llvm.org
>
>
> What type of binaries do you want to commit in?
>
> Generally we don't like putting binaries to the repository because they
> are not human readable so it is hard to review/diff them and they will only
> run on a single platform and a single architecture while we support a lot
> of different configuration.
>
> Tamas
>
> On Wed, Jul 6, 2016 at 3:26 PM E BOUTALEB via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I would like to submit two patches for code review.
> They introduce concrete support for OCaml native debugging, granted that
> you have access to the native compiler with DWARF emission support (see
> https://github.com/ocaml/ocaml/pull/574)
>
> This adds about 2000 lines of code.
> The type system isn't particularly complex here, every value is considered
> as an unsigned integer, and interpretation of the value is left to an
> external debugging layer made in OCaml.
> The language plugin handles function name demangling for breakpoints too.
>
> No tests for now. Is it fine to commit binaries with the patchs?
>
> Elias Boutaleb
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Debugging Python scripts (backtraces, variables) with LLDB

[Alexandru Croitor via lldb-dev]

Thanks for replying, it's good to know what the status is at least, as well as 
how it's done in GDB.

> On 06 Jul 2016, at 20:56, Jim Ingham  wrote:
> 
> Nothing of this sort has been done to my knowledge, and I haven't heard of 
> any plans to do so either.
> 
> It should certainly be possible, you just need to grub the C stack and 
> recognize the pattern of a Python stack frame in it and where said frame 
> stashes away the arguments & locals, and then re-present it as a Python 
> frame.  The SB API's should make that fairly straight forward.
> 
> It looks like the Python work in gdb is based on a generic "frame filter" 
> concept in the gdb Python API's.  That's something Greg and I talked about 
> when working on gdb way back, and has been a future goal for lldb from the 
> start, but it hasn't ever gotten beyond discussion to date.  We already have 
> the notion of a "thread provider" which allows the Mach Kernel plugin to 
> present its activations as threads in lldb.  You could do much the same thing 
> in lldb, where a thread would have the native unwind based stack frame and 
> then pluggable StackFrame provider that would show different representations 
> of the stack.
> 
> If anybody is interested in taking on such a project, that would be very cool.
> 
> Jim
> 
>> On Jul 6, 2016, at 8:48 AM, Alexandru Croitor via lldb-dev 
>>  wrote:
>> 
>> Hello,
>> 
>> I've searched for information wether it is possible to debug a python script 
>> using LLDB, and haven't found anything so far.
>> 
>> Specifically I'm interested in an LLDB counterpart to what GDB provides (the 
>> two main pages being https://wiki.python.org/moin/DebuggingWithGdb and 
>> http://fedoraproject.org/wiki/Features/EasierPythonDebugging ).
>> 
>> So python stack traces, python values, etc.
>> 
>> I assume this is not implemented, but are there any plans, or is it even 
>> feasible to implement?
>> 
>> Regards, Alex.
>> ___
>> 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] Add support for OCaml native debugging

[E BOUTALEB via lldb-dev]

To be frank, I do not like that either. I could add the test the DWARF emission 
feature hit OCaml packages.

Anyway, here are the patches. I would be fine with just the code review if the 
absence of tests is a bother.
I ran check-lldb before and after applying the patches, and AFAIK I didn't 
introduce any regressions.

Elias

From: tbergham...@google.com
Date: Thu, 7 Jul 2016 13:23:41 +
Subject: Re: [lldb-dev] Add support for OCaml native debugging
To: e.bouta...@hotmail.fr; lldb-dev@lists.llvm.org

What type of binaries do you want to commit in?
Generally we don't like putting binaries to the repository because they are not 
human readable so it is hard to review/diff them and they will only run on a 
single platform and a single architecture while we support a lot of different 
configuration.
Tamas
On Wed, Jul 6, 2016 at 3:26 PM E BOUTALEB via lldb-dev 
 wrote:



I would like to submit two patches for code review.
They introduce concrete support for OCaml native debugging, granted that you 
have access to the native compiler with DWARF emission support (see 
https://github.com/ocaml/ocaml/pull/574)

This adds about 2000 lines of code. 
The type system isn't particularly complex here, every value is considered as 
an unsigned integer, and interpretation of the value is left to an external 
debugging layer made in OCaml.
The language plugin handles function name demangling for breakpoints too.

No tests for now. Is it fine to commit binaries with the patchs?

Elias Boutaleb
  
___

lldb-dev mailing list

lldb-dev@lists.llvm.org

http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

  

0002-Demangling-OCaml-function-symbols.patch
Description: Binary data


0001-Add-support-for-OCaml-native-debugging.patch
Description: Binary data
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB-MI from Eclipse hangs

[via lldb-dev]

Thanks Greg. Attached is the file after sampling lldb-mi. Please let me
know if you can find some clue from it.

-- 
Have a nice day!
Regards,
Dipti


On Fri, Jul 8, 2016 at 5:49 AM, Greg Clayton  wrote:

> It looks like we continue and then ask fore thread groups? I am not sure
> on the rules of MI. Can you ask another question before receiving a
> response? If we say command 18 is "-exec-continue --thread-group i1", can
> you send command 19 without receiving a response?
>
> 314,372 18-exec-continue --thread-group i1
> 319,380 19-list-thread-groups
>
> I would sample the lldb-mi when it is deadlocked:
>
> % sample lldb-mi
>
> Then attach the sample output to your response.
>
> > On Jul 7, 2016, at 8:53 AM, dipt...@gmail.com wrote:
> >
> >
> 
> > 313,309 2-environment-cd "/Users/admin/Documents/workspace/Hello World
> C++ Project"
> > 313,314 2^done,path="/Users/admin/Documents/workspace/Hello World C++
> Project"
> > 313,315 (gdb)
> > 313,321 3-gdb-set breakpoint pending on
> > 313,322 3^done
> > 313,323 (gdb)
> > 313,327 4-gdb-set detach-on-fork on
> > 313,327 4^done
> > 313,328 (gdb)
> > 313,330 5-enable-pretty-printing
> > 313,388 5^done,supported="0"
> > 313,394 (gdb)
> > 313,404 6-gdb-set python print-stack none
> > 313,404 6^done
> > 313,405 (gdb)
> > 313,407 7-gdb-set print object on
> > 313,408 7^error,msg="The request ''print' error. The option 'object' not
> found' failed."
> > 313,409 (gdb)
> > 313,411 8-gdb-set print sevenbit-strings on
> > 313,413 8^error,msg="The request ''print' error. The option
> 'sevenbit-strings' not found' failed."
> > 313,434 (gdb)
> > 313,436 9-gdb-set host-charset UTF-8
> > 313,436 9^done
> > 313,437 (gdb)
> > 313,439 10-gdb-set target-charset UTF-8
> > 313,440 10^done
> > 313,442 (gdb)
> > 313,446 11-gdb-set target-wide-charset UTF-32
> > 313,447 11^done
> > 313,447 (gdb)
> > 313,449 12-gdb-set target-async off
> > 313,453 12^done
> > 313,453 (gdb)
> > 313,454 13-gdb-set auto-solib-add on
> > 313,455 13^done
> > 313,455 (gdb)
> > 313,464 14-file-exec-and-symbols --thread-group i1
> "/Users/admin/Documents/workspace/Hello World C++\
> >  Project/Debug/Hello World C++ Project"
> > 313,625 14^done
> > 313,626 =library-loaded,id="/Users/admin/Documents/workspace/Hello World
> C++ Project/Debug/Hello Wor\
> > ld C++ Project",target-name="/Users/admin/Documents/workspace/Hello
> World C++ Project/Debug/Hello Wo\
> > rld C++ Project",host-name="/Users/admin/Documents/workspace/Hello World
> C++ Project/Debug/Hello Wor\
> > ld C++ Project",symbols-loaded="0",loaded_addr="-",size="8192"
> > 313,626 (gdb)
> > 313,627 15-target-select remote 192.168.116.141:1234
> > 314,260 15^connected
> > 314,260 =thread-group-started,id="i1",pid="1725"
> > 314,261 =thread-created,id="1",group-id="i1"
> > 314,261 =thread-selected,id="1"
> > 314,261 (gdb)
> > 314,261
> =library-loaded,id="/usr/lib/dyld",target-name="/usr/lib/dyld",host-name="/usr/lib/dyld",sym\
> > bols-loaded="0",loaded_addr="0x7fff65fd2000",size="229376"
> > 314,261 (gdb)
> > 314,261
> =library-loaded,id="/usr/lib/libc++.1.dylib",target-name="/usr/lib/libc++.1.dylib",host-name\
> >
> ="/usr/lib/libc++.1.dylib",symbols-loaded="0",loaded_addr="0x7fff90557000",size="344064"
> > 314,261 (gdb)
> > 314,261
> =library-loaded,id="/usr/lib/libSystem.B.dylib",target-name="/usr/lib/libSystem.B.dylib",hos\
> >
> t-name="/usr/lib/libSystem.B.dylib",symbols-loaded="0",loaded_addr="0x7fff88a4c000",size="8192"
> > 314,261 (gdb)
> > 314,261
> =library-loaded,id="/usr/lib/libc++abi.dylib",target-name="/usr/lib/libc++abi.dylib",host-na\
> >
> me="/usr/lib/libc++abi.dylib",symbols-loaded="0",loaded_addr="0x7fff8fb0f000",size="172032"
> > 314,261 (gdb)
> > 314,261
> =library-loaded,id="/usr/lib/system/libcache.dylib",target-name="/usr/lib/system/libcache.dy\
> >
> lib",host-name="/usr/lib/system/libcache.dylib",symbols-loaded="0",loaded_addr="0x7fff8be07000",\
> > size="20480"
> > 314,262 (gdb)
> > 314,262
> =library-loaded,id="/usr/lib/system/libcommonCrypto.dylib",target-name="/usr/lib/system/libc\
> >
> ommonCrypto.dylib",host-name="/usr/lib/system/libcommonCrypto.dylib",symbols-loaded="0",loaded_addr=\
> > "0x7fff8afba000",size="49152"
> > 314,262 (gdb)
> > 314,262
> =library-loaded,id="/usr/lib/system/libcompiler_rt.dylib",target-name="/usr/lib/system/libco\
> >
> mpiler_rt.dylib",host-name="/usr/lib/system/libcompiler_rt.dylib",symbols-loaded="0",loaded_addr="0x\
> > 7fff8c6ed000",size="32768"
> > 314,262 (gdb)
> > 314,262
> =library-loaded,id="/usr/lib/system/libcopyfile.dylib",target-name="/usr/lib/system/libcopyf\
> >
> ile.dylib",host-name="/usr/lib/system/libcopyfile.dylib",symbols-loaded="0",loaded_addr="0x7fff8\
> > c6f5000",size="36864"
> > 314,262 (gdb)
> > 314,262
> =library-loaded,id="/usr/lib/system/libcorecrypto.dylib",target-name="/usr/lib/system/libcor\