Re: [lldb-dev] [cfe-dev] [10.0.0 Release] Release Candidate 5 is here

2020-03-23 Thread James Henderson via lldb-dev 
 Hi Hans,

I don't know if you'll be planning on RC6, but this bug:
https://bugs.llvm.org/show_bug.cgi?id=45271 was just filed as a regression
in LLVM 10 versus LLVM 9, and looks like it could break things (potentially
silently) for at least some installations of llvm-strip. There's a fix
that's basically ready (https://reviews.llvm.org/D76562). I'll leave it up
to you as to whether the fix should be included in the release or not (it
almost certainly should be in a patch release if it doesn't, I think).

James

On Thu, 19 Mar 2020 at 13:51, Hans Wennborg via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> Hello again,
>
> I had hoped that rc4 would be the last one, but I wanted to pick up
> one more fix, so here we go.
>
> Release Candidate 5 was just tagged as llvmorg-10.0.0-rc5 on the
> release branch at 35627038123.
>
> Source code and docs are available at
> https://prereleases.llvm.org/10.0.0/#rc5 and
> https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc5
>
> If nothing new comes up, I plan to tag 'final' on Monday. Testers, if
> you still have cycles, please take this for a quick spin.
>
> Thanks,
> Hans
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [10.0.0 Release] Release Candidate 5 is here

2020-03-23 Thread Hans Wennborg via lldb-dev 
I think it's too late for this, but distributions that install the
tool like that may want to take that patch downstream.

On Mon, Mar 23, 2020 at 9:55 AM James Henderson
 wrote:
>
> Hi Hans,
>
> I don't know if you'll be planning on RC6, but this bug: 
> https://bugs.llvm.org/show_bug.cgi?id=45271 was just filed as a regression in 
> LLVM 10 versus LLVM 9, and looks like it could break things (potentially 
> silently) for at least some installations of llvm-strip. There's a fix that's 
> basically ready (https://reviews.llvm.org/D76562). I'll leave it up to you as 
> to whether the fix should be included in the release or not (it almost 
> certainly should be in a patch release if it doesn't, I think).
>
> James
>
> On Thu, 19 Mar 2020 at 13:51, Hans Wennborg via cfe-dev 
>  wrote:
>>
>> Hello again,
>>
>> I had hoped that rc4 would be the last one, but I wanted to pick up
>> one more fix, so here we go.
>>
>> Release Candidate 5 was just tagged as llvmorg-10.0.0-rc5 on the
>> release branch at 35627038123.
>>
>> Source code and docs are available at
>> https://prereleases.llvm.org/10.0.0/#rc5 and
>> https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc5
>>
>> If nothing new comes up, I plan to tag 'final' on Monday. Testers, if
>> you still have cycles, please take this for a quick spin.
>>
>> Thanks,
>> Hans
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB sometimes escapes unicode characters, sometimes not

2020-03-23 Thread Lutz Justen via lldb-dev 
Hey,

We've noticed that LLDB sometimes escapes certain characters (e.g. in the
+128/negative range) of const char* strings and sometimes it doesn't. In
particular, this happens for unicode strings:

C++:
const char* str =  u8"😂";

LLDB:
(lldb) expr str
(const char *) $0 = 0x7ff662489d18 "â‰ĄÆ’ĂżĂ©"
(lldb) expr (const char*)str
(const char *) $1 = 0x7ff662489d18
"\xfff0\xff9f\xff98\xff82"

To my understanding, evaluating 'str' and '(const char*)str' should be the
same since str is already a const char*.

We've found that the code takes a different path at this location:
https://source.corp.google.com/piper///depot/google3/third_party/llvm/llvm-project/lldb/source/Core/FormatEntity.cpp;l=865;rcl=294541377

Any idea what's going on? We'd like to get the unescaped strings. Is it
possible to enforce this?

Thanks,

- Lutz

-- 

Dr. Lutz Justen

Software Engineer

ljus...@google.com


Google Germany GmbH

ABC-Str. 19


20354 Hamburg


GeschĂ€ftsfĂŒhrer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Diese E-Mail ist vertraulich. Falls sie diese fÀlschlicherweise erhalten
haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
löschen Sie alle Kopien und AnhÀnge davon und lassen Sie mich bitte wissen,
dass die E-Mail an die falsche Person gesendet wurde.

This e-mail is confidential. If you received this communication by mistake,
please don't forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.


Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen
wider und dient als Basis fĂŒr weitere GesprĂ€che. Er soll keine rechtlich
verbindliche Verpflichtung begrĂŒnden. Eine solche Verpflichtung wird allein
durch einen zwischen allen beteiligten Parteien abgeschlossenen,
schriftlichen Vertrag geschaffen.

The above terms reflect a potential business arrangement, are provided
solely as a basis for further discussion, and are not intended to be and do
not constitute a legally binding obligation. No legally binding obligations
will be created, implied, or inferred until an agreement in final form is
executed in writing by all parties involved.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB sometimes escapes unicode characters, sometimes not

2020-03-23 Thread Lutz Justen via lldb-dev 
Sorry, the link was internal. Here's the proper on:
https://github.com/llvm-mirror/lldb/blob/master/source/Core/FormatEntity.cpp#L861


On Mon, Mar 23, 2020 at 4:00 PM Lutz Justen  wrote:

> Hey,
>
> We've noticed that LLDB sometimes escapes certain characters (e.g. in the
> +128/negative range) of const char* strings and sometimes it doesn't. In
> particular, this happens for unicode strings:
>
> C++:
> const char* str =  u8"😂";
>
> LLDB:
> (lldb) expr str
> (const char *) $0 = 0x7ff662489d18 "â‰ĄÆ’ĂżĂ©"
> (lldb) expr (const char*)str
> (const char *) $1 = 0x7ff662489d18
> "\xfff0\xff9f\xff98\xff82"
>
> To my understanding, evaluating 'str' and '(const char*)str' should be the
> same since str is already a const char*.
>
> We've found that the code takes a different path at this location:
>
> https://source.corp.google.com/piper///depot/google3/third_party/llvm/llvm-project/lldb/source/Core/FormatEntity.cpp;l=865;rcl=294541377
>
> Any idea what's going on? We'd like to get the unescaped strings. Is it
> possible to enforce this?
>
> Thanks,
>
> - Lutz
>
> --
>
> Dr. Lutz Justen
>
> Software Engineer
>
> ljus...@google.com
>
>
> Google Germany GmbH
>
> ABC-Str. 19
> 
>
> 20354 Hamburg
> 
>
> GeschĂ€ftsfĂŒhrer: Paul Manicle, Halimah DeLaine Prado
>
> Registergericht und -nummer: Hamburg, HRB 86891
>
> Diese E-Mail ist vertraulich. Falls sie diese fÀlschlicherweise erhalten
> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
> löschen Sie alle Kopien und AnhÀnge davon und lassen Sie mich bitte wissen,
> dass die E-Mail an die falsche Person gesendet wurde.
>
> This e-mail is confidential. If you received this communication by
> mistake, please don't forward it to anyone else, please erase all copies
> and attachments, and please let me know that it has gone to the wrong
> person.
>
>
> Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen
> wider und dient als Basis fĂŒr weitere GesprĂ€che. Er soll keine rechtlich
> verbindliche Verpflichtung begrĂŒnden. Eine solche Verpflichtung wird allein
> durch einen zwischen allen beteiligten Parteien abgeschlossenen,
> schriftlichen Vertrag geschaffen.
>
> The above terms reflect a potential business arrangement, are provided
> solely as a basis for further discussion, and are not intended to be and do
> not constitute a legally binding obligation. No legally binding obligations
> will be created, implied, or inferred until an agreement in final form is
> executed in writing by all parties involved.
>


-- 

Dr. Lutz Justen

Software Engineer

ljus...@google.com


Google Germany GmbH

ABC-Str. 19


20354 Hamburg


GeschĂ€ftsfĂŒhrer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Diese E-Mail ist vertraulich. Falls sie diese fÀlschlicherweise erhalten
haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
löschen Sie alle Kopien und AnhÀnge davon und lassen Sie mich bitte wissen,
dass die E-Mail an die falsche Person gesendet wurde.

This e-mail is confidential. If you received this communication by mistake,
please don't forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.


Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen
wider und dient als Basis fĂŒr weitere GesprĂ€che. Er soll keine rechtlich
verbindliche Verpflichtung begrĂŒnden. Eine solche Verpflichtung wird allein
durch einen zwischen allen beteiligten Parteien abgeschlossenen,
schriftlichen Vertrag geschaffen.

The above terms reflect a potential business arrangement, are provided
solely as a basis for further discussion, and are not intended to be and do
not constitute a legally binding obligation. No legally binding obligations
will be created, implied, or inferred until an agreement in final form is
executed in writing by all parties involved.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [10.0.0 Release] Release Candidate 6 is here

2020-03-23 Thread Hans Wennborg via lldb-dev 
Dear everyone,

I had hoped rc5 would be the last one, but we needed to pick up yet another fix.

Release candidate 6 was tagged as llvmorg-10.0.0-rc6 on the
release/10.x branch at d32170dbd5b. It picks up the fix for
https://llvm.org/pr45270

Source code and docs are available at
https://prereleases.llvm.org/10.0.0/#rc6 and
https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc6

The plan is to tag 'final' tomorrow.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] lldb-instr not working

2020-03-23 Thread Walter via lldb-dev 
Hi, I've recently tried to use lldb-instr, as mentioned in
https://lldb.llvm.org/resources/sbapi.html, but I'm having the following
issue when running it on darwin.

./lldb-instr
> LLVM ERROR: Unable to find target for this triple (no targets are
registered)

Is this a known issue? Or should lldb-instr be built in a special way to
make it aware of the local compilation target?

Does anyone know anything about this?

Thanks!

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

Re: [lldb-dev] lldb-instr not working

2020-03-23 Thread Jonas Devlieghere via lldb-dev 
Hi Walter,

lldb-instr needs compile_commands.json file to figure out the exact
compiler invocation for every file. Can you verify that the file exists in
the directory you're running lldb-instr from?

Cheers,
Jonas

On Mon, Mar 23, 2020 at 1:29 PM Walter via lldb-dev 
wrote:

> Hi, I've recently tried to use lldb-instr, as mentioned in
> https://lldb.llvm.org/resources/sbapi.html, but I'm having the following
> issue when running it on darwin.
>
> ./lldb-instr
> > LLVM ERROR: Unable to find target for this triple (no targets are
> registered)
>
> Is this a known issue? Or should lldb-instr be built in a special way to
> make it aware of the local compilation target?
>
> Does anyone know anything about this?
>
> Thanks!
>
> - Walter
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB sometimes escapes unicode characters, sometimes not

2020-03-23 Thread Jaroslav Sevcik via lldb-dev 
Attempt at a fix: https://reviews.llvm.org/D76650

On Mon, Mar 23, 2020 at 5:22 PM Lutz Justen via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Sorry, the link was internal. Here's the proper on:
>
> https://github.com/llvm-mirror/lldb/blob/master/source/Core/FormatEntity.cpp#L861
>
>
> On Mon, Mar 23, 2020 at 4:00 PM Lutz Justen  wrote:
>
>> Hey,
>>
>> We've noticed that LLDB sometimes escapes certain characters (e.g. in the
>> +128/negative range) of const char* strings and sometimes it doesn't. In
>> particular, this happens for unicode strings:
>>
>> C++:
>> const char* str =  u8"😂";
>>
>> LLDB:
>> (lldb) expr str
>> (const char *) $0 = 0x7ff662489d18 "â‰ĄÆ’ĂżĂ©"
>> (lldb) expr (const char*)str
>> (const char *) $1 = 0x7ff662489d18
>> "\xfff0\xff9f\xff98\xff82"
>>
>> To my understanding, evaluating 'str' and '(const char*)str' should be
>> the same since str is already a const char*.
>>
>> We've found that the code takes a different path at this location:
>>
>> https://source.corp.google.com/piper///depot/google3/third_party/llvm/llvm-project/lldb/source/Core/FormatEntity.cpp;l=865;rcl=294541377
>>
>> Any idea what's going on? We'd like to get the unescaped strings. Is it
>> possible to enforce this?
>>
>> Thanks,
>>
>> - Lutz
>>
>> --
>>
>> Dr. Lutz Justen
>>
>> Software Engineer
>>
>> ljus...@google.com
>>
>>
>> Google Germany GmbH
>>
>> ABC-Str. 19
>> 
>>
>> 20354 Hamburg
>> 
>>
>> GeschĂ€ftsfĂŒhrer: Paul Manicle, Halimah DeLaine Prado
>>
>> Registergericht und -nummer: Hamburg, HRB 86891
>>
>> Diese E-Mail ist vertraulich. Falls sie diese fÀlschlicherweise erhalten
>> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
>> löschen Sie alle Kopien und AnhÀnge davon und lassen Sie mich bitte wissen,
>> dass die E-Mail an die falsche Person gesendet wurde.
>>
>> This e-mail is confidential. If you received this communication by
>> mistake, please don't forward it to anyone else, please erase all copies
>> and attachments, and please let me know that it has gone to the wrong
>> person.
>>
>>
>> Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen
>> wider und dient als Basis fĂŒr weitere GesprĂ€che. Er soll keine rechtlich
>> verbindliche Verpflichtung begrĂŒnden. Eine solche Verpflichtung wird allein
>> durch einen zwischen allen beteiligten Parteien abgeschlossenen,
>> schriftlichen Vertrag geschaffen.
>>
>> The above terms reflect a potential business arrangement, are provided
>> solely as a basis for further discussion, and are not intended to be and do
>> not constitute a legally binding obligation. No legally binding obligations
>> will be created, implied, or inferred until an agreement in final form is
>> executed in writing by all parties involved.
>>
>
>
> --
>
> Dr. Lutz Justen
>
> Software Engineer
>
> ljus...@google.com
>
>
> Google Germany GmbH
>
> ABC-Str. 19
> 
>
> 20354 Hamburg
> 
>
> GeschĂ€ftsfĂŒhrer: Paul Manicle, Halimah DeLaine Prado
>
> Registergericht und -nummer: Hamburg, HRB 86891
>
> Diese E-Mail ist vertraulich. Falls sie diese fÀlschlicherweise erhalten
> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
> löschen Sie alle Kopien und AnhÀnge davon und lassen Sie mich bitte wissen,
> dass die E-Mail an die falsche Person gesendet wurde.
>
> This e-mail is confidential. If you received this communication by
> mistake, please don't forward it to anyone else, please erase all copies
> and attachments, and please let me know that it has gone to the wrong
> person.
>
>
> Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen
> wider und dient als Basis fĂŒr weitere GesprĂ€che. Er soll keine rechtlich
> verbindliche Verpflichtung begrĂŒnden. Eine solche Verpflichtung wird allein
> durch einen zwischen allen beteiligten Parteien abgeschlossenen,
> schriftlichen Vertrag geschaffen.
>
> The above terms reflect a potential business arrangement, are provided
> solely as a basis for further discussion, and are not intended to be and do
> not constitute a legally binding obligation. No legally binding obligations
> will be created, implied, or inferred until an agreement in final form is
> executed in writing by all parties involved.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>


-- 

Jaroslav Sevcik |  Software Engineer |  ja...@google.com |

Google Germany GmbH
Erika-Mann-Str. 33
80636 MĂŒnchen

GeschĂ€ftsfĂŒhrer: Paul Manicle, Halimah DeLaine Prado | Registergericht und
-nummer: Hamburg, HRB 86891 | Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adress