Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Hans Wennborg via lldb-dev]

On Fri, Aug 17, 2018 at 1:27 PM, Dimitry Andric  wrote:
> On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev 
>  wrote:
>> On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote:
>>> This is a regression caused by https://reviews.llvm.org/rL323281:
>>>
>>> 
>>> r323281 | wmi | 2018-01-23 23:27:57 + (Tue, 23 Jan 2018) | 12 lines
>>>
>>> Adjust MaxAtomicInlineWidth for i386/i486 targets.
>>>
>>> This is to fix the bug reported in 
>>> https://bugs.llvm.org/show_bug.cgi?id=34347#c6.
>>> Currently, all  MaxAtomicInlineWidth of x86-32 targets are set to 64. 
>>> However,
>>> i386 doesn't support any cmpxchg related instructions. i486 only supports 
>>> cmpxchg.
>>> So in this patch MaxAtomicInlineWidth is reset as follows:
>>> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is 
>>> supported.
>>> For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg.
>>> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because 
>>> of cmpxchg8b.
>>
>> This seems to be somewhat undesirable. Does *anyone* care about real
>> i386 support at this point? NetBSD certainly doesn't and I think we are
>> already the odd man for a number of cases like this.
>
>
> Yes, and since this causes quite a number of regressions for us, I would
> really prefer this revision to be reverted, at least in the 7.0.0
> branch.  I have already reverted it locally in our FreeBSD project
> branch for importing llvm/clang 7.0.0.  Hans, what is your opinion about
> this?

I'd prefer to see it reverted on trunk, and then merge the revert.

Is there a discussion about reverting started somewhere besides this
thread? It would be nice if we could get this figured out before RC2
(tomorrow, if the schedule holds..)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] PDB symbol reader supports C++ only?

[Vadim Chugunov via lldb-dev]

Would you mind going into a bit more detail on what sort of problems an
unknown language could cause?   I'd like to understand the issue before
jumping in to fix anything.  AFAIK, in the case of DWARF symbols, debug
info for unknown languages is still used, so it wouldn't be the first for
LLDB...

Also, the second fragment

checks for specific file extensions, which is an unreliable method, IMO,
since there's more extensions in use for c++ alone.  Code could also be
generated by a template engine, which will probably use a different
extension, etc.   I'd rather not just hardcode '.rs' for Rust.
I was hoping Aaron could commend on why this is necessary (i.e. why not
just trust the language flag?)

Thanks!

On Mon, Aug 20, 2018 at 7:35 PM Zachary Turner  wrote:

> Various parts of lldb require knowing the source language. It’s possible
> that things will mostly work if you report that the language is c++, but
> you’ll probably get errors in other areas. It goes all the way down to the
> CodeView level, where certain cv records indicate the original source
> language. Can you check cvconst.h (ships with DIA SDK) and look for the
> enumeration corresponding to source language? Does it have a value for
> Rust? I’m guessing it doesn’t. When you generate PDBs for Rust you probably
> need to put something unique value there, then we could properly set the
> language in lldb
> On Mon, Aug 20, 2018 at 7:15 PM Vadim Chugunov  wrote:
>
>> Hi!
>> I've been investigating why LLDB refuses to set breakpoints in Rust
>> source files when using PDB debug info on Windows...  This seems to stem
>> from a couple of checks here
>> 
>> and here
>> .
>>
>> I am wondering, what is the backstory there?  Are those still necessary?
>> I tried disabling them and Rust debugging worked just fine...
>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] PDB symbol reader supports C++ only?

[Zachary Turner via lldb-dev]

I think Aaron added that code for when the language is not set, but he can
clarify.

Off the top of my head I guess it helps with demangling symbols. Eg you
can’t demangle symbols from a TU without knowing what the language is.
There could be other reasons though. For example each language is going to
have an ABI with respect to the generated code. This is used for unwinding,
stepping, jitting code to run in the target, etc. all of those could be
affected by the language.

Maybe someone else can chime in with more reasons
On Tue, Aug 21, 2018 at 7:10 PM Vadim Chugunov  wrote:

> Would you mind going into a bit more detail on what sort of problems an
> unknown language could cause?   I'd like to understand the issue before
> jumping in to fix anything.  AFAIK, in the case of DWARF symbols, debug
> info for unknown languages is still used, so it wouldn't be the first for
> LLDB...
>
> Also, the second fragment
> 
> checks for specific file extensions, which is an unreliable method, IMO,
> since there's more extensions in use for c++ alone.  Code could also be
> generated by a template engine, which will probably use a different
> extension, etc.   I'd rather not just hardcode '.rs' for Rust.
> I was hoping Aaron could commend on why this is necessary (i.e. why not
> just trust the language flag?)
>
> Thanks!
>
> On Mon, Aug 20, 2018 at 7:35 PM Zachary Turner  wrote:
>
>> Various parts of lldb require knowing the source language. It’s possible
>> that things will mostly work if you report that the language is c++, but
>> you’ll probably get errors in other areas. It goes all the way down to the
>> CodeView level, where certain cv records indicate the original source
>> language. Can you check cvconst.h (ships with DIA SDK) and look for the
>> enumeration corresponding to source language? Does it have a value for
>> Rust? I’m guessing it doesn’t. When you generate PDBs for Rust you probably
>> need to put something unique value there, then we could properly set the
>> language in lldb
>> On Mon, Aug 20, 2018 at 7:15 PM Vadim Chugunov  wrote:
>>
>>> Hi!
>>> I've been investigating why LLDB refuses to set breakpoints in Rust
>>> source files when using PDB debug info on Windows...  This seems to stem
>>> from a couple of checks here
>>> 
>>> and here
>>> .
>>>
>>> I am wondering, what is the backstory there?  Are those still
>>> necessary?  I tried disabling them and Rust debugging worked just fine...
>>>
>>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev