similar to: GDB pretty printers for LLVM ADTs

> On Dec 20, 2016, at 9:55 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Dandy :) > > I looked into ways to do this for the GDB visualizers - but was unable to come up with a totally automated solution, unfortunately. I've wanted the same. Best I could think of was to embed them (or a reference to them) in the binary for the debugger to look at.

The VC visualizers are automatcially installed. 2016-12-20 19:45 GMT+02:00 David Blaikie via llvm-dev < llvm-dev at lists.llvm.org>: > Added something in r290186. > > Say, Reid - do you know anything about the MSVC formatters that are also > provided in LLVM? Perhaps you could add a brief bit of documentation about > them, if they need an explicit wiring up (if they just

Dandy :) I looked into ways to do this for the GDB visualizers - but was unable to come up with a totally automated solution, unfortunately. On Tue, Dec 20, 2016 at 9:51 AM Yaron Keren <yaron.keren at gmail.com> wrote: > The VC visualizers are automatcially installed. > > > 2016-12-20 19:45 GMT+02:00 David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org>: >

Added something in r290186. Say, Reid - do you know anything about the MSVC formatters that are also provided in LLVM? Perhaps you could add a brief bit of documentation about them, if they need an explicit wiring up (if they just come for free/automatically - might not be worth documenting, people will find it when they need it) or point this thread to someone who knows about them to provide

I've added a few LLVM GDB pretty printers a while back (& just added llvm::Optional earlier today) & thought people might be interested in how to use them, etc. I use them by adding the following to my .gdbinit: source /path/to/llvm/src/utils/gdb-scripts/prettyprinters.py Also, I can suggest adding: set print pretty on there too, it helps a lot when printing complex nested

Added some basic DenseMap support in r290011 On Fri, Dec 16, 2016 at 2:05 PM David Blaikie <dblaikie at gmail.com> wrote: > I've added a few LLVM GDB pretty printers a while back (& just added > llvm::Optional earlier today) & thought people might be interested in how > to use them, etc. > > I use them by adding the following to my .gdbinit: > > source

Excellent. I think it would make sense to add small section somewhere in documentation (e.g. LLVM Programmer’s Manual <http://llvm.org/docs/ProgrammersManual.html>) about it, so it won't be lost somewhere in the mailing list. Piotr 2016-12-17 1:04 GMT+01:00 David Blaikie via llvm-dev < llvm-dev at lists.llvm.org>: > Added some basic DenseMap support in r290011 > > On

Here are the linker errors: lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_end__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_end__ lld: warning:

Good point - any ideas on where in the programmer's manual would suit best? Looking around I sort of feel like it belongs in the "Picking the right data structure" section - but I fear someone merely examining existing data structures might not think to look there for help in their task (if they have no need to 'pick' a data structure for a new use, etc). On Mon, Dec 19,

I guess adding section "Debugging" at the bottom of programmers manual would sounds like a good plan to me. Piotr 2016-12-20 6:03 GMT+01:00 David Blaikie <dblaikie at gmail.com>: > Good point - any ideas on where in the programmer's manual would suit > best? Looking around I sort of feel like it belongs in the "Picking the > right data structure" section -

Is that the only problem to use lld to link cygwin programs? On Thu, Feb 8, 2018 at 8:19 AM, Andrew Kelley <superjoe30 at gmail.com> wrote: > Here are the linker errors: > > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_start__ > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_end__ > lld: warning:

COFF lld doesn't support the linker script at the moment, and I'm sad to say that it is very unlikely to support that in the future. Linker script support is so huge that I can't imagine we really want it for COFF. GNU BFD linker supports it because the linker is built as an interpreter for the built-in linker script (and that's one of the reasons why GNU linker is by far more

Hello, I have a user who is trying to get LLD to link for the cygwin target: https://github.com/zig-lang/zig/issues/751 Currently the issue they are running into is needing to define a linker script, but the COFF driver (or MinGW driver) does not have support for that. Is there documentation or advice for how to use LLD to link for cygwin? As a starting point, which driver to use? Regards,

A very common code pattern in LLVM is SmallString<128> S; raw_svector_ostream OS(S); OS<< ... Use OS.str() While raw_svector_ostream is smart to share the text buffer itself, it's inefficient keeping two sets of pointers to the same buffer: In SmallString: void *BeginX, *EndX, *CapacityX In raw_ostream: char *OutBufStart, *OutBufEnd, *OutBufCur Moreover, at runtime the

The LLVM Tutorial, https://llvm.org/docs/tutorial/LangImpl01.html provides an excellent introduction to language definition and code generation. I am looking for a similar example that demonstrates how to use SmallString. Even a small test program, ———— #include <llvm/ADT/SmallString.h> int main(int argc, char **argv) { llvm::SmallString<32> str("hello world\n");

Hallo Guys, something went wrong and I didn't know from where. - uninstall vmware (removed to virtual adapter) - reinstall package with route and ping and glibc - test with original kernel and own vanilla nothing helps. Laptop by my side has same software stand no problem at all gdb --args ping benzler.me GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-94.el7 Copyright (C) 2013 Free

Sean, thanks for reminding this, Alp did commit a class derived from raw_svector_ostream conatining an internal SmallString he called small_string_ostream. The commit was reverted after a day due to a disagreement about the commit approval and apparently abandoned. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140623/223393.html

I don't think we should make flush virtual. Why do you need to do it? Can't you set up the base class to write to use the tail of the memory region as the buffer? On 24 April 2015 at 06:46, Yaron Keren <yaron.keren at gmail.com> wrote: > Hi, > > Is this what you're thinking about? > The code is not tested yet, I'd like to know if the overall direction and >

+llvm-dev at lists.llvm.org The impact should be small as all the other streamers usually write directly to the memory buffer and only when out of buffer they call write(). OTOH, raw_svector_ostream (without a buffer) goes though write for every character or block it writes. It can work without virtual write() by overriding the existing virtual write_impl() but this is a slower code path for

Here's a performance testcase for the raw_svector_ostream patch. On my WIndows x64 machine it runs in 1010ms with the current code and in 440ms with the patch applies. Is this OK to commit? 2015-05-02 21:31 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > Following a hint from Duncan in http://llvm.org/pr23395, here is a > revised patch. Rather then introduce the