Re: [lldb-dev] [Openmp-dev] [6.0.0 Release] Release Candidate 3 tagged

2018-02-25 Thread Dimitry Andric via lldb-dev
On 23 Feb 2018, at 16:14, Hans Wennborg via Openmp-dev 
 wrote:
> 6.0.0-rc3 was just tagged, after r325901 on the branch.
> 
> There are still a few open blockers, but I'm not sure we'll actually
> end up blocking on all of them. So depending on what comes up, this
> release candidate is probably pretty close to what the final release
> will look like (I'm still hoping for more release notes, though).
> 
> I'm hoping we can get to 'final' sometime next week.
> 
> Please test, let me know how it goes, and upload binaries.

Built, tested and uploaded:

SHA256 (clang+llvm-6.0.0-rc3-amd64-unknown-freebsd-10.tar.xz) = 
210089c6bcce118b3defe4084c4e0a0afa482deec42466ad31f0c8de49296ca7
SHA256 (clang+llvm-6.0.0-rc3-i386-unknown-freebsd-10.tar.xz) = 
b4a3678bc86ab949ebf9845b524408fcf7f825de09f37d2a70fb4447cef3d8e6

On amd64-freebsd10 there were 526 unexpected test failures (down from 896 at 
rc2):

  Expected Passes: 45381
  Passes With Retry  : 4
  Expected Failures  : 185
  Unsupported Tests  : 2937
  Unexpected Passes  : 1
  Unexpected Failures: 526

On i386-freebsd10 there were 250 unexpected test failures (down from 619 at 
rc2):

  Expected Passes: 44223
  Passes With Retry  : 4
  Expected Failures  : 194
  Unsupported Tests  : 1954
  Unexpected Passes  : 1
  Unexpected Failures: 250

In both cases, the "unexpected pass" is lldb :: 
Expr/TestCallStdStringFunction.test, no idea where that came from, though.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] Adding D language demangling support

2018-02-25 Thread Timothee Cour via lldb-dev
update:

* D now correctly prefixes its symbols with an extra underscore on OSX
(cf https://dlang.org/changelog/2.079.0.html#fix8207) and gdb
correctly demangles D symbols
* in https://github.com/dlang/druntime/pull/2083 I had a PR to support
demangling C++ symbols along with D symbols for D programs via runtime
loading (dlopen) of libc++ ; could we use a similar technique for lldb
by allowing user to dlopen a shared library that would customize
demangling?





On Mon, Sep 26, 2016 at 8:50 AM, Greg Clayton  wrote:
> Just did, and it looks good.
>
>> On Sep 26, 2016, at 3:49 AM, Johan Engelen  wrote:
>>
>> Timothee, do you intend to work on this?
>> What can I do to help?
>>
>> In the meanwhile, I'd appreciate it if someone could take a look at 
>> https://reviews.llvm.org/D24794 (currently, debugging D code is very much 
>> broken without that change).
>>
>> -Johan
>>
>>
>> On Thu, Sep 22, 2016 at 7:21 PM, Greg Clayton via lldb-dev 
>>  wrote:
>> I like the JSON approach. We might need to include the mangled name for the 
>> function or specify where arguments go if we aren't going to expect a canned 
>> function to be in each dylib. That is a bit harder, but something we should 
>> think about.
>>
>> If we look at __cxa_demangle:
>>
>>
>> char* abi::__cxa_demangle(const char *mangled_name, char *output_buffer, 
>> size_t *length, int *status);
>>
>> I am not sure how we would logically specify this in the JSON... Where to 
>> put the name to demangle, how to call it etc...
>>
>> > On Sep 22, 2016, at 9:56 AM, Timothee Cour  
>> > wrote:
>> >
>> >
>> >
>> > On Wed, Sep 21, 2016 at 4:13 PM, Greg Clayton via lldb-dev 
>> >  wrote:
>> > You could have a setting that allows you to specify prefix as the key with 
>> > a dylib path as a value. Would you expect a function with certain name or 
>> > would you need to specify the function name (probably mangled) as well? 
>> > Let me know what you are thinking?
>> >
>> >
>> > whatever works it doesn't really matter so long there's something to get 
>> > started, I was going for something simple to start with but if you want 
>> > this level of flexibility how about using a json config file:
>> >
>> > export LLDB_DEMANGLE_CONFIG_FILE="~/.lldbl.demangle.conf"
>> >
>> > cat ~/.lldbl.demangle.conf
>> >
>> > {"demangle":
>> >   ["D": {"prefix" : "_D", "shared_libary_file" : 
>> > "/path/libdemangled.dylib", "mangled_name", "_demangle_custom_D"}],
>> >   ["nim":  /* same for nim language */ ],
>> > }
>> >
>> > Greg
>> >
>> > > On Sep 21, 2016, at 3:50 PM, Timothee Cour  
>> > > wrote:
>> > >
>> > >
>> > >
>> > > On Wed, Sep 21, 2016 at 3:35 PM, Greg Clayton via lldb-dev 
>> > >  wrote:
>> > > Sounds like you could then make a setting that is a dictionary where you 
>> > > say what the prefix is (like maybe "_D") and the value is the path to 
>> > > the tool to use? This would be easy to implement. Demangling does tend 
>> > > to be one of the most expensive parts of symbol file and debug info 
>> > > parsing, so if you do this, you will want to make sure the shell tool 
>> > > can be spawned and kept running maybe?
>> > >
>> > > Greg
>> > >
>> > >
>> > > where in the lldb code would be such entry point?
>> > >
>> > > instead of a binary it can just be a library dynamically loaded via 
>> > > dlopen (as i wrote, though I should've called it LLDB_DEMANGLER_LIB 
>> > > instead of LLDB_DEMANGLER_EXE), and the dynamically loaded symbol be 
>> > > cached to make sure it's dlopen'd at most once per process.
>> > >
>> > > Then it's easy enough for us to write a demangleCustom that is fast on 
>> > > the D side of things. It can also work with a binary instead of a dllib 
>> > > but would be a bit slower (could have a client server model, but that's 
>> > > more complex than the simple dllib solution i was proposing).
>> > >
>> > > yes, we could use a prefix for that as well.
>> > >
>> > >
>> > > > On Sep 21, 2016, at 3:30 PM, Timothee Cour  
>> > > > wrote:
>> > > >
>> > > >
>> > > >
>> > > > On Wed, Sep 21, 2016 at 3:10 PM, Greg Clayton  
>> > > > wrote:
>> > > > There is no external demangling plug-in infrastructure at the moment, 
>> > > > but you could add functionality that would allow it. No one is going 
>> > > > to have D installed by default. Where do you expect your demangler 
>> > > > dylib to live?
>> > > > Would you just add code that tries to locate the dylib in N places on 
>> > > > the current system and try to dlopen it? Avoiding duplication and just 
>> > > > not having the functionality at all unless something else is might not 
>> > > > make it that useful. Is D stable? Is the mangling changing at all? 
>> > > > Will you require a demangler to be vended with each new version of the 
>> > > > tool? Are all previous demanglings still valid in newer versions? Can 
>> > > > you figure out the version of the D from a compiled executable so that 
>> > > > you might be able to locate one of 5 different installs of D and 
>> > > > select the right one? Let me know w