similar to: [LLVMdev] Crash reporting in clang/lldb

On 2/12/2016 9:47 PM, Vince Harron wrote: > Are you building LLDB? Im guessing that is where the failure is I'm building LLVM. The failure in the buildbot happens when compiling HexagonFrameLowering.cpp: ---------- FAILED: C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe /nologo /TP /DWIN32 /D_WINDOWS /W4 -wd4141 -wd4146 -wd4180 -wd4244 -wd4258 -wd4267 -wd4291 -wd4345 -wd4351 -wd4355 -wd4456

On Fri, Jan 18, 2013 at 4:00 PM, Eli Bendersky <eliben at google.com> wrote: > Hi All, > > While working on some recent patches for x32 support, I ran into an > unpleasant limitation the LLVM eco-system has with testing DWARF > emission. We currently have several approaches, neither of which is > great: > > 1. llvm-dwarfdump: the best approach when it works. But

Hi All, While working on some recent patches for x32 support, I ran into an unpleasant limitation the LLVM eco-system has with testing DWARF emission. We currently have several approaches, neither of which is great: 1. llvm-dwarfdump: the best approach when it works. But unfortunately lib/DebugInfo supports only a (small) subset of DWARF. Tricky sections like debug_frame aren't supported. 2.

It works for me: ------ Build started: Project: LLVMHexagonCodeGen, Configuration: RelWithDebInfo Win32 ------ cl : Command line warning D9002: ignoring unknown option '/Zc:inline' HexagonFrameLowering.cpp ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== Here's the info from the "about" window: Microsoft Visual Studio Professional 2013

> I still think that we do bfd locs with a decent option to change for at least the current release and sources and then, once we're a little more certain we have everything that might want to parse dwarf (say by working with dwarf-discuss), we can change the default. Given what’s been found, I think Eric/Dave are correct, use bfd behavior by default with an option to do the new thing.

>From my understanding the breakpad bug was also only related to .debug_line and has been fixed by https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2317730 > a) .debug_ranges&.debug_loc => -2, .debug_line => 0, other .debug_* -> -1 > b) .debug_ranges&.debug_loc => -2, other .debug_* => 0 I am still of the opinion that we should just do a), not b).

Hello all, yesterday I sent an email <http://lists.llvm.org/pipermail/lldb-dev/2019-March/014811.html> to lldb-dev proposing a new tool in lldb for yamlization of minidump files. It's been suggested to me that instead of a new tool it may be better to add support for that format to obj2yaml instead. Hence, this email. :) As I expect most people are unfamiliar with this format, I'm

Can we please just revert back to what we had before until the discussion about the desired behaviour and how to get there reaches a conclusion? In particular, I would like to merge that revert to the 11.x branch. At this point in the release process, I'm not keen on taking any patch that changes the behavior to something that hasn't been well tested from sitting in trunk for a while. On

Created https://reviews.llvm.org/D84825 to be used for release/11.x I haven't seen a strong argument for changing other .debug_* but in any case I don't want to continue debating on this topic. * .debug_ranges & .debug_loc: -2 (lld<11: 0+addend) * .debug_*: 0 (lld<11: 0+addend, lld HEAD: -1) On Mon, Jul 27, 2020 at 12:47 PM David Blaikie <dblaikie at gmail.com> wrote:

As I mentioned in the thread (to many people who don't have time to read the discussions), pushing https://reviews.llvm.org/D84825 restores the original behavior. The same effect as one would get by reverting all related patches. If someone gives me an approval, I'll push it immediately. I already get verbal LGTM from Peter. > With respect I think the "request for changes"

On 2020-07-29, Eric Christopher wrote: >I think the arguments are largely compatibility for software that's already >deployed and can't easily upgrade, and wanting to ensure a larger time >frame for migration with a fallback if things go wrong. A bridge basically >from what we had to where we'd like to be. > >I think we also need to make the change in mainline lld as

no expression parser or knowledge of any specific programming language. Basically I just mean that the parsing of the native DWARF format itself is in scope, but anything beyond that is out of scope. For symbolication we have things like llvm-symbolizer that already just work and are built on top of LLVM's dwarf parsing code. Similarly, LLDB's type system could be built on top of it as

Honestly even though I do understand the debug information I'm with you and one reason why I'm pushing for the same reset that you are. There are a lot of threads, it's fairly confusing what has been done where and other than some fairly widespread breakage among early users of lld (i.e. a short time from commit to use) it's unclear what the plan is to roll this out effectively

You'd probably need to pull the Unwinder in if you want backtraces, but that part shouldn't be that hard to disentangle. I don't think you'd need much else? Basing your work on NativeProcess rather than lldb proper would also cut the number of observer processes in half and avoid the context switches between the server and the debugger. That seems more appropriate for a

On Wed, Aug 5, 2020 at 12:50 PM Fāng-ruì Sòng <maskray at google.com> wrote: > On Wed, Aug 5, 2020 at 12:32 PM Eric Christopher <echristo at gmail.com> > wrote: > > > > Honestly even though I do understand the debug information I'm with you > and one reason why I'm pushing for the same reset that you are. There are a > lot of threads, it's fairly

Not subscribed to the list, sorry to mess up the message threading - but to touch on one question that was raised earlier in the day, Bob Wilson wrote: > On Mar 28, 2014, at 4:23 PM, Jevin Sweval <jevinsweval at gmail.com> wrote: > >> Is the LLDB patch missing? I only see libc++, compiler-rt, LLVM, and Clang patches > > We have a patch for LLDB but it is combined with a

I there, I recently installed wine, and followed this document https://help.ubuntu.com/community/CounterStrike to install steam. After installing steam I logged into my account and installed Day of Defeat Source from my steam account. After downloading and installing when I click play I got this error in my command line: errle:RevokeDragDrop invalid hwnd (nil) errle:RevokeDragDrop invalid hwnd

Hi all. I was using wine 1.3.10 to run Steam and Left 4 Dead2 successfully until recently. Last week, there was an update for Steam, and now I can't start Left 4 Dead 2. It starts up, but then immediately crashes. The window "Preparing to launch Left 4 Dead 2" pops up, and then disappears. It worked flawlessly last Sunday, and yesterday it stopped working. I am getting the same

It is interesting that the stop reason on the thread that stopped is "trace". That's what you would expect returning from the single-step to step over the breakpoint. But it looks like we got a signal while single-stepping, but the stop reason was misreported by somebody. Jim > On Apr 17, 2018, at 6:00 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:

Hello lldb developers, I am running into a problem with lldb on Linux. I am currently running llvm 6.0.0. I have an executable that dynamically loads a large number of shared libraries at runtime. These are explicitly loaded via dlopen (they are specified in a configuration file), and after loading a few (typically a dozen or so, but the number varies) lldb will halt during dlopen. If I