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.
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,
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
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-
> 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 acros
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.o
> 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
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 l
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
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 comm
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 d
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-conti
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 fan
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
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 f
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
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 featu
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, y
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
int
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 M
20 matches
Mail list logo
