Re: [lldb-dev] Adding D language demangling support
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 <
lldb-dev@lists.llvm.org> 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 <
> lldb-dev@lists.llvm.org> 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 <
> lldb-dev@lists.llvm.org> 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 what you use case is.
> > > >
> > > > Greg
> > > >
> > > >
> > > > one simple flexible backward compatible option would be to have a
> generic environment variable:
> > > >
> > > > ```
> > > > export LLDB_DEMANGLER_EXE="/usr/bin/ddemangle"
> > > > lldb myprog
> > > > ```
> > > >
> > > > inside lldb (D-like pseudo code):
> > > >
> > > > ```
> > > > bool demangle(string symbol, string* output){
> > > > auto path=env["LLDB_DEMANGLER_EXE"];
> > > > if(!path.empty) {
> > > > auto demangleCustom=cast(proper_type) dlopen(path);
> > > > if(demangleCustom(symbol, output)) return true;
> > > > // fallsback to default code if custom code didn't handle symbol
> > > > }
> > > > return run_default_lldb_demangle(symbol, output);
> > > > }
> > > > ```
> > > >
> > > > user defined demangler (eg D's demangler)
> > > > ```
> > > > /
[lldb-dev] [Bug 12355] Symbolization does not work with -pie
https://llvm.org/bugs/show_bug.cgi?id=12355 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |INVALID --- Comment #10 from lab...@google.com --- The bug report is old and the test program does not compile anymore. Please refile if the problem still persists (I think it shouldn't as linux support is much better now). -- 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 15719] 'image lookup' and 'frame info' disagree, image lookup is more right
https://llvm.org/bugs/show_bug.cgi?id=15719 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |INVALID --- Comment #2 from lab...@google.com --- Unfortunately, the bug is too old to be actionable right now. -- 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 15036] LLDB is unable to parse DWARF data generated by GCC (4.6)
https://llvm.org/bugs/show_bug.cgi?id=15036 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #8 from lab...@google.com --- I don't know about gcc-4.6, but we certainly handle gcc-4.9 now. -- 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 15591] ASSERT when building record layout for anonymous structures.
https://llvm.org/bugs/show_bug.cgi?id=15591 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #3 from lab...@google.com --- Seems to work fine now. -- 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 15936] LLDB incorrectly unwinds a call stack that contains a function with an illegal instruction
https://llvm.org/bugs/show_bug.cgi?id=15936 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- The test passes with gcc>=4.8. I don't know if 4.6 still fails, but hopefully noone uses that anymore. -- 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 16000] SBBreakpoint::SetCallback() function does not work as expected
https://llvm.org/bugs/show_bug.cgi?id=16000 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #3 from lab...@google.com --- The test seems to pass now. -- 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 17096] Incorrect stop reason data for multiple breakpoints
https://llvm.org/bugs/show_bug.cgi?id=17096 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #3 from lab...@google.com --- Seems to be working now. -- 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 17227] Disassembly is incorrect when using lldb with ELF core files
https://llvm.org/bugs/show_bug.cgi?id=17227 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #3 from lab...@google.com --- Core file debugging is still not perfect, but this should work now. -- 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 17385] registers unavailable in the TestFrames.py inferior stack frames above frame 0
https://llvm.org/bugs/show_bug.cgi?id=17385 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #2 from lab...@google.com --- This should work now. -- 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 17189] Frame variable command isn't working for Go programs
https://llvm.org/bugs/show_bug.cgi?id=17189 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #5 from lab...@google.com --- LLDB has grown Go support since this was filed. Hopefully it's working now (?) -- 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 17628] lldb should support JIT debugging
https://llvm.org/bugs/show_bug.cgi?id=17628 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- This should work now. -- 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 15302] LLDB does not print 'anonymous namespace' prefix for variable names (if inferior built with GCC on Linux)
https://llvm.org/bugs/show_bug.cgi?id=15302 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #6 from lab...@google.com --- Looks like the test passes now. -- 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 18064] Silent tests
https://llvm.org/bugs/show_bug.cgi?id=18064 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- This is already implemented. -- 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 30526] New: deadlock when calling SBThread::GetSelectedFrame
https://llvm.org/bugs/show_bug.cgi?id=30526
Bug ID: 30526
Summary: deadlock when calling SBThread::GetSelectedFrame
Product: lldb
Version: 3.9
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: cc.t...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
I have thread working with lldb events.
void LLDBRunner::eventsThread()
{
while (1)
{
lldb::SBEvent ev;
m_debugData->listener.WaitForEvent(UINT32_MAX, ev);
lldb::SBThread thread = m_debugData->currentProcess.GetSelectedThread();
lldb::SBFrame frame = thread.GetSelectedFrame();
}
}
Sometimes(but not always) this thread hangs up when calling
thread.GetSelectedFrame();
Call stack:
liblldb.dll!llvm::sys::MutexImpl::acquire() Line 41C++
liblldb.dll!llvm::sys::SmartMutex<0>::lock() Line 101C++
liblldb.dll!llvm::sys::SmartScopedLock<0>::SmartScopedLock<0>(llvm::sys::SmartMutex<0>
& m) Line 147C++
liblldb.dll!lldb_private::ProcessWindowsLive::DoReadMemory(unsigned
__int64 vm_addr, void * buf, unsigned int size, lldb_private::Error & error)
Line 704C++
liblldb.dll!lldb_private::Process::ReadMemoryFromInferior(unsigned __int64
addr, void * buf, unsigned int size, lldb_private::Error & error) Line 2506
C++
liblldb.dll!lldb_private::MemoryCache::Read(unsigned __int64 addr, void *
dst, unsigned int dst_len, lldb_private::Error & error) Line 268C++
liblldb.dll!lldb_private::Process::ReadMemory(unsigned __int64 addr, void
* buf, unsigned int size, lldb_private::Error & error) Line 2355C++
liblldb.dll!lldb_private::RegisterContext::ReadRegisterValueFromMemory(const
lldb_private::RegisterInfo * reg_info, unsigned __int64 src_addr, unsigned int
src_len, lldb_private::RegisterValue & reg_value) Line 409C++
liblldb.dll!lldb_private::RegisterContextLLDB::ReadRegisterValueFromRegisterLocation(lldb_private::UnwindLLDB::RegisterLocation
regloc, const lldb_private::RegisterInfo * reg_info,
lldb_private::RegisterValue & value) Line 1083C++
liblldb.dll!lldb_private::RegisterContextLLDB::ReadGPRValue(lldb::RegisterKind
register_kind, unsigned int regnum, unsigned __int64 & value) Line 1919C++
liblldb.dll!lldb_private::RegisterContextLLDB::ReadPC(unsigned __int64 &
pc) Line 2066C++
liblldb.dll!lldb_private::UnwindLLDB::GetOneMoreFrame(lldb_private::ABI *
abi) Line 265C++
liblldb.dll!lldb_private::UnwindLLDB::AddOneMoreFrame(lldb_private::ABI *
abi) Line 357C++
liblldb.dll!lldb_private::UnwindLLDB::UpdateUnwindPlanForFirstFrameIfInvalid(lldb_private::ABI
* abi) Line 332C++
liblldb.dll!lldb_private::UnwindLLDB::AddFirstFrame() Line 118C++
liblldb.dll!lldb_private::UnwindLLDB::DoGetFrameInfoAtIndex(unsigned int
idx, unsigned __int64 & cfa, unsigned __int64 & pc) Line 422C++
liblldb.dll!lldb_private::Unwind::GetFrameInfoAtIndex(unsigned int
frame_idx, unsigned __int64 & cfa, unsigned __int64 & pc) Line 72C++
liblldb.dll!lldb_private::StackFrameList::GetFramesUpTo(unsigned int
end_idx) Line 299C++
liblldb.dll!lldb_private::StackFrameList::GetFrameAtIndex(unsigned int
idx) Line 541C++
liblldb.dll!lldb_private::Thread::GetSelectedFrame() Line 364C++
liblldb.dll!lldb::SBThread::GetSelectedFrame() Line 1471C++
ssl-rt.dll!Debugger::LLDBRunner::checkCurrentFunctionIsOkey() Line 143
C++
ssl-rt.dll!Debugger::LLDBRunner::eventsThread() Line 263C++
--
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 18077] liblldb.so fails to link under GNU/Linux powerpc & mips
https://llvm.org/bugs/show_bug.cgi?id=18077 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #2 from lab...@google.com --- Some mips fixes went in for this. Hopefully that fixed the problem. -- 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 18579] Can't access to anonymous struct and union
https://llvm.org/bugs/show_bug.cgi?id=18579 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- works now. -- 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 18965] Can't debug with gdbserver on Linux with top of tree lldb
https://llvm.org/bugs/show_bug.cgi?id=18965 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #4 from lab...@google.com --- this should work now. -- 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 19248] replace custom unittest2.skipUnless clauses for which we have more specific @attributes
https://llvm.org/bugs/show_bug.cgi?id=19248 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- Decorator is no longer present. -- 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 19245] LLDB commits suicide after failing launch a process twice.
https://llvm.org/bugs/show_bug.cgi?id=19245 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #4 from lab...@google.com --- works now. -- 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 19695] [PATCH] Build fails with swig in non-standard location
https://llvm.org/bugs/show_bug.cgi?id=19695 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- works now. -- 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 19783] lldb doesn't look for symbols in /usr/lib/debug/.build-id/
https://llvm.org/bugs/show_bug.cgi?id=19783 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- This should work now. -- 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 19818] Clean up unused variable warnings in MI code
https://llvm.org/bugs/show_bug.cgi?id=19818 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- appears to be fixed now. -- 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 19826] ObjectContainerBSDArchive::Object::Extract() crashes if extracted file name is exactly 16 characters long
https://llvm.org/bugs/show_bug.cgi?id=19826 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- It seems that file has a check for string::npos now. -- 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 20143] lldb crashes
https://llvm.org/bugs/show_bug.cgi?id=20143 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |INVALID --- Comment #1 from lab...@google.com --- Not enough info to be actionable now. Please re-file if you still have a problem. -- 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 20203] scripts/CMakeLists.txt missing script lldb_python_module.cmake
https://llvm.org/bugs/show_bug.cgi?id=20203 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- That file no longer exists. Hopefully the problem went away with it. -- 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 20233] TestWatchpointMultipleThreads.test_watchpoint_multiple_threads_with_dwarf fails on Linux clang
https://llvm.org/bugs/show_bug.cgi?id=20233 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- Works now. -- 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 20319] Crashes on run with Segmentation Fault
https://llvm.org/bugs/show_bug.cgi?id=20319 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- Should be fixed now. -- 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 20352] test_stop_hook_multiple_threads_with_dwarf hangs on Linux
https://llvm.org/bugs/show_bug.cgi?id=20352 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |DUPLICATE --- Comment #1 from lab...@google.com --- *** This bug has been marked as a duplicate of bug 15037 *** -- 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 20687] lldb segfault on go program
https://llvm.org/bugs/show_bug.cgi?id=20687 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #4 from lab...@google.com --- We should be able to do basic go debugging now. -- 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] Adding D language demangling support
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 what you use case is.
> > > >
> > > > Greg
> > > >
> > > >
> > > > one simple flexible backward compatible option would be to have a
> > > > generic environment variable:
> > > >
> > > > ```
> > > > export LLDB_DEMANGLER_EXE="/usr/bin/ddemangle"
> > > > lldb myprog
> > > > ```
> > > >
> > > > inside lldb (D-like pseudo code):
> > > >
> > > > ```
> > > > bool demangle(string symbol, string* output){
> > > > auto path=env["LLDB_DEMANGLER_EXE"];
> > > > if(!path.empty) {
> > > > auto demangleCustom=cast(proper_type) dlopen(path);
> > > > if(demangleCustom(symbol, output)) return true;
> > > > // fallsback
[lldb-dev] YouTrack e-mails
Dear All, Today some of you received dozen e-mails from YouTrack connected with something which looks like LLVM PRs. Please ignore them and I do apologize that you received them. Here is some background. As you may know we had a lot of problems with Bugzilla recently due to spam activity. Currently we're having user registration disabled and all the users have to be created by hands. Unfortunately, Bugzilla has very poor possibilities for dealing with spam PRs as well as bulk operations, e.g. we simply cannot remove spam PRs without executing SQL statement directly in the mysql console. Currently we're simply evaluating different approaches how to proceed: - Customize bugzilla to add some filtering / captcha / whatever (it seems there is no built-in functionality for this). - Move to some other product, including (but not limited to) to e.g. JIRA, YouTrack, Redmine, Mantis, The second approach regardless of the selected system involves the migration of the whole Bugzilla and this process might have a lot of rough edges. So, recently we started to test whether we could import the whole Bugzilla contents to Youtrack, evaluate the completeness of the data, etc. Accidentally I enabled the e-mail notifications for a moment and this is how all the e-mails were sent. Note that nothing was decided yet, it might be very probable that we'll continue use Bugzilla, we're just evaluating other options and collecting the relevant information. We will try to make sure that there will be no more e-mail notifications without reason. -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] YouTrack e-mails
On 26 September 2016 at 19:12, Anton Korobeynikov via llvm-dev wrote: > Note that nothing was decided yet, it might be very probable that > we'll continue use Bugzilla, we're just evaluating other options and > collecting the relevant information. We will try to make sure that > there will be no more e-mail notifications without reason. Hi Anton, Thanks for the effort of testing new systems! I'm a hard fan of bugzilla (I know, I'm weird), but I'm happy with any other, too, as long as they don't block us more than help. In the end, any future decision will have to be backed by hard data, and testing these other systems as you're doing is the only meaningful way of getting it. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
