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

[Johan Engelen via lldb-dev]

It'd be great if an external lib could be used for the demangling.

Zooming out a little:
`Mangled::GetDemangledName(lldb::LanguageType language)` takes a language
as parameter (unused), which to me looks like the plan was to move this
into the language plugins?
Then D could have its own language plugin (possibly dynamically loaded).
The D plugin could then do the dynamic loading of ddemangleCustom.

-Johan

On Thu, Sep 22, 2016 at 1:13 AM, 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?
>
> 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)
> > > ```
> > > // return true if can demangle symbol (ie it's a D symbol in our case)
> > > bool demangleCustom(string symbol, string* output);
> > >
> > > ```
> > >
> > > >> Is the mangling changing at all?
> > >
> > > yes, there's some ongoing work on making the mangling scheme produce
> much shorter symbols. The logic is complex, and it'd be a lot of work to
> reproduce this.
> > >
> > > Bottomline: this scheme is very flexible, and it'd be no less useful
> than current situation, where lldb just returns the symbol unchanged if it
> can't demangle.
> > >
> > >
> > >
> > >
> > > > On Sep 21, 2016, at 3:00 PM, Timothee Cour 
> wrote:
> > > >
> > > > Is there a way to provide a hook (eg, via an extern(C) function, or
> using a dynamically loaded shared library) to do this, so as to simply
> reuse D's https://dlang.org/phobos/std_demangle.html and make sure it's
> always in sync with D's demangling instead of duplicating code
> > > >
> > > > On Wed, Sep 21, 2016 at 10:24 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > > > It might be nice to add demangling support to llvm and then use it
> by modifying "Mangled::GetDemangledName()" in Mangl

[lldb-dev] [Bug 30485] New: lldb assertion "Architecture or OS not supported" when loading Ubuntu core dump

[via lldb-dev]

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

Bug ID: 30485
   Summary: lldb assertion "Architecture or OS not supported" when
loading Ubuntu core dump
   Product: lldb
   Version: 3.9
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: richard_chamberl...@uk.ibm.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Error and log messages:

elf-core::CreateRegisterContextForFrame:: Architecture(27) or OS(0) not
supported
lldb:
/home/rchamberlain/lldb/llvm/tools/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp:146:
virtual lldb::RegisterContextSP
 ThreadElfCore::CreateRegisterContextForFrame(lldb_private::StackFrame*):
Assertion `false && "Architecture or OS not supported"' failed.

Problen seen on lldb trunk version 4.0.0
(http://llvm.org/svn/llvm-project/lldb/trunk revision 281963 clang revision
281963 llvm revision 281963). Also fails on lldb 3.9.0.

The core dump was produced by an Ubuntu 14.04 instance (OS version: Linux
3.19.0-33-generic #38~14.04.1-Ubuntu SMP Fri Nov 6 18:17:28 UTC 2015) running
in IBM Bluemix/Cloud Foundry. Core dumps from Ubuntu running 'on the metal'
work fine. The difference seems to be that the library paths in the ELF notes
section that lldb uses to identify the core dump as Linux have an additional
prefix in the failing case. So the check for a path that starts with
/lib/x86_64-linux-gnu does not work for these core dumps. Relevant lldb code is
here:

Plugins/ObjectFile/ELF/ObjectFileELF.cpp
ObjectFileELF::RefineModuleDetailsFromNote()

  llvm::StringRef path(cstr);
  if (path.startswith("/lib/x86_64-linux-gnu") ||
  path.startswith("/lib/i386-linux-gnu")) {
arch_spec.GetTriple().setOS(llvm::Triple::OSType::Linux);

Notes section in core dump:

~/test$ readelf -n core-node-6-100-1470315046
Displaying notes found at file offset 0x23b0 with length 0x3d14:
  Owner Data sizeDescription
  CORE 0x0150NT_PRSTATUS (prstatus structure)
  CORE 0x0088NT_PRPSINFO (prpsinfo structure)
  CORE 0x0080NT_SIGINFO (siginfo_t data)
  CORE 0x0130NT_AUXV (auxiliary vector)
  CORE 0x17dbNT_FILE (mapped files)
Page size: 4096
 Start End Page Offset
0x0040  0x017bc000  0x
/warden/depot/19p5hmkqpps/tmp/rootfs/home/vcap/app/vendor/node/bin/node
0x019bc000  0x019d5000  0x13bc

/packages/rootfs_cflinuxfs2//lib/x86_64-linux-gnu/libc-2.19.so
0x7fbe4a139000  0x7fbe4a339000  0x01ba
   
/packages/rootfs_cflinuxfs2//rootfs/lib/x86_64-linux-gnu/libc-2.19.so
0x7fbe4a339000  0x7fbe4a33d000  0x01ba
   
/packages/rootfs_cflinuxfs2//rootfs/lib/x86_64-linux-gnu/libc-2.19.so
0x7fbe4a33d000  0x7fbe4a33f000  0x01be


Suggested fix would be to widen the test slightly, e.g.
path.find("/lib/x86_64-linux-gnu") rather than
path.startswith("/lib/x86_64-linux-gnu")

This solution was already hinted at by Ted Woodward here:
http://lists.llvm.org/pipermail/lldb-dev/2016-August/010974.html

Offending core dump(s) available on request.

-- 
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] lldb-3.8.1 prebuilt binary for windows7

[Pavel Labath via lldb-dev]

On 22 September 2016 at 04:51, Chunseok Lee via lldb-dev
 wrote:
> Actually, I am trying to remote-debug from lldb(win host) to
> lldb-server(arm/x64 linux). In my case, The problem is that no
> lldb-sever-4.0 is available(I only have lldb-server 3.8 for arm/x64 linux).
> Q) lldb 4.0 and lldb-server 3.8 are compatible each other?

The gdb-remote protocol is generally backward-compatible, but this
isn't a configuration that we are explicitly testing. I think there is
a good chance that it will work, but if it doesn't you're on your own.
:)

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

Re: [lldb-dev] LLDB Evolution - Final Form

[Pavel Labath via lldb-dev]

I am a bit late to the party, but anyways, here are my thoughts on the
issues here:

On 19 September 2016 at 21:18, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Difficulty / Effort: 3 (5 if we have to add enhanced mode support)
>
> Use llvm streams instead of lldb::StreamString
>
> Supports output re-targeting (stderr, stdout, std::string, etc), printf
> style formatting, and type-safe streaming operators.
>
> Interoperates nicely with many existing llvm utility classes
>
> Risk: 4
>
> Impact: 5
>
> Difficulty / Effort: 7
>
I would also mention the logging infrastructure here. I've been thinking
about how to make that more streamlined, and I plan to come with a
proposal, but I am a bit busy at the moment.


> Port as much as possible to lit
>
> Simple tests should be trivial to port to lit today.  If nothing else this
> serves as a proof of concept while increasing the speed and stability of
the
> test suite, since lit is a more stable harness.
I am afraid that we are still pretty far from a solution that will fit all
use-cases, mostly thinking about the remote-tests here. Part of the reason
for that is that nobody except me and Tamas knows exactly how it works (?).
Please make sure we're included in the design discussions to make sure the
new solution does not lack some basic features we need.

> lldb-unwind - A tool for testing the unwinder.  Accepts byte code as input
> and passes it through to the unwinder, outputting a compressed summary of
> the steps taken while unwinding, which could be pattern matched in lit.
The
> output format is entirely controlled by the tool, and not by the unwinder
> itself, so it would be stable in the face of changes to the underlying
> unwinder.  Could have various options to enable or disable features of the
> unwinder in order to force the unwinder into modes that can be tricky to
> encounter in the wild.
+100
Right now the only way to test the instruction emulation is to make a
program containing some instructions and run it. This means:
- you need to have the hardware capable of running that code
- the tests have high overhead
- it can be hard to tickle the compiler into producing the corner cases you
might want to test (and there's no guarantee that the next version of the
compiler will still produce the corner-case you had in mind)

In theory all you need to test the emulation is to feed it the instruction
stream and check the validate the generated unwind plan.



> Clean up the mess of cyclical dependencies and properly layer the
libraries.
> This is especially important for things like lldb-server that need to link
> in as little as possible, but regardless it leads to a more robust
> architecture, faster build and link times, better testability, and is
> required if we ever want to do a modules build of LLDB
+1

>   • Use llvm::cl for the command line arguments to the
> primary lldb executable.
> >   • Risk: 2
> >   • Impact: 3
> >   • Difficulty / Effort: 4
> Easy and fine to switch over to. We might need to port some getopt_long
> functionality into it if it doesn't handle all of the things that
> getopt_long does. For example arguments and options can be interspersed in
> getopt_long(). You can also terminate your arguments with "--". It accepts
> single dashes for long option names if they don't conflict with short
> options. Many things like this.


At one point I made a CL which does that  .
With the reformat it might be tricky to resurrect, but I think I can still
pull it off. One of the problems there is that will be pretty hard to make
that consistent with the interpreter command line as that one uses getopt
(and we can't make the interpreter use llvm::cl, as that one relies on
global variables). Two solutions I see here are:
- teach llvm::cl to not use global vars - I think that could be pretty
worthwhile, as it has a very nice interface and it would enable it to be
used in more contexts. It still won't exactly match the current getopt()
interface (but I think it comes sufficiently close already, and we don't
have to care about the difference).
- use llvm::opt - it can handle all crazy gcc arguments, so I'm pretty sure
it can be made to work for our use case. However (and precisely because of
that), it is extremely unwieldy. I looked at it for a couple of hours and I
still could not figure out how it's supposed to be used. (but, I guess we
could find someone on the llvm side, who could help us with that).


Part of the problem is just that I think we don't have the tools we need to
> write effective tests.  We have a lot of tests that only work on a
> particular platform, or with a particular language runtime, or all these
> different variables that affect the configurations under which the test
> should pass.  In an ideal world we would be able to test the lion's share
> of the debugger on any platform.  The only thing that's plat

[lldb-dev] [Bug 30488] New: boost::shared_ptr type show as 'element_type *' in GUI mode

[via lldb-dev]

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

Bug ID: 30488
   Summary: boost::shared_ptr type show as 'element_type *' in GUI
mode
   Product: lldb
   Version: 3.6
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: ser...@vlasov.me
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 17333
  --> https://llvm.org/bugs/attachment.cgi?id=17333&action=edit
Example code

In GUI mode I cannot see the real underlying type of the pointer,
it's always printed as 'element_type *', but in command line the real
types are shown. Please see the attached main.cpp to reproduce.

$ g++ -g -Wall -std=c++0x main.cpp -o out
$ lldb ./out
(lldb) b foo
(lldb) r
(lldb) p p.px
(Derived *) $0 = 0x00614c20

However in GUI mode:

┌───
│ ◆─(shared_ptr) p
│ ├─◆─(element_type *) px = 0x00614c20
│ └─◆─(boost::detail::shared_count) pn

-- 
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] Converting global option tables to use ArrayRef

[Greg Clayton via lldb-dev]

That sounds like a good patch. I look forward to seeing it.

> On Sep 21, 2016, at 11:48 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> I have a patch I'd like to submit tomorrow which converts all of the global 
> command option tables from C-style arrays to llvm ArrayRefs.
> 
> Actually they are still declared internally in each translation unit as 
> C-style arrays, but the Option classes are updated so that they return 
> ArrayRefs instead of raw pointers.  Previously there were two strategies:
> 
> 1) Sometimes we'd return a const Option* and have a method on the class 
> called GetNumDefinitions() so you could treat the pointer as an array.
> 
> 2) Other times we'd return a const Option* and expect the caller to iterate 
> until it reached a sentinel entry.
> 
> With the new approach, the two methods are merged and now the 
> GetDefinitions() method only returns an ArrayRef.
> 
> Since this carries with it its length, neither the GetNumDefinitions() method 
> nor the sentinel entry are needed any more.  
> 
> Most of the old code compiled without modification, because ArrayRef can be 
> treated with a similar syntax as arrays, except you'll get a nice assert if 
> you index out of bounds.
> 
> An added bonus is that you can now iterate over them with ranged-based for 
> syntax.
> 
> I can put it up for review if anyone would like, but as it is extremely 
> mechanical there's not really much to see.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
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

[Greg Clayton via lldb-dev]

> On Sep 22, 2016, at 1:48 AM, Johan Engelen  wrote:
> 
> It'd be great if an external lib could be used for the demangling.
> 
> Zooming out a little:
> `Mangled::GetDemangledName(lldb::LanguageType language)` takes a language as 
> parameter (unused), which to me looks like the plan was to move this into the 
> language plugins?

That was added only because pascal uses the Itanium mangling scheme and the 
same mangled name needs to be demangled in different ways. We can move the 
demangling to the language plug-ins at some point, but it has to be a static 
thing. Let me know if you are interested in doing this work and I can guide 
you. Or maybe we can start with D and see if we like the solution we come up 
with and if so move to that.

> Then D could have its own language plugin (possibly dynamically loaded). The 
> D plugin could then do the dynamic loading of ddemangleCustom.

We currently don't expose the lldb_private layer in LLDB to any plugins and 
that is the layer that would be needed. The lldb_private layer isn't really an 
API that we can expose because it is free to change at any time. Our public 
API, anything in the "lldb" namespace, is an API and we don't break it. We 
could try to make these plug-ins at the public layer, but we can't done that 
with anything except command line command plugins.

Greg


> 
> -Johan
> 
> On Thu, Sep 22, 2016 at 1:13 AM, 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?
> 
> 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 to default code if custom code didn't handle symbol
> > >   }
> > >   return run_default_lldb_demangle(symbol, output);
> > > }
> > > ```
> > >
> > > user defined demangler (eg D's demangler)
> > > ```
> > > // return true if can demangle symbol (ie it's a D symbol in our case)
> > > bool demangleCustom(string symbol, string* output);
> > >
> > > ```
> > >
> > > >> Is the man

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

[Timothee Cour via lldb-dev]

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)
> > > ```
> > > // return true if can demangle symbol (ie it's a D symbol in our case)
> > > bool demangleCustom(string symbol, string* output);
> > >
> > > ```
> > >
> > > >> Is the mangling changing at all?
> > >
> > > yes, there's some ongoing work on making the mangling scheme produce
> much shorter symbols. The logic is complex, and it'd be a lot of work to
> reproduce this.
> > >
> > > Bottomline: this scheme is very flexible, and it'd be no less useful
> than current situation, where lldb just returns the symbol unchanged if it
> can't demangle.
> > >
> > >
> > >
> > >
> > > > On Sep 21, 2016, at 3:00 PM, Timothee Cour 
> wrote:
> > > >
> > > > Is there a way to provide a hook (eg, via an extern(C) function, or
> using a dynamically loaded shared library) to do this, so as to simply
> reuse D's https://dlang.org/phobos/std_demangle.html and make sure it's
> always in sync with D's demangling instead of duplicating code
> > > >
> > > > On Wed, Sep 21, 2016 at 10:24 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > > > It might be nice to add demangling support to llvm and then us

Re: [lldb-dev] Converting global option tables to use ArrayRef

[Zachary Turner via lldb-dev]

I put it up for review.  I don't expect anyone to actually review it since
it's quite large and 99% of it is the same exact thing.  I'm running tests
on Linux and Windows right now.  Will also test on Mac if beanz's new lldb
framework thing works out for me.  I'm going to try to commit sometime
after lunch after I confirm all the tests are passing.

On Thu, Sep 22, 2016 at 9:33 AM Greg Clayton  wrote:

> That sounds like a good patch. I look forward to seeing it.
>
> > On Sep 21, 2016, at 11:48 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > I have a patch I'd like to submit tomorrow which converts all of the
> global command option tables from C-style arrays to llvm ArrayRefs.
> >
> > Actually they are still declared internally in each translation unit as
> C-style arrays, but the Option classes are updated so that they return
> ArrayRefs instead of raw pointers.  Previously there were two strategies:
> >
> > 1) Sometimes we'd return a const Option* and have a method on the class
> called GetNumDefinitions() so you could treat the pointer as an array.
> >
> > 2) Other times we'd return a const Option* and expect the caller to
> iterate until it reached a sentinel entry.
> >
> > With the new approach, the two methods are merged and now the
> GetDefinitions() method only returns an ArrayRef.
> >
> > Since this carries with it its length, neither the GetNumDefinitions()
> method nor the sentinel entry are needed any more.
> >
> > Most of the old code compiled without modification, because ArrayRef can
> be treated with a similar syntax as arrays, except you'll get a nice assert
> if you index out of bounds.
> >
> > An added bonus is that you can now iterate over them with ranged-based
> for syntax.
> >
> > I can put it up for review if anyone would like, but as it is extremely
> mechanical there's not really much to see.
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
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

[Greg Clayton via lldb-dev]

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 to default code if custom code didn't handle symbol
> > >   }
> > >   return run_default_lldb_demangle(symbol, output);
> > > }
> > > ```
> > >
> > > user defined demangler (eg D's demangler)
> > > ```
> > > // return true if can demangle symbol (ie it's a D symbol in our case)
> > > bool demangleCustom(string symbol, string* output);
> > >
> > > ```
> > >
> > > >> Is the mangling changing at all?
> > >
> > > yes, there's some ongoing work on making the mangling scheme produce much 
> > > shorter symbols. The logic is complex, and it'd be a lot of work to 
> > > reproduce this.
> > >
> > > Bottomline: this scheme is very flexible, and it'd be no less usefu

[lldb-dev] [Bug 30492] New: On Linux, lldb lit tests fail

[via lldb-dev]

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

Bug ID: 30492
   Summary: On Linux, lldb lit tests fail
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: hfin...@anl.gov
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

I needed the following changes to make the lldb lit tests work on my Linux
build system:

diff --git a/lit/Expr/TestCallStopAndContinue.test
b/lit/Expr/TestCallStopAndContinue.test
index f518f3d..263fa2a 100644
--- a/lit/Expr/TestCallStopAndContinue.test
+++ b/lit/Expr/TestCallStopAndContinue.test
@@ -9,4 +9,4 @@ breakpoint set --file call-function.cpp --line 14
 expression -i false -- returnsFive()
 # CHECK: Execution was interrupted, reason: breakpoint
 # CHECK: stop reason = User Expression thread plan
-# CHECK: Completed expression: (Five) $0 = (number = 5 {{.*}}, name = "five")
+# CHECK: Completed expression: (Five) $0 = (number = 5{{.*}}, name = "five")
diff --git a/lit/lit.cfg b/lit/lit.cfg
index e18719b..fe00344 100644
--- a/lit/lit.cfg
+++ b/lit/lit.cfg
@@ -140,7 +140,9 @@ config.substitutions.append(('%cc', config.cc))
 config.substitutions.append(('%cxx', config.cxx))

 config.substitutions.append(('%lldb', lldb))
-config.substitutions.append(('%debugserver', debugserver))
+
+if debugserver is not None:
+  config.substitutions.append(('%debugserver', debugserver))

 for pattern in [r"\bFileCheck\b",
 r"\| \bnot\b"]:


For the second change, the problem is that, on Linux, there is no "debugserver"
process, and the RUN-line substitution will fail if you try to substitute
'%debugserver' with None. For the first change, I don't know why there would be
a space after the 5 on any system.

-- 
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] lldb-3.8.1 prebuilt binary for windows7

[Chunseok Lee via lldb-dev]

Thank you for kind help. 
It seems to work nicely(from lldb4.0(win) to lldbserver3.8) for me. 

나의 iPhone에서 보냄

2016. 9. 22. 오후 7:45 Pavel Labath  작성:

> On 22 September 2016 at 04:51, Chunseok Lee via lldb-dev
>  wrote:
>> Actually, I am trying to remote-debug from lldb(win host) to
>> lldb-server(arm/x64 linux). In my case, The problem is that no
>> lldb-sever-4.0 is available(I only have lldb-server 3.8 for arm/x64 linux).
>> Q) lldb 4.0 and lldb-server 3.8 are compatible each other?
> 
> The gdb-remote protocol is generally backward-compatible, but this
> isn't a configuration that we are explicitly testing. I think there is
> a good chance that it will work, but if it doesn't you're on your own.
> :)
> 
> pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] MI command for connecting remote target

[Chunseok Lee via lldb-dev]

Is there any MI command for connecting remote target ?

Using platform and target command with lldb, It works fine as follows:

-host log--
twoflower@js1-desktop ~/local-hello> ls
a.out*  hello.cpp
twoflower@js1-desktop ~/local-hello> lldb-3.8.1
(lldb) platform select remote-linux
  Platform: remote-linux
 Connected: no
(lldb) platform connect connect://10.113.62.251:1234
  Platform: remote-linux
Triple: x86_64-*-linux-gnu
OS Version: 3.19.0 (3.19.0-32-generic)
Kernel: #37~14.04.1-Ubuntu SMP Thu Oct 22 09:41:40 UTC 2015
  Hostname: twoflower
 Connected: yes
WorkingDir: /home/twoflower/remote-hello
(lldb) target create -r /home/twoflower/remote-hello/a.out a.out
Current executable set to 'a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main, address = 0x0040052d
(lldb) r
Process 14524 launched:
'/home/twoflower/.lldb/module_cache/remote-linux/.cache/BB42308F-4677-5DC0-AFC2-097CDFE91A83-3612C4F8/a.out'
(x86_64)
Process 14524 stopped
* thread #1: tid = 14524, 0x0040052d a.out`main, name = 'a.out',
stop reason = breakpoint 1.1
frame #0: 0x0040052d a.out`main
a.out`main:
->  0x40052d <+0>: pushq  %rbp
0x40052e <+1>: movq   %rsp, %rbp
0x400531 <+4>: movl   $0x4005d4, %edi   ; imm = 0x4005D4
0x400536 <+9>: movl   $0x0, %eax
(lldb) c
Process 14524 resuming
Process 14524 exited with status = 0 (0x)
(lldb) q
twoflower@js1-desktop ~/local-hello>

--remote log ---
twoflower@twoflower ~/remote-hello> ls
a.out*  hello.cpp
twoflower@twoflower ~/remote-hello> lldb-server-3.8 p --listen "*:1234"
Connection established.
error: lost connection
lldb-server exiting...

--

However, when I try the same thing with lldb-mi, I cannot connect to remote
target as follows:

--- host log 
twoflower@js1-desktop ~/local-hello> lldb-mi-3.8.1
(gdb)
-target-select remote 10.113.62.251:1234
^error,msg="Command 'target-select'. Current SBTarget is invalid"
(gdb)

--  remote log --
twoflower@twoflower ~/remote-hello> lldb-server-3.8 p --listen "*:1234"

The remote side seems not to receive any msg at all.
I am not sure that it is proper use for -target-select command.

BR,
Chunseok Lee

-- 
Where Do We come from? What Are We? Where Are We Going?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] MI command for connecting remote target

[Vadim Macagon via lldb-dev]

You need to specify the executable to debug before attempting to connect 
to the remote machine:



lldb-mi --interpreter


-file-exec-and-symbols local/path/to/executable
-target-select remote host:port

Note that the file-exec-and-symbols command has some non-standard 
extensions in LLDB-MI that are documented in 



On 23/09/2016 7:07 AM, Chunseok Lee via lldb-dev wrote:
However, when I try the same thing with lldb-mi, I cannot connect to 
remote target as follows:


--- host log 
twoflower@js1-desktop ~/local-hello> lldb-mi-3.8.1
(gdb)
-target-select remote 10.113.62.251:1234 
^error,msg="Command 'target-select'. Current SBTarget is invalid"
(gdb)

--  remote log --
twoflower@twoflower ~/remote-hello> lldb-server-3.8 p --listen "*:1234"

The remote side seems not to receive any msg at all.
I am not sure that it is proper use for -target-select command.

BR,
Chunseok Lee




On 23/09/2016 7:07 AM, Chunseok Lee via lldb-dev wrote:

Is there any MI command for connecting remote target ?

Using platform and target command with lldb, It works fine as follows:

-host log--
twoflower@js1-desktop ~/local-hello> ls
a.out*  hello.cpp
twoflower@js1-desktop ~/local-hello> lldb-3.8.1
(lldb) platform select remote-linux
  Platform: remote-linux
 Connected: no
(lldb) platform connect connect://10.113.62.251:1234 


  Platform: remote-linux
Triple: x86_64-*-linux-gnu
OS Version: 3.19.0 (3.19.0-32-generic)
Kernel: #37~14.04.1-Ubuntu SMP Thu Oct 22 09:41:40 UTC 2015
  Hostname: twoflower
 Connected: yes
WorkingDir: /home/twoflower/remote-hello
(lldb) target create -r /home/twoflower/remote-hello/a.out a.out
Current executable set to 'a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main, address = 0x0040052d
(lldb) r
Process 14524 launched: 
'/home/twoflower/.lldb/module_cache/remote-linux/.cache/BB42308F-4677-5DC0-AFC2-097CDFE91A83-3612C4F8/a.out' 
(x86_64)

Process 14524 stopped
* thread #1: tid = 14524, 0x0040052d a.out`main, name = 
'a.out', stop reason = breakpoint 1.1

frame #0: 0x0040052d a.out`main
a.out`main:
->  0x40052d <+0>: pushq  %rbp
0x40052e <+1>: movq   %rsp, %rbp
0x400531 <+4>: movl   $0x4005d4, %edi   ; imm = 0x4005D4
0x400536 <+9>: movl   $0x0, %eax
(lldb) c
Process 14524 resuming
Process 14524 exited with status = 0 (0x)
(lldb) q
twoflower@js1-desktop ~/local-hello>

--remote log ---
twoflower@twoflower ~/remote-hello> ls
a.out*  hello.cpp
twoflower@twoflower ~/remote-hello> lldb-server-3.8 p --listen "*:1234"
Connection established.
error: lost connection
lldb-server exiting...

--

However, when I try the same thing with lldb-mi, I cannot connect to 
remote target as follows:


--- host log 
twoflower@js1-desktop ~/local-hello> lldb-mi-3.8.1
(gdb)
-target-select remote 10.113.62.251:1234 
^error,msg="Command 'target-select'. Current SBTarget is invalid"
(gdb)

--  remote log --
twoflower@twoflower ~/remote-hello> lldb-server-3.8 p --listen "*:1234"

The remote side seems not to receive any msg at all.
I am not sure that it is proper use for -target-select command.

BR,
Chunseok Lee

--
Where Do We come from? What Are We? Where Are We Going?


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



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