Re: [lldb-dev] LLDB build at windows

ms. > > > On 11/01/2016 18:48, Zachary Turner via lldb-dev wrote: > > Yea, unfortunately the way things work is that the person who is affected > by the problem and who needs it fixed is usually the one that needs to fix > it. Right now we don't have any Windows people buil

Re: [lldb-dev] [llvm-dev] [Attn: Bot Owners!] Raising CMake minimum version to 3.4.3

Windows LLDB is done On Thu, May 26, 2016 at 2:39 AM Daniel Sanders via lldb-dev < lldb-dev@lists.llvm.org> wrote: > All the MIPS buildbots are ready too. > > > > *From:* llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] *On Behalf Of > *NAKAMURA > Takumi via llvm-dev > *Sent:* 25 May 2016

Re: [lldb-dev] LLDB build at windows

Yea, unfortunately the way things work is that the person who is affected by the problem and who needs it fixed is usually the one that needs to fix it. Right now we don't have any Windows people building inside Visual Studio, so nobody has fixed that. But you're welcome to submit a patch :)

Re: [lldb-dev] LLDB build at windows

I have never built with -DLLVM_INCLUDE_TESTS=OFF -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF before, so that could be related. Can you try removing those options on CMake to see if that fixes it? The other thing I do differently is I use ninja generator. So I use -G Ninja instead of

Re: [lldb-dev] lldb tests and tear down hooks

There's no reason a finally block inside each test method wouldn't work, and that's probably the simplest solution. On Fri, Jan 15, 2016 at 12:59 AM Pavel Labath <lab...@google.com> wrote: > On 14 January 2016 at 21:52, Zachary Turner via lldb-dev > <lldb-dev@lists.llvm.org>

Re: [lldb-dev] LLDB build at windows

When we move to VS 2015 (which will be soon, btw) we will require Python 3.5+ on Windows. This already works for the most part, you can even try it out today. I've spent the better part of the past 6 months making LLDB's python bindings work with Python 3. The best part is that you don't need

Re: [lldb-dev] lldb tests and tear down hooks

and you can just push "self.foo" --- that > cleanup hook pushed on most tests at the end of the file is a perfect > example of an unneeded level of lambda indirection). > > On Wed, Oct 21, 2015 at 12:04 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org>

Re: [lldb-dev] Status of prettyprint via MI

I can think of two problems with this scenario. First, it depends what implementation of STL you're using. If you're using clang-cl or MSVC to compile your program, then you're getting the MSVC STL, and we don't have any data formatters implemented for those yet. It will happen eventually, but

Re: [lldb-dev] Making a new symbol provider

On Fri, Feb 12, 2016 at 9:41 AM Greg Clayton <gclay...@apple.com> wrote: > > > On Feb 11, 2016, at 6:56 PM, Zachary Turner <ztur...@google.com> wrote: > > > > > > > > On Thu, Feb 11, 2016 at 5:35 PM Greg Clayton <gclay...@apple.com> wrote: > &

Re: [lldb-dev] Making a new symbol provider

On Thu, Feb 11, 2016 at 5:35 PM Greg Clayton wrote: > > > 5. ParseCompileUnitLineTable. On the LineTable class you can add "line > sequences" or individual entries. What's the difference here? Is there > any disadvantage to adding every single line entry in the line table

Re: [lldb-dev] Running a single test

Try passing the directory to start in as the last argument. Also make sure you include .py on the filename when using -p (I don't actually know if this is required but I do it). % python dotest.py --executable /tank/emaste/src/llvm/build-nodebug/bin/lldb -C /usr/bin/clang -v -t -p

Re: [lldb-dev] Making a new symbol provider

On Thu, Feb 11, 2016 at 5:35 PM Greg Clayton <gclay...@apple.com> wrote: > > > On Feb 11, 2016, at 3:41 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hi, > > > > I want to make a new symbol provider to teach LLDB

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

your bot isn't actually doing anything > differently > > than my bot [http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015 > ]. > > If you want you could just remove your bot. If you want to keep it, then > > yea getting it on VS2015 and Python 3 would be the best idea. > >

Re: [lldb-dev] Question about TestMultipleDebuggers.py

Ahh yea I missed that. Makes sense On Mon, Feb 8, 2016 at 2:38 PM Siva Chandra wrote: > On Mon, Feb 8, 2016 at 2:35 PM, Zachary Turner wrote: > > > > > > On Mon, Feb 8, 2016 at 2:21 PM Siva Chandra > wrote: > >> > >> On Mon,

Re: [lldb-dev] Question about TestMultipleDebuggers.py

han...@google.com> wrote: > On Mon, Feb 8, 2016 at 1:36 PM, Zachary Turner via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > Why is this marked @skipIfI386? I don't see anything i386 specific about > > this test. Can this decorator be removed? > > I think skipping for

Re: [lldb-dev] something just toasted the test suite on OS X

Humm.. it's a unicode literal, not sure why it's complaining. I guess I'll have to crack open my linux machine and see what's going on tomorrow. On Tue, Jan 26, 2016 at 6:12 PM Todd Fiala wrote: > I'm still getting a lot of these: > > > Traceback (most recent call last):

Re: [lldb-dev] something just toasted the test suite on OS X

sorry, yea I stuck around for a while after that patch waiting for emails, but nothing came through. Please revert in the meantime, I'll work on a fix tomorrow. On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I think I see what happened w/r/t why no

Re: [lldb-dev] something just toasted the test suite on OS X

No worries, worst case scenario a sledgehammer solution is to change all the places where we write to the session file to convert to unicode first (which would be a trivial conversion, since everything is going to be ascii, which is already valid utf 8). The reason a problem arose at all is

[lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

As of this week, we have the test suite running clean under MSVC 2015 using Python 3.5. I'm sure new things will pop up, but I'm considering the transition "done" as of now. What this means for MSVC 2013 is that we dont' want to support it anymore. Reasons: * C++ language support is poor *

[lldb-dev] Problem running the test suite on Linux.

On Linux I get the following test results: UNEXPECTED SUCCESS: test_and_run_command_dwarf (lang/c/const_variables/TestConstVariables.py) UNEXPECTED SUCCESS: test_and_run_command_dwo (lang/c/const_variables/TestConstVariables.py) UNEXPECTED SUCCESS: test_command_script_immediate_output_dwarf

Re: [lldb-dev] Problems with core load on Linux and proposed solution

Cced some people who work on Linux. Not sure how this slipped through the cracks, but sometimes you can have better results by just posting a patch to lldb-commits and ccing the right person (check owners file to find out who the right person is) On Thu, Feb 25, 2016 at 5:18 PM Eugene Birukov

Re: [lldb-dev] clang-format now supports return type on separate line

Oh neat, I didn't know about that. I'll play around with that when I have some time and see how the behavior works with respect to git clang-format (which formats diffs instead of entire files) On Fri, Jan 22, 2016 at 12:29 PM Pavel Labath wrote: > Apparently, you can also

Re: [lldb-dev] lldb status at windows

When you compile, you need to use -fuse-ld=lld. Most people miss this step. That said, it's not supposed to hang, but it is supposed to not work. What's the command line you used with clang? On Fri, Jan 22, 2016 at 11:08 AM Red Skotina wrote: > Look like I miss

Re: [lldb-dev] lldb status at windows

Ahh you probably need to add -g to clang, otherwise it's not generating debug info. I've never tried debugging a binary with no debug info. Obviously it shouldn't hang, but either way it's just not something we've tested on Windows. On Sat, Jan 23, 2016 at 12:51 AM Red Skotina

Re: [lldb-dev] lldb status at windows

I'm out of office until Monday, but I'll try to reproduce this then and update. Never seen a hang before, so I wonder if there's something different about your machine that we haven't thought of or taken into account. Either way I'll update Monday. On Sat, Jan 23, 2016 at 12:57 AM Red Skotina

Re: [lldb-dev] something just toasted the test suite on OS X

Bump. Can I re-submit this? On Tue, Jan 26, 2016 at 10:54 AM Zachary Turner wrote: > Can one of you guys try out this patch and see if it works? If so I'll > commit it. > > I don't know of a way to make this "elegant". i.e. a single syntax / > paradigm that works in both

Re: [lldb-dev] clang-format now supports return type on separate line

On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan wrote: > I tend to agree with Zachary on the overall principle – and I would be > willing to clang-format functions when I modify them. I’m concerned about > a specific class of functions, though. Let’s say I have a function

Re: [lldb-dev] clang-format now supports return type on separate line

By the way, one place where you are guaranteed to get undesirable results is where you have a large array formatted so that the columns line up. Like in our options tables in the CommandObjects. If you're using git, one way to avoid having clang-format touch these files is to commit that file by

Re: [lldb-dev] Interest in enabling -Werror by default

You're talking about doing it on a per-bot basis and not a global policy, but just throwing in that on the MSVC side at least, we're not warning free right now and it's not trivial tog et warning free without disabling some warnings (which I don't want to do either) On Tue, Feb 16, 2016 at 10:31

Re: [lldb-dev] Details on rdar://18684408?

Does not work on Windows yet, so please leave it xfail'ed on windows for now On Thu, Feb 18, 2016 at 11:30 AM Sean Callanan via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I apologize for this confusion. I recently fixed these as a side effect > of some major changes in IRForTarget.cpp. >

Re: [lldb-dev] Making a new symbol provider

We do know the last line of a function. In the review i posted, you can see the condition where i set is_epilogue to true. That is the last line of a function corresponding to the } (although the function may contain additional bytes, since that only refers to the first byte of the epilogue. But

Re: [lldb-dev] Making a new symbol provider

On Mon, Feb 29, 2016 at 5:49 PM Zachary Turner wrote: > Those are addresses. Here's the situation I was encountering this on: > > // foo.h > #include "bar.h" > inline int f(int n) > { > return g(n) + 1; > } > > // bar.h > inline int g(int n) > { > return n+1; > } > >

Re: [lldb-dev] SymbolFile::FindGlobalVariables

It looks like i need to get type information working before variables, so I'll work on that first and come back to this On Fri, Mar 11, 2016 at 5:05 PM Greg Clayton wrote: > > > On Mar 11, 2016, at 1:02 PM, Zachary Turner wrote: > > > > How large of a

Re: [lldb-dev] SymbolFile::FindGlobalVariables

Bleh, it looks like some abstraction will be needed at this level too, because ClangASTContext assumes a DWARFASTParser. This doesn't seem too bad, because the only code that actually assumes it's a DWARFASTParser is in SymbolFileDWARF. So maybe creating a DebugInfoASTParser in lldb/Symbol and

Re: [lldb-dev] SymbolFile::FindGlobalVariables

and had the added benefit that > if you did your DWARF then you don't have to transcode. > > Jim > > > On Mar 11, 2016, at 11:32 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Also why does the lldb_private::Variable() class

Re: [lldb-dev] SymbolFile::FindGlobalVariables

r email. You can abstract this, but it doesn't seem worth it > unless PDB has some really powerful way to express variable locations? > > > On Mar 11, 2016, at 11:39 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Can we abstract this somehow? Conver

Re: [lldb-dev] exception "leaks" to debugger for win32

FWIW all the debuggers that people normally use on windows show it this way as well. The reason is that by default, if you do nothing and simply launch a program under a debugger, you hit a breakpoint. There's no way to avoid it, it's done by the loader at the OS level. If someone doesn't want

Re: [lldb-dev] Is it ok to use lldb_private from the driver?

interfaces (command line or gui) using >> the SB API’s, so it would be good if we stuck to that discipline as well. >> >> I thought that the lldm-mi was pure SB API’s. That seemed a virtue to me. >> >> Jim >> >> > On Mar 18, 2016, at 9:54 AM, Zachary Turner via

Re: [lldb-dev] SymbolFile::FindGlobalVariables

Also why does the lldb_private::Variable() class take a DWARFExpression to its constructor? Seems like this is wrong in the face of non-DWARF debug information. On Fri, Mar 11, 2016 at 11:02 AM Zachary Turner wrote: > I'm trying to implement this function for PDB. There

[lldb-dev] SymbolFile::FindGlobalVariables

I'm trying to implement this function for PDB. There are two overloads: uint32_t FindGlobalVariables (const ConstString , const CompilerDeclContext *parent_decl_ctx, bool append, uint32_t max_matches, VariableList& variables) uint32_t FindGlobalVariables(const RegularExpression& regex, bool

Re: [lldb-dev] Help debugging OSX build error

And btw, to get the obvious out of the way, I do have swig installed, and "which swig" finds it in /opt/local/bin/swig On Mon, Mar 28, 2016 at 12:48 PM Zachary Turner wrote: > Trying to get an Xcode build working, and I keep getting this error: > > ERROR:root:Unable to find

[lldb-dev] Help debugging OSX build error

Trying to get an Xcode build working, and I keep getting this error: ERROR:root:Unable to find swig executable: 'module' object has no attribute 'OSError' Command /bin/sh failed with exit code 250 Does anyone know how to diagnose this? There's no other useful information in the log file. I

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

r, Inc. > >> > >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > >> a Linux Foundation Collaborative Project > >> > >> > >> > >> From: Zachary Turner [mailto:ztur...@google.com] > >> Sent: Tuesday,

[lldb-dev] Is it ok to use lldb_private from the driver?

I notice everything uses SB classes only. Is this a hard requirement? We have a bit of cruft in all of the top-level executables (lldb-server, lldb-mi, lldb) that could be shared if we could move it into Host, but then the 3 drivers would have to #include "lldb/Host/Host.h". Note that lldb-mi

Re: [lldb-dev] Is it ok to use lldb_private from the driver?

aces (command line or gui) using the > SB API’s, so it would be good if we stuck to that discipline as well. > > I thought that the lldm-mi was pure SB API’s. That seemed a virtue to me. > > Jim > > > On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev < > lldb-dev@li

Re: [lldb-dev] SymbolFile::FindGlobalVariables

Hi Greg, could you clarify the difference between the functions ParseTypes, FindTypes, ResolveTypeUID, and CompleteType from the SymbolFile plugin? On Mon, Mar 14, 2016 at 1:33 PM Zachary Turner wrote: > Bleh, it looks like some abstraction will be needed at this level too,

Re: [lldb-dev] exception "leaks" to debugger for win32

Are you launching the process with -s (stop at entry)? On Fri, Mar 18, 2016 at 11:24 AM Carlo Kok via lldb-dev < lldb-dev@lists.llvm.org> wrote: > When starting a process on Win32 there's an internal exception > (breakpint) that leaks to the debug caller: > s 'Exception 0x8003

Re: [lldb-dev] Is it ok to use lldb_private from the driver?

eady IIUC). It would be > great if any API added here did not preclude this. > > > > > On 18 March 2016 at 17:44, Greg Clayton via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > > >> On Mar 18, 2016, at 10:20 AM, Zachary Turner via lldb-dev < > lldb-d

Re: [lldb-dev] Windows lldb prompt issue

This has been a longstanding issue which I just haven't been able to prioritize over things such as PDB support, minidump support, test fixes, etc. There's various thread synchronization stuff that happens between the IOHandler thread and the debugger thread, and I guess there's a race condition

Re: [lldb-dev] FYI: a python crash running tests

Hi Ted, any chance this is your recent change? I know you had some changes in this file recently On Wed, Mar 2, 2016 at 4:46 PM Adrian McCarthy wrote: > Running ninja check-lldb now has one crash in a Python process, due to > deferencing a null pointer in

Re: [lldb-dev] Question about building line tables

? On Mon, Mar 7, 2016 at 3:13 PM Greg Clayton <gclay...@apple.com> wrote: > > > On Mar 7, 2016, at 3:07 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > This discussion originally started on a code review thread, but I > figured I wou

[lldb-dev] Question about building line tables

This discussion originally started on a code review thread, but I figured I would continue it here since the patch has landed and I want to do more work as a followup. So LLDB's LineTable data structures have the notion of a "terminal entry". As I understand it, LineTables are structured as a

Re: [lldb-dev] Question about building line tables

Let's suppose I've got this function (ignore the operands to branch instructions, I disassembled a real function and just manually adjusted addresses on the left side only just to create a contrived example). infinite-dwarf.exe`main at infinite.cpp:5 4 5int main(int argc, char **argv) {

Re: [lldb-dev] break on exceptions/windows

Not possible currently, although it wouldn't be too hard to add. Would be a welcome feature if you are interested On Mon, Apr 4, 2016 at 2:05 AM Carlo Kok via lldb-dev < lldb-dev@lists.llvm.org> wrote: > How do I break on (first chance) exceptions on Windows? > > -- > Carlo Kok > RemObjects

Re: [lldb-dev] LLDB /w Windows and MinGW64

I'm the main Windows maintainer, and while We've gotten things working pretty well on Windows, our effort has been 100% on building with msvc and/or clang-cl. Building with mingw has a different set of pre processor defines and some other subtle differences, so it doesn't surprise me that things

Re: [lldb-dev] LLDB /w Windows and MinGW64

Patches welcome. If you can split it into independent pieces that would be helpful, but it's not always possible. The NativeProcessProtocol error, that's the interface that converts debugging events that occur on the inferior into packets that can be sent to the server, and vice versa. Since

Re: [lldb-dev] LLDB /w Windows and MinGW64

For the patch, can you create an account on reviews.llvm.org, and upload your patch there? This makes interactive reviewing / commenting much easier. Let me know if you need help getting that set up. On Mon, Mar 28, 2016 at 10:58 AM Zachary Turner wrote: > If you compile

Re: [lldb-dev] LLDB /w Windows and MinGW64

If you compile with MSVC or Clang-cl it wouldn't ask for lldb-server. So most likely there is some code that is using #if defined(_MSC_VER) when it should be using #if defined(LLVM_ON_WINDOWS). You'll have to hunt that down, but a good starting point might be to put a breakpoint in

Re: [lldb-dev] break on exceptions/windows

Take a look at ProcessWindowsLive.cpp in Plugins/Process/Windows. There's a function called ProcessWindowsLive::OnDebugException. If you're working in a fork and you don't intend to upstream any changes, you could just modify the default case of the switch statement there to not return

Re: [lldb-dev] break on exceptions/windows

ception you are talking about here, but at > least from a command interface standpoint, it would be good to keep alike > things that actually are alike, but only if they ARE actually alike. > > > > Jim > > > > > On Apr 4, 2016, at 10:07 AM, Greg Clayton <gclay...

Re: [lldb-dev] break on exceptions/windows

Calling everything "catch" is a bit too much of a catch-all though (excuse the pun). I like the idea of every command being able to have a platform specific sub command, similar to gregs suggested "platform break set". But I think you need a way to make commands themselves platform specific so

Re: [lldb-dev] LLDB /w Windows and MinGW64

Almost, there's one more step. Click Create a New Revision on that screen, then give it a title and a description. For reviewers put zturner, and for subscribers put lldb-commits On Mon, Mar 28, 2016 at 11:20 AM Eran Ifrah wrote: > Is this what you meant: >

Re: [lldb-dev] Windows lldb prompt issue

Yea Windows does have methods for doing this, it's just windows specific as you said and requires someone to actually do it. On Mon, Mar 21, 2016 at 1:50 PM Greg Clayton wrote: > You might see if there is some way to implement an equivalent of > IOHandlerEditline that works

Re: [lldb-dev] LLDB /w Windows and MinGW64

I will have another look tomorrow. On Thu, Mar 31, 2016 at 11:56 AM Eran Ifrah wrote: > Ping... > > On Mon, Mar 28, 2016 at 10:19 PM, Eran Ifrah wrote: > >> Sorry, the current status is that lldb-server is no longer needed, >> however the debuggee

Re: [lldb-dev] netbsd7 buildbot broken

There's no CMake change in any of these patches. It looks like something is wrong with your bot. On Tue, May 24, 2016 at 5:14 PM Kamil Rytarowski via lldb-dev < lldb-dev@lists.llvm.org> wrote: > http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd7/builds/4296 > > It looks like after this

Re: [lldb-dev] How to link lldb on i386

cross building on a 64-bit machine using a 64-bit toolchain is what we have to do on Windows. On Mon, May 23, 2016 at 2:21 PM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Don't generate debug info would be one that comes to mind. The other is to > cross build for i386 on a 64

Re: [lldb-dev] All windows Mutex objects are recursive???

Yes, eventually we should move to std::mutex and std::condition_variable, in which case it behaves as expected (std::mutex is non recursive, std::mutex is recursive). On Wed, May 11, 2016 at 2:20 PM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > From

Re: [lldb-dev] All windows Mutex objects are recursive???

I mean std::recursive_mutex is recursive On Wed, May 11, 2016 at 3:01 PM Zachary Turner wrote: > Yes, eventually we should move to std::mutex and std::condition_variable, > in which case it behaves as expected (std::mutex is non recursive, > std::mutex is recursive). > > > >

[lldb-dev] Enabling tests on the Windows LLVM buildbot

Hi all, I'm going to be submitting a change shortly to enable "ninja check-lldb" on the upstream Windows lldb buildbot. For now this is an experiment to see how well this will go, but I would eventually like this to become permanent. As with build breakages, the bot needs to stay green, so

Re: [lldb-dev] Push work-in-progress plugin for Process NetBSD?

I think it's fine, but I'll let others comment on that too. But i will say, if you do this, please make sure it's clang-formatted. On Thu, May 12, 2016 at 6:23 PM Kamil Rytarowski via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I keep locally almost 5k lines of code of the process plugin for

Re: [lldb-dev] Listing memory regions in lldb

On Intel processors, the best way to do this is probably going to be to walk the page directory (see Intel processor manuals). Assuming someone implements this command in lldb, I hope it can be done in such a way as to allow different implementations when one os/architecture has a better way of

Re: [lldb-dev] Redundant six.py copy

Six isn't a module that is normally installed. I think the pythonic way to do this is tell people "you need to install six before you can use lldb", but given the number of different ways in which people use it and the different needs, this isn't ideal. There are no plans to drop support for 2.7,

Re: [lldb-dev] Debugging win64 from 32bits

No, there is no such thing currently. You can build an x64 lldb, it should work in theory but it's not well tested. If you want to port llgs to Windows that would be great :) On Tue, Apr 19, 2016 at 7:40 AM Carlo Kok via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi, > > Is there a good way to

Re: [lldb-dev] LLDB Evolution

Can we fix this by putting a .clang-format style file in the tests/ folder that disables comment formatting? The sledgehammer approach would be CommentPragmas: .* But we can probably do it with a combination of more targeted options too On Thu, Aug 11, 2016 at 8:26 AM Christian Convey

Re: [lldb-dev] LLDB Evolution

It's not possible. The problem is that lldb was dependent on order of includes because each header wasn't properly including what it used. So when clang-format reordered this, things broke On Thu, Aug 11, 2016 at 8:04 AM Christian Convey via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi Pavel,

Re: [lldb-dev] LLDB Evolution

Yea, if you see above, I mentioned that clang-format has a style option called CommentPragmas, which allows you to specify a regex for comments that clang-format won't touch. If you specified CommentPragmas: .* then it would never touch any comment no matter what. (Note that I haven't actually

Re: [lldb-dev] LLDB Evolution

On Wed, Aug 10, 2016 at 10:37 PM Chris Lattner <clatt...@apple.com> wrote: > > On Aug 9, 2016, at 3:01 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > So perhaps it would be reasonable for us to standardize on something like > this: > &g

Re: [lldb-dev] LLDB Evolution

ions? > I was assuming that upon completion of this exercise, we would delete the > lldb coding conventions doc. > > Jim > > > On Aug 11, 2016, at 11:20 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > On Wed, Aug 10, 2016 at

Re: [lldb-dev] LLDB Evolution

On Thu, Aug 11, 2016 at 3:28 PM Greg Clayton wrote: > > > - Will we stop putting m_ at the front of class ivars and g_ at > the front of globals? > > I believe these make things much clearer and I would love to see llvm and > clang adopt some way to identify member

Re: [lldb-dev] Add support for OCaml native debugging

I don't like the idea of not having tests. Promising tests and actually delivering on them are two entirely different things. And without them, we just end up with broken code and nobody to maintain it On Thu, Jul 7, 2016 at 6:23 AM Tamas Berghammer via lldb-dev < lldb-dev@lists.llvm.org> wrote:

Re: [lldb-dev] LLDB Evolution

On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev < lldb-dev@lists.llvm.org> wrote: > LLDB has come a long way since the project was first announced. As a > robust debugger for C-family languages and Swift, LLDB is constantly in use > by millions of developers. It has also become a

Re: [lldb-dev] Leaks from static variables

If you're linking against liblldb you can't rely on the os cleaning up because you could unload liblldb before shutting down the process. Also it's good practice to do explicit cleanup since its not always just a simple matter of releasing resources, sometimes actual shutdown code needs to be

Re: [lldb-dev] LLDB Evolution

On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > *Near-Term Goal: Standardizing on LLVM-style clang-format Rules* > > We’ve heard from several in the community that would prefer to have a > single code formatting style to further unify the two code

Re: [lldb-dev] LLDB Evolution

Standardizing include order would really help. LLVM's style is documented here , but to quote it: 1. Main Module Header 2. Local/Private Headers 3. llvm/... 4. System #includes So perhaps it would be reasonable for us to

Re: [lldb-dev] compile failure with VS 2015 Update 3

So without declspec(align(8)) was this a silent codegen bug in update 2? Despite the error message, I don't think this happens on a pass by value, as std atomic is not copyable On Thu, Jun 30, 2016 at 3:49 PM Reid Kleckner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Right, the x86_32

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

story. Read the comments and the review threads. It's hilarious. > > On Wed, Feb 8, 2017 at 1:00 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Why doesn't llvm::call_once() just use std::call_once on Windows? > > On Wed, Feb 8, 2017 at 12:40 PM

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

bug was to know if it has been fixed. On Wed, Feb 8, 2017 at 1:03 PM Reid Kleckner <r...@google.com> wrote: > It's a sad story. Read the comments and the review threads. It's hilarious. > > On Wed, Feb 8, 2017 at 1:00 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llv

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

Why doesn't llvm::call_once() just use std::call_once on Windows? On Wed, Feb 8, 2017 at 12:40 PM Hans Wennborg wrote: > The Win64 lldb build seems broken (at 294367). > > I ran into this when trying to build the weekly snapshot > (http://www.llvm.org/builds/) which includes

Re: [lldb-dev] RTTI does not work stable in LLDB.

Doesn't the DWARF have a record for the VTable itself? I know PDB does, you can look up the class name through the VTable debug info record rather than trying to demangle the name. On Mon, Feb 6, 2017 at 2:21 PM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Yeah, when doing

Re: [lldb-dev] Too many ModuleSP references

On Tue, Feb 21, 2017 at 4:24 PM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > On Feb 21, 2017, at 9:10 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > No comments on this specifically, but +1 to reducing shared_ptr usage in > g

Re: [lldb-dev] About lldbHost

e, ...). Missing contents will be replaced with zeroes. > */ > > Are you trying to use them for read-write access? That's all I can see. > > Jim > > > > On Feb 21, 2017, at 1:47 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > &g

Re: [lldb-dev] About lldbHost

eachable removable or remote media, access > beyond > * end-of-file, ...). Missing contents will be replaced with zeroes. > */ > > Are you trying to use them for read-write access? That's all I can see. > > Jim > > > > On Feb 21, 2017, at 1:47 PM, Zachary Tu

Re: [lldb-dev] About lldbHost

On Wed, Feb 15, 2017 at 11:02 AM Greg Clayton wrote: > > The other thing is on Mac we add new flags to mmap that allow us not to > crash if the backing store (network mount) goes away. There is also a flag > that says "if code signature is borked, please still allow me to

Re: [lldb-dev] Too many ModuleSP references

No comments on this specifically, but +1 to reducing shared_ptr usage in general. We use way too many, and often it feels like shared_ptr is used as a way to avoid having to think about ownership, which leads to more problems than it solves imo On Tue, Feb 21, 2017 at 9:03 AM Pavel Labath via

[lldb-dev] About lldbHost

After https://reviews.llvm.org/D29964, we finally have a starting point at which we can begin unravelling the cross-project cyclic dependencies in LLDB. lldb/Utility now is very similar in spirit to llvm/Support. But llvmSupport goes one step further and includes what lldb would normally put

Re: [lldb-dev] About lldbHost

uch independently of any other > refactoring we will be doing. > > What do you think? > > > > On 15 February 2017 at 01:48, Zachary Turner via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > After https://reviews.llvm.org/D29964, we finally have a starting point

Re: [lldb-dev] About lldbHost

On Wed, Feb 15, 2017 at 10:47 AM Reid Kleckner wrote: > On Wed, Feb 15, 2017 at 10:35 AM, Greg Clayton via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > I am fine with switching mmap over to llvm if it works. One important > thing to LLDB is we have a "mmap if not on remote

Re: [lldb-dev] About lldbHost

d, and I think it > >>>>> should be. I believe this is the reason the FileSystem pseudo-class > >>>>> was created. > >>>>> > >>>>> So, my counter-proposal would be to finish moving the host-specific > >>>>&g

Re: [lldb-dev] About lldbHost

ing I really like about this idea is that we will end up with > >> two classes that very closely mirror llvm functionality (FileSpec is a > >> version of Support/Path.h that does not assume host path syntax, > >> FileSystem is similar to Support/FileSystem.h, but it supports some

Re: [lldb-dev] About lldbHost

If you only ever call MemoryMapContentsIfLocal, then is that first flag even doing anything? And if you are passing that flag, then can you just mmap it always even if non-local? I searched the code and only in the windows minidump plugin are we unconditionally mmaping, and that could be changed

<    1   2   3   4   5   >