Great, this should work with GDB on Linux now! Hope to find the time
soon to double-check.
Note that for LLDB we have to fix the second part of this regression
(source-level debugging):
https://bugs.llvm.org/show_bug.cgi?id=36209
For MachO support on macOS we need to implement `getObjectForDebug(
Interesting. Is there any extra info dumped to the log (e.g. `log enable
lldb default`)
On 22/07/2019 16:34, Gábor Márton wrote:
> Well, SIP is turned off and I experience the same with a binary I just
> built:
> ```
> egbomrt@msmarple ~/llvm2/build/release_assert $ csrutil status
> System Integri
> egbomrt@msmarple ~/llvm2/build/release_assert $ ./bin/lldb /bin/ls
> (lldb) target create "/bin/ls"
> Current executable set to '/bin/ls' (x86_64).
> (lldb) r
> *error: process exited with status -1 (Error 1)*
I don't think this is related to debugserver codesigning. If you really
need to debug s
Hi Gábor, I am sorry this caused an issue for you. Good that apparently
it's resolved now.
Did you reconfigure an existing build-tree? Your observations would make
sense in this context, because the change affects CMake cached
variables. This is unfortunate, but can not always be avoided. If this
Hey Jonas, thanks for the initiative! I actually started doing the same today
but then go distracted. Your changes certainly put it in a much better shape!
Before touching anything again, maybe it's worth some feedback first:
* In "Building LLDB with CMake & Ninja": Should we update the build
in
For compiler-rt and/or LLDB: is anyone else running into "FileCheck
target does not exist"?
https://bugs.llvm.org/show_bug.cgi?id=40443
Will try and figure it out tomorrow morning (in a few hours).
Best
Stefan
Am 24.01.19 um 01:49 schrieb Hans Wennborg via llvm-dev:
> Dear testers,
>
> 8.0.0-rc1
Hi Gabor
Is this behavior reproducible with the current upstream LLDB? (after
https://reviews.llvm.org/D55013)
Did you follow the instructions in docs/code-signing.txt?
> There is a setting to disable it. These days, you should be able to achieve
> it with LLDB_CODESIGN_IDENTITY="" or SKIP_DEBU
esn't fit on the
> screen. Once I figure out how/if we can include the section names I'll
> generate the site with the LLVM theme so people can compare and give their
> opinion.
>
> Cheers,
> Jonas
>
> On Tue, Jan 8, 2019 at 9:31 AM Jonas Devlieghere <mail
Hi Jonas, I think this is a great effort. Thanks!
My current reviews do some small updates on the build page. Hope this doesn't
get in conflict with your work?
Best
Stefan
> On 6. Dec 2018, at 18:02, Jonas Devlieghere via lldb-dev
> wrote:
>
> Hi everyone,
>
> The current LLDB website is wr
Hi all
I put a number of patches for review that are related to LLDB standalone builds
and testing. They mostly clean up things that confused me while investigating
the mysterious problem with the cxx target dependency [1][2].
One of the changes [4] has relevant effects on CMake parameters: it
Hi Alex, hi Pavel
Thanks for your feedback and sorry for the late reply, I was a little busy on
the other sites.
Ok, so making the LLDB_FRAMEWORK_INSTALL_DIR vs. LLDB_FRAMEWORK_BUILD_DIR
distinction and changing the approach for tools from symlink to copy sound like
good tasks to start with.
Hello Alex, hello Pavel
I spent some time creating/streamlining our CMake infrastructure downstream of
LLDB and learned a few things about bundles, versions, code-signing etc.
(mostly on the Darwin side of things). I am currently sorting out what can be
upstreamed and prepare reviews.
Some wor
> root of the DIE tree described by each unit header. <>
> Whatever is producing one unit contained inside another is doing something
> wrong.
> --paulr
>
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Stefan
> Gränitz via lldb-dev
> Sent: Friday,
SymbolFileDWARFDebugMap::PrivateFindGlobalVariables(), which is
one of the clients for symbol slices/ranges. The remaining ones are
SymbolFileDWARFDebugMap::SymbolContainsSymbolWithID/Index() and
SymbolFileDWARFDebugMap::CompileUnitInfo::GetFileRangeMap(), which are all
alive.
> On 11. Sep
Thanks for your replies!
>> Right now we assume that each .o file has only on CU so we don't need to
>> open all .o files in SymbolFileDWARFDebugMap::CalculateAbilities() which is
>> something that gets run when we are trying to figure out which SymbolFile
>> plug-in to load. [...] The problem
Hello everyone
I am investigating a bug that prevents correct breakpoint resolution in LTO
objects with embedded DWARF (no separate dSYM file) and tracked it down to the
initialization of SymbolFileDWARFDebugMap. This code seems to assume there is
only one compile unit per object file, but LTO
One more short question, as you seem to be much more familiar with the
code than me. Maybe you have an idea?
In the unit test I prepared, I didn't manage to cover this line in
Symtab::InitNameIndexes():
https://github.com/llvm-mirror/lldb/blob/master/source/Symbol/Symtab.cpp#L348
With both demang
Hi Pavel, thanks for your feedback!
> I would propose to create a new class (RichMangingInfo?), which would
> wrap both ItaniumPartialDemangler and the existing string-chopping
> implementation, and provide a unified interface on top of them.
Right, good point. Adding an abstraction like this cert
Hello everyone
I am relatively new to the LLDB sources and just submitted my first own
patch for review in Phabricator. Based on this patch I would like to
discuss a few details for further improvements on LLDB's demangling.
First a short recap on the current state:
* Name demangling used to be a
Hello everyone, Haitao, Greg, Keno
Reviving this topic as I am investigating the current state of JITed
code debugging in LLVM release 4.0 for our upcoming LLVM Social in
Berlin. Following the docs I got everything working on Linux (for a side
note see 0):
http://llvm.org/docs/DebuggingJITedCode.h
20 matches
Mail list logo
