[lldb-dev] [Bug 28016] New: Assertion failed: (false && "Unhandled quote character")

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=28016

Bug ID: 28016
   Summary: Assertion failed: (false && "Unhandled quote
character")
   Product: lldb
   Version: 3.6
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: chris+l...@qwirx.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

I typed the following at the lldb prompt:

l BackupStoreFile.cpp`

and this caused lldb to exit with an assertion error:

Assertion failed: (false && "Unhandled quote character"), function
EscapeLLDBCommandArgument, file
/Library/Caches/com.apple.xbs/Sources/lldb/lldb-350.0.21.9/source/Interpreter/Args.cpp,
line 1805.
Abort trap: 6

Presumably this is not supposed to happen? :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 28017] New: error: failed to load objectfile for static-linking archives?

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=28017

Bug ID: 28017
   Summary: error: failed to load objectfile for static-linking
archives?
   Product: lldb
   Version: 3.6
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: chris+l...@qwirx.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

I'm having trouble debugging my application with LLDB on Mac because it seems
to fail to find some of the compiled object files, which are inside a static
link library (.a file). Objects which are compiled directly into the binary
seem to be OK.

I get errors like this when I first try to access line-level information:

(lldb) l BackupStoreFile.cpp
error: backupstore.a(BackupStoreFile.o) failed to load objfile for
/Users/chris/projects/2004/boxi/bb-git/bin/bbackupquery/../../debug/lib/backupstore/backupstore.a
error: backupstore.a(BackupCommands.o) failed to load objfile for
/Users/chris/projects/2004/boxi/bb-git/bin/bbackupquery/../../debug/lib/backupstore/backupstore.a
...
error: common.a(autogen_CommonException.o) failed to load objfile for
/Users/chris/projects/2004/boxi/bb-git/bin/bbackupquery/../../debug/lib/common/common.a
error: Could not find source file "BackupStoreFile.cpp".

I suspect that either lldb does not fully understand the .a archive format, or
another bug prevents it from locating the correct object file inside the
archive. It is definitely there:

chris@Chriss-MacBook-Pro(backupstorepatch)$ ar t
/Users/chris/projects/2004/boxi/bb-git/bin/bbackupquery/../../debug/lib/backupstore/backupstore.a
__.SYMDEF
BackupAccountControl.o
...
BackupStoreDirectory.o
BackupStoreFile.o
BackupStoreFileCmbDiff.o
...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[via lldb-dev]

Chris Lattner  writes:

>> On Jun 2, 2016, at 11:42 AM, via lldb-dev  wrote:
>> 
>> Yeah, I get that and I actually don't mind keeping a linear history.
>> But we definitely should branch for release.  Given release branches,
>> there are a number of questions and tradeoffs about how to backport
>> changes from master/latest development to a release.  Some of those
>> options break linear history.  This is the kind of workflow stuff we
>> should clarify if possible.
>
> +1 for branching for official llvm.org releases, and each branch
> should have its own linear history (from its branch point).

My only hesitation with this is that this requires use of cherry-pick,
which is not idea.  The way most git repositories work is to put
everything that should go into a release branch in the release branch
*first* and then merge the release branch to master, ensuring that
everything going out in a release will make it into the next release.
This is how the gitflow workflow works, for example.

The advantage to this is one can use built-in git tool to ask questions
like, "is this commit in the release branch?"  With cherry-pick you get
logically duplicate commits and making such queries is more cumbersome.

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Joerg Sonnenberger via lldb-dev]

On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote:
> My only hesitation with this is that this requires use of cherry-pick,
> which is not idea.  The way most git repositories work is to put
> everything that should go into a release branch in the release branch
> *first* and then merge the release branch to master, ensuring that
> everything going out in a release will make it into the next release.
> This is how the gitflow workflow works, for example.

The model of "commit to oldest first" is IMO one of the most stupid
concepts I have ever seen in git "workflows". It is contrary to the way
software development works and essentially just a bad workaround for
broken cherry picks. I've seen more than one project starting to use
this model due to advocacy after deciding to use git, stumble around
with it for a release or two and then going back to a normal release
management approach. Even the argument you have presented here does not
make sense to me. Just because a change has been committed to a release
branch, doesn't mean it won't get replaced later.

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[James Y Knight via lldb-dev]

+1 to that. I would strongly suggest that we continue to commit to master
first, like we've always done in llvm.

On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" <
cfe-...@lists.llvm.org> wrote:

> On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote:
> > My only hesitation with this is that this requires use of cherry-pick,
> > which is not idea.  The way most git repositories work is to put
> > everything that should go into a release branch in the release branch
> > *first* and then merge the release branch to master, ensuring that
> > everything going out in a release will make it into the next release.
> > This is how the gitflow workflow works, for example.
>
> The model of "commit to oldest first" is IMO one of the most stupid
> concepts I have ever seen in git "workflows". It is contrary to the way
> software development works and essentially just a bad workaround for
> broken cherry picks. I've seen more than one project starting to use
> this model due to advocacy after deciding to use git, stumble around
> with it for a release or two and then going back to a normal release
> management approach. Even the argument you have presented here does not
> make sense to me. Just because a change has been committed to a release
> branch, doesn't mean it won't get replaced later.
>
> Joerg
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 28019] New: Possibly insecure use of TCP sockets by LLDB

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=28019

Bug ID: 28019
   Summary: Possibly insecure use of TCP sockets by LLDB
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: demioben...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

As I understand it LLDB uses a client-server architecture.  The client and
server communicate over TCP sockets.

This is insecure.  When the client and server are on the same machine and the
socket bound to localhost, this allows local execution of arbitrary code by an
unpriviliged and untrusted user distinct from the user LLDB is running as. 
When the client and server are on different machines, this allows for remote
execution of arbitrary code.

LLDB needs to ensure strong authentication (and, in the remote case,
encryption) of all messages.  This can be done by using SSH.  In the local
case, the best answer is to use Unix domain sockets in a secure directory (on
*nix) or named pipes with a restrictive (non-default) ACL plus authentication
of the server to the client (perhaps by demanding that the server HMAC a random
client-generated string using a key found in a temporary file only the client's
user has access to).

As I understand it LLDB uses an auth hash currently.  This works on localhost
only, but it would be better to HMAC every message.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 28026] New: LLDB-MI doesn't properly output CLI command response using console-stream-output

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=28026

Bug ID: 28026
   Summary: LLDB-MI doesn't properly output CLI command response
using console-stream-output
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: a...@unlimitedcodeworks.xyz
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

According to the MI specification [1], the response for CLI commands should be
output as a console-stream-output record. Right now they are just dumped out
without any stream prefix and quotation.

[1]
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Stream-Records.html#GDB_002fMI-Stream-Records

Step to reproduce:
1. launch using command 'lldb-mi echo'
2. set set target.run-args 1 2 3
3. set show target.run-args

Result output:

(gdb)
-file-exec-and-symbols "echo"
^done
(gdb)
=library-loaded,id="/usr/bin/echo",target-name="/usr/bin/echo",host-name="/usr/bin/echo",symbols-loaded="0",loaded_addr="-",size="0"
set set target.run-args 1 2 3
^done
(gdb)
set show target.run-args
target.run-args (array of strings) =
  [0]: "1"
  [1]: "2"
  [2]: "3"
^done
(gdb)



Expected output:

(gdb)
-file-exec-and-symbols "echo"
^done
(gdb)
=library-loaded,id="/usr/bin/echo",target-name="/usr/bin/echo",host-name="/usr/bin/echo",symbols-loaded="0",loaded_addr="-",size="0"
set set target.run-args 1 2 3
^done
(gdb)
set show target.run-args
~ "target.run-args (array of strings) =\n"
~ "  [0]: \"1\"\n"
~ "  [1]: \"2\"\n"
~ "  [2]: \"3\"\n"
^done
(gdb)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Bruce Hoult via lldb-dev]

I'd suggest a workflow like the following:

- developer commits locally to a feature/bug dev branch. You can commit
work in progress, experiments, have bad commit messages etc

- developer commits locally to a feature/bug release branch. Tidy up into a
small number of logical commits, nice messages etc. I'd suggest it's good
to have at least two commits: 1) a commit adding a test that fails, and is
marked as expected to fail, demonstrating the bug or lack of feature. 2) a
commit that fixes the bug or adds the feature, and marks the test as
expected to pass.

- developer rebases to master and tests

- developer pushes their feature/bug release branch to their github fork of
llvm, issues a pull request

- the appropriate maintainer (or or automatic system) causes build and
tests to be run on the proposed bug fix.

- if the tests work, then do a "git merge --no-ff" to master

There's room to discuss the last part. That gives a master history with
exactly one commit per feature or bug fix. The details of how it was done
are on a different branch that merges back.

You might prefer merge --ff-only. This means that the merge can only happen
if the new feature has been rebased to the head of master. The commits in
the new feature each become a commit in master. In this case you should
make very sure that every commit works -- which is defined as no crashes;
tests expected to work, work; tests expected to fail, fail.


On Mon, Jun 6, 2016 at 8:07 PM, James Y Knight via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> +1 to that. I would strongly suggest that we continue to commit to master
> first, like we've always done in llvm.
>
> On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" <
> cfe-...@lists.llvm.org> wrote:
>
>> On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote:
>> > My only hesitation with this is that this requires use of cherry-pick,
>> > which is not idea.  The way most git repositories work is to put
>> > everything that should go into a release branch in the release branch
>> > *first* and then merge the release branch to master, ensuring that
>> > everything going out in a release will make it into the next release.
>> > This is how the gitflow workflow works, for example.
>>
>> The model of "commit to oldest first" is IMO one of the most stupid
>> concepts I have ever seen in git "workflows". It is contrary to the way
>> software development works and essentially just a bad workaround for
>> broken cherry picks. I've seen more than one project starting to use
>> this model due to advocacy after deciding to use git, stumble around
>> with it for a release or two and then going back to a normal release
>> management approach. Even the argument you have presented here does not
>> make sense to me. Just because a change has been committed to a release
>> branch, doesn't mean it won't get replaced later.
>>
>> Joerg
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Richard Smith via lldb-dev]

On 6 Jun 2016 12:52 p.m., "Bruce Hoult via cfe-dev" 
wrote:
>
> I'd suggest a workflow like the following:
>
> - developer commits locally to a feature/bug dev branch. You can commit
work in progress, experiments, have bad commit messages etc
>
> - developer commits locally to a feature/bug release branch. Tidy up into
a small number of logical commits, nice messages etc. I'd suggest it's good
to have at least two commits: 1) a commit adding a test that fails, and is
marked as expected to fail, demonstrating the bug or lack of feature. 2) a
commit that fixes the bug or adds the feature, and marks the test as
expected to pass.

Our policy and workflow is to upstream small, incremental changes wherever
possible (rather than presenting reviewers with a complete, monolithic
change to review), and that seems to conflict somewhat with your suggestion
of working on feature branches. But so long as the changes we receive for
review are sufficiently small and authors are happy to receive feedback
that the design of the first patch in a series of N is problematic (so the
whole series needs rework), I don't think we need to care how they produced
the patch.

> - developer rebases to master and tests
>
> - developer pushes their feature/bug release branch to their github fork
of llvm, issues a pull request
>
> - the appropriate maintainer (or or automatic system) causes build and
tests to be run on the proposed bug fix.
>
> - if the tests work, then do a "git merge --no-ff" to master
>
> There's room to discuss the last part. That gives a master history with
exactly one commit per feature or bug fix. The details of how it was done
are on a different branch that merges back.

I assume you're simplifying for exposition; that's not really how git works
(commits aren't associated with any particular branch except perhaps by a
convention of annotations in the commit message; a branch is just a label
for its current head commit). More precisely, what this would give us is a
linear one-commit-per-merge history *if we follow the first parent of each
commit from master*. I think that should be fine in practice, but it might
be better to instead only allow a commit to be pushed to master on github
if its first parent is the current master; that would allow us to avoid
merge commits in most cases.

> You might prefer merge --ff-only. This means that the merge can only
happen if the new feature has been rebased to the head of master. The
commits in the new feature each become a commit in master. In this case you
should make very sure that every commit works -- which is defined as no
crashes; tests expected to work, work; tests expected to fail, fail.
>
>
> On Mon, Jun 6, 2016 at 8:07 PM, James Y Knight via llvm-dev <
llvm-...@lists.llvm.org> wrote:
>>
>> +1 to that. I would strongly suggest that we continue to commit to
master first, like we've always done in llvm.
>>
>>
>> On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" <
cfe-...@lists.llvm.org> wrote:
>>>
>>> On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote:
>>> > My only hesitation with this is that this requires use of cherry-pick,
>>> > which is not idea.  The way most git repositories work is to put
>>> > everything that should go into a release branch in the release branch
>>> > *first* and then merge the release branch to master, ensuring that
>>> > everything going out in a release will make it into the next release.
>>> > This is how the gitflow workflow works, for example.
>>>
>>> The model of "commit to oldest first" is IMO one of the most stupid
>>> concepts I have ever seen in git "workflows". It is contrary to the way
>>> software development works and essentially just a bad workaround for
>>> broken cherry picks. I've seen more than one project starting to use
>>> this model due to advocacy after deciding to use git, stumble around
>>> with it for a release or two and then going back to a normal release
>>> management approach. Even the argument you have presented here does not
>>> make sense to me. Just because a change has been committed to a release
>>> branch, doesn't mean it won't get replaced later.
>>>
>>> Joerg
>>> ___
>>> cfe-dev mailing list
>>> cfe-...@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Matthias Braun via lldb-dev]

> On Jun 6, 2016, at 1:29 PM, Richard Smith via llvm-dev 
>  wrote:
> 
> On 6 Jun 2016 12:52 p.m., "Bruce Hoult via cfe-dev"  > wrote:
> >
> > I'd suggest a workflow like the following:
> >
> > - developer commits locally to a feature/bug dev branch. You can commit 
> > work in progress, experiments, have bad commit messages etc
> >
> > - developer commits locally to a feature/bug release branch. Tidy up into a 
> > small number of logical commits, nice messages etc. I'd suggest it's good 
> > to have at least two commits: 1) a commit adding a test that fails, and is 
> > marked as expected to fail, demonstrating the bug or lack of feature. 2) a 
> > commit that fixes the bug or adds the feature, and marks the test as 
> > expected to pass
> 
While I applaud small patches, this is going too far in my opinion. In my 
opinion the system should be designed to ease reading and understanding the 
changes (since a change is usually read by more people than it is written...). 
In this specific instance I really like the fact to have the testcase together 
with the commit that fixes it because it often present a short understandable 
and concrete example of the issue getting fixed [1]

- Matthias

[1] I should mention here that we have a number of testcases in the repository 
that fail this crtiterium! Cases where the test is just extracted from a real 
world input but still a lot of instructions and information irrelevant to the 
problem. Just because a testcase is bugpoint-reduced does not mean it is 
minimal!___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Release_38 cherry-picks

[Francis Ricci via lldb-dev]

Hi all,

I'd like to merge a few more small bugfixes onto the 38 release
branch. I'll plan to do it tomorrow (3/7) in the evening if I don't
hear any objections. Thanks!

r259433 - Fix getCompiler in unit testing framework on compiler symlinks
r267459 - Add missing qRegisterInfo option to gdbremote testcase
r271899 - Don't remove PIE executables when using svr4 packets

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

[lldb-dev] Catching async debugger output

[Vadim Chugunov via lldb-dev]

Hello,
Is there a way for a python script to catch asynchronous debugger output,
such as the output of stop hooks?  I've tried attaching a listener to
CommandInterpreter's broadcaster, but no events seem to be ever fired.
Anything else I should try?

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