Re: [lldb-dev] JIT debugging on Mac OSX

[Stefan Gränitz via lldb-dev]

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.html

On OSX it doesn't work as there's a special check preventing
JITLoaderGDB instantiation:

ArchSpec arch (process->GetTarget().GetArchitecture());
if (arch.GetTriple().getVendor() != llvm::Triple::Apple)
  jit_loader_sp.reset(new JITLoaderGDB(process));

Trying to reconstruct history: The check was introduced due to a
performance issuein 2014 (see 1). Shortly afterwards Keno Fischer
submitted his implementation for MachO support and in the original
patch, the OSX limitation was removed as I'd expected(see 2). However,
in the final LLDB commit these lines remained inside (see 3), I guess
because the performance issue was still present? IIUC this was
onlysolved in 2015 with a special option to enable the JIT loader
breakpoint (see 4). Though the check for llvm::Triple::Apple is still in
there..

So I guess there are more reasons why JITed code debugging is still not
available on OSX?

Just removing the line, doesn't get me anywhere (see terminal output in
5). Although LLI's __jit_debug_register_code and __jit_debug_descriptor
symbols are found correctly, the jit-debug-register breakpoint set in
JITLoaderGDB::SetJITBreakpoint will never be hit, so source locations
are not resolved and debug symbols not available.

It would be great to hear if anyone knows more about the topic, how to
fix or workaround it, or maybe alternative ways to get it done on OSX.

Thanks
Stefan

--

(0) The docs could be updated as the mentioned lli flag recently changed
from "-use-mcjit" to "-jit-kind=mcjit". Also it won't work with
"-jit-kind=orc-mcjit" as  OrcMCJITReplacement does not register
GDBRegistrationListener as MCJIT does:
https://github.com/llvm-mirror/llvm/blob/master/lib/ExecutionEngine/MCJIT/MCJIT.cpp#L90

(1) 07.04.2014:
Disable JITLoaderGDB on "vendor == apple" for now due to performance
slowdowns [...]
https://github.com/llvm-mirror/lldb/commit/2829ee8e179e9d3381de08dba1502351e34867c0

(2) 03.06.2014:
Allow MachO JIT debugging (Review)
https://reviews.llvm.org/D4006#C84943OL290

(3) 25.06.2014:
[...] enable JITLoaderGDB with mach-o file support
https://github.com/llvm-mirror/lldb/commit/a900ab69519016161cd640643776b55a1e56ad84
https://github.com/llvm-mirror/lldb/blob/a900ab69519016161cd640643776b55a1e56ad84/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp#L367

(4) 16.09.2015:
[...] make JIT loader breakpoint optional
https://github.com/llvm-mirror/lldb/commit/4066cc33b57758fbc94afc3428c52e817a65c201

(5) Debugging JITed code with LLDB & LLVM Release 4.0 on OSX 10.12:

(lldb) target create "/Dev/3rdParty/llvm40-build-xcode/Debug/bin/lli"
Current executable set to
'/Dev/3rdParty/llvm40-build-xcode/Debug/bin/lli' (x86_64).
(lldb) settings set -- target.run-args  "-O0" "-jit-kind=mcjit"
"/Dev/Personal/jitdebug/foo.ll"
(lldb) log enable lldb jit
(lldb) settings set plugin.jit-loader.gdb.enable-jit-breakpoint true
(lldb) b foo.c:4
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) run
JITLoaderGDB::SetJITBreakpoint looking for JIT register hook
JITLoaderGDB::SetJITBreakpoint setting JIT breakpoint
Process 7433 launched: '/Dev/3rdParty/llvm40-build-xcode/Debug/bin/lli'
(x86_64)
Process 7433 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x000103fd000c
->  0x103fd000c: movl   (%rcx), %esi
0x103fd000e: movabsq $0x103fd1000, %rdi; imm = 0x103FD1000
0x103fd0018: movabsq $0x7fffcb06f180, %rcx ; imm = 0x7FFFCB06F180
0x103fd0022: xorl   %eax, %eax
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000103fd000c
frame #1: 0x000103fd0050
frame #2: 0x000103fd0070
frame #3: 0x000103fd009b
frame #4: lli`llvm::MCJIT::runFunction(this=0x000106806200,
F=0x000104003238, ArgValues=ArrayRef @
0x7fff5fbfacd0) at MCJIT.cpp:538
frame #5:
lli`llvm::ExecutionEngine::runFunctionAsMain(this=0x000106806200,
Fn=0x000104003238, argv=size=1, envp=0x7fff5fbff708) at
ExecutionEngine.cpp:471
frame #6: lli`main(argc=6, argv=0x7fff5fbff6d0,
envp=0x7fff5fbff708) at lli.cpp:632
frame #7: 0x7fffcaff6235 libdyld.dylib`start + 1

On Sat Jul 6 05:58:39 PDT 2013 HaiTao Feng wrote:
> Hi,
>
> How does JIT debugging feature work on Mac OSX?
>
> It seems that some LLVM documents implied lldb supports JIT debugging on
> Mac OSX.
>   1) "LLDB may be a better option for debugging JIT-ed code on Mac OS X."
> from http://llvm.org/docs/DebuggingJITedCode.html.
>   2)  "Upcoming features include JIT debugging, core file support and
> support of new processor features." in the 

[lldb-dev] LLDB Demangling

[Stefan Gränitz via lldb-dev]

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 lazy process, exclusively accessible via
Mangled::GetDemangledName() - this is a valuable mechanism:
https://github.com/llvm-mirror/lldb/blob/8ba903256fd92a2d8644b108a7c8a1a15efd90ad/source/Core/Mangled.cpp#L252
* My patch wants to replace the existing combination of FastDemangle &
itaniumDemangle() with LLVM's new ItaniumPartialDemangler (IPD)
implementation and no fallbacks anymore. It slightly reduces complexity
and slightly improves performance, but doesn't introduce conceptual
changes: https://reviews.llvm.org/D49612
* IPD provides rich information on names, e.g. isFuntion() or
isCtorOrDtor(), but stores that in its own state rather than returning a
queriable object:
https://github.com/llvm-mirror/llvm/blob/a3de0cbb8f4d886a968d20a8c6a6e8aa01d28c2a/include/llvm/Demangle/Demangle.h#L36
* IPD's rich info could help LLDB, where it currently parses mangled
names on its own, on-top of demangling. Symtab::InitNameIndexes() seems
to be the most prominent such place. LLDB builds an index with various
categories from all its symbols here. This is performance-critical and
it does not benefit from the laziness in GetDemangledName():
https://github.com/llvm-mirror/lldb/blob/8ba903256fd92a2d8644b108a7c8a1a15efd90ad/source/Symbol/Symtab.cpp#L218

My simple switch doesn't exploit IPD's rich demangling info yet and it
uses a new IPD instance for each demangling request, which is considered
quite costly as it uses a bump allocator internally. Over-all
performance still didn't drop, but even seems to benefit.

In order to fully exploit the remaining potential, I am thinking about
the following changes:

(1) In the Mangled class, add a separate entry-point for batch
demangling, that allows to pass in an existing IPD:
bool Mangled::DemangleWithRichNameIndexInfo(ItaniumPartialDemangler &IPD);

(2) DemangleWithRichNameIndexInfo() will demangle explicitly, which is
required to make sure we gather IPD's rich info. It's not lazy as
GetDemangledName(), but it will store the demangled name and set the
"MangledCounterpart" so that subsequent lazy requests will be fast.

(3) DemangleWithRichNameIndexInfo() will be used by
Symtab::InitNameIndexes(), which will have a single IPD instance that is
reused for all symbols. Symtab::InitNameIndexes() is usually called
before anything else, so it is basically "warming the cache" here.

(4) Finally, with IPD's rich info, we can get rid of the additional
string parsing in Symtab::InitNameIndexes(). I expect a considerable
speedup here too.

What do you think about the plan?
Do you think it's a good idea to add DemangleWithRichNameIndexInfo()
like this?
Are you aware of more batch-processing places like
Symtab::InitNameIndexes(), that I should consider as clients for
DemangleWithRichNameIndexInfo()?
Do you know potential side-effects I must be aware of?
Would you consider the evidence on the performance benefits convincing,
or do you think it needs bulletproof benchmarking numbers?

When it comes to MSVC-mangled names:
* It is certainly necessary to keep a legacy version of the current
categorization mechanism for these. But in general, what do you think
about their importance for LLDB? (Personally I would like to see LLDB on
Windows, but I tried it only once and gave up quickly.)
* I saw there is a new MicrosoftDemangler now in LLVM. Does anyone know
more about it? Especially: Are there plans to provide rich demangling
information similar to the IPD?

So far I started writing a unit test for Symtab::InitNameIndexes(), so I
won't accidentally break its indexing. I also experimented with a
potential DemangleWithRichNameIndexInfo() and had a look on the numbers
of the internal LLDB timers. This was, however, not exhaustive and real
benchmarking is always hard.

Thanks for all kinds of feedback.

Best,
Stefan


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

Re: [lldb-dev] LLDB Demangling

[Stefan Gränitz via lldb-dev]

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 certainly makes sense.

> we might be able
> to get further speedup by having DemangleWithRichNameIndexInfo *not*
> fill out the demangled string (as, I understand, building the actual
> string is the most expensive operation), and just fetching the bits of
> info we need from the IPD.
Yes, if it turns out we really don't need the demangled names in a table
and instead just render them on-demand, I guess we'd gain additional
speedup plus reduction in memory usage. I will have a closer look on this.

> right now the Symtab class builds a table containing all
> demangled names. This is mostly unnecessary, and
What exact table are you referring to here? The m_name_to_index map does
store both, demangled and mangled strings. Not sure to what extend the
demangled ones are necessary. It's a little hard to judge, but I can try
and check. Or do you mean a different one?

There is one more follow-up task here: Now that FastDemangle isn't used
anymore in Mangled::GetDemangledName(), its last remaining usage is
SubsPrimitiveParmItanium() in CPlusPlusLanguage.cpp. I will try to
figure out if we still need it or if we can switch it to the IPD too.
Then we could consider to get rid of FastMangle altogether.

Any objections here?


Am 25.07.18 um 13:11 schrieb Pavel Labath:
> Hello Stefan,
>
> thank you for working on this. I believe this work will bring a huge
> improvement to LLDB.
>
> Adding something like DemangleWithRichNameIndexInfo to the Mangled
> class makes sense to me. However, I don't think that function should
> be taking an ItaniumPartialDemangler as an argument. The reason for
> that is that ItaniumPartialDemangler is, unsurprisingly, specific to
> the itanium mangling scheme, and the Mangled class tries to hide the
> specifics of different manglings.
>
> 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.
> Internally it would use IPD for the itanium scheme and the legacy
> implementation for the MSVC mangling, but the user would not have to
> care about that, as it can just ask questions like "is this a
> constructor?" and get the correct answer either way. If ever we get
> something similar to IPD for the MSVC mangling scheme, we can just
> replace the legacy implementation with that one, and nobody should
> know the difference.
>
> What do you think?
>
>
> BTW, right now the Symtab class builds a table containing all
> demangled names. This is mostly unnecessary, and in fact we have
> recently removed a similar table for the demangled debug_info names.
> The only present use for it that I am aware of is papering over a
> clang "bug"*. If we are able to get rid of this, then we might be able
> to get further speedup by having DemangleWithRichNameIndexInfo *not*
> fill out the demangled string (as, I understand, building the actual
> string is the most expensive operation), and just fetching the bits of
> info we need from the IPD.
>
> (*) The "bug" is that sometimes clang will not generate the C1 (full
> object) flavour of an constructor if it is identical to the C2 version
> (even though the CU in question definitely constructs full objects of
> the given class). This means that we are not able able to construct
> some objects during expression evaluation as we cannot find the C1
> version anywhere. The demangling makes this work accidentally, as were
> are able to match up the constructors by demangled names, as they both
> demangle to the same string. I have recently fixed clang to emit C1
> always (at -O0), but the question remains on what to do with older
> compilers.
>
>
> On Tue, 24 Jul 2018 at 21:55, Stefan Gränitz  
> wrote:
>> 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 lazy process, exclusively accessible via
>> Mangled::GetDemangledName() - this is a valuable mechanism:
>> https://github.com/llvm-mirror/lldb/blob/8ba903256fd92a2d8644b108a7c8a1a15efd90ad/source/Core/Mangled.cpp#L252
>> * My patch wants to replace the existing combination of FastDemangle &
>> itaniumDemangle() with LLVM's new ItaniumPartialDemangler (IPD)
>> implementation and no fallbacks anymore. It slightly reduces complexity
>> and slightly improves performance, but doesn't introduce conceptual
>> changes: https://reviews.llvm.org/D49612
>> * IPD provides rich information on names, e.g. isFuntion() or
>> isCtorOrD

Re: [lldb-dev] LLDB Demangling

[Stefan Gränitz via lldb-dev]

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 demangle implementations, the old one and IPD, annotations
cause demangling to fail/return empty name. I assume this branch has its
right to exist and I would just keep it, but it would also be great to
find an explanation and a repro to cover it.

Am 25.07.18 um 20:15 schrieb Stefan Gränitz:
> 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 certainly makes sense.
>
>> we might be able
>> to get further speedup by having DemangleWithRichNameIndexInfo *not*
>> fill out the demangled string (as, I understand, building the actual
>> string is the most expensive operation), and just fetching the bits of
>> info we need from the IPD.
> Yes, if it turns out we really don't need the demangled names in a table
> and instead just render them on-demand, I guess we'd gain additional
> speedup plus reduction in memory usage. I will have a closer look on this.
>
>> right now the Symtab class builds a table containing all
>> demangled names. This is mostly unnecessary, and
> What exact table are you referring to here? The m_name_to_index map does
> store both, demangled and mangled strings. Not sure to what extend the
> demangled ones are necessary. It's a little hard to judge, but I can try
> and check. Or do you mean a different one?
>
> There is one more follow-up task here: Now that FastDemangle isn't used
> anymore in Mangled::GetDemangledName(), its last remaining usage is
> SubsPrimitiveParmItanium() in CPlusPlusLanguage.cpp. I will try to
> figure out if we still need it or if we can switch it to the IPD too.
> Then we could consider to get rid of FastMangle altogether.
>
> Any objections here?
>
>
> Am 25.07.18 um 13:11 schrieb Pavel Labath:
>> Hello Stefan,
>>
>> thank you for working on this. I believe this work will bring a huge
>> improvement to LLDB.
>>
>> Adding something like DemangleWithRichNameIndexInfo to the Mangled
>> class makes sense to me. However, I don't think that function should
>> be taking an ItaniumPartialDemangler as an argument. The reason for
>> that is that ItaniumPartialDemangler is, unsurprisingly, specific to
>> the itanium mangling scheme, and the Mangled class tries to hide the
>> specifics of different manglings.
>>
>> 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.
>> Internally it would use IPD for the itanium scheme and the legacy
>> implementation for the MSVC mangling, but the user would not have to
>> care about that, as it can just ask questions like "is this a
>> constructor?" and get the correct answer either way. If ever we get
>> something similar to IPD for the MSVC mangling scheme, we can just
>> replace the legacy implementation with that one, and nobody should
>> know the difference.
>>
>> What do you think?
>>
>>
>> BTW, right now the Symtab class builds a table containing all
>> demangled names. This is mostly unnecessary, and in fact we have
>> recently removed a similar table for the demangled debug_info names.
>> The only present use for it that I am aware of is papering over a
>> clang "bug"*. If we are able to get rid of this, then we might be able
>> to get further speedup by having DemangleWithRichNameIndexInfo *not*
>> fill out the demangled string (as, I understand, building the actual
>> string is the most expensive operation), and just fetching the bits of
>> info we need from the IPD.
>>
>> (*) The "bug" is that sometimes clang will not generate the C1 (full
>> object) flavour of an constructor if it is identical to the C2 version
>> (even though the CU in question definitely constructs full objects of
>> the given class). This means that we are not able able to construct
>> some objects during expression evaluation as we cannot find the C1
>> version anywhere. The demangling makes this work accidentally, as were
>> are able to match up the constructors by demangled names, as they both
>> demangle to the same string. I have recently fixed clang to emit C1
>> always (at -O0), but the question remains on what to do with older
>> compilers.
>>
>>
>> On Tue, 24 Jul 2018 at 21:55, Stefan Gränitz  
>> wrote:
>>> 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 s

[lldb-dev] Extract compile unit infos from OSO entries for LTO objects

[Stefan Gränitz via lldb-dev]

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 objects have more than that:

void SymbolFileDWARFDebugMap::InitOSO() {
...
  const uint32_t oso_index_count =
symtab->AppendSymbolIndexesWithTypeAndFlagsValue(
eSymbolTypeObjectFile, k_oso_symbol_flags_value, oso_indexes);
...
  m_compile_unit_infos.resize(oso_index_count); // <—— one CU per OSO entry in 
the Symtab

  for (uint32_t i = 0; i < oso_index_count; ++i) {
const uint32_t so_idx = oso_indexes[i] - 1;
const uint32_t oso_idx = oso_indexes[i];
const Symbol *so_symbol = symtab->SymbolAtIndex(so_idx);
const Symbol *oso_symbol = symtab->SymbolAtIndex(oso_idx);
...
  const Symbol *last_symbol = symtab->SymbolAtIndex(sibling_idx - 1);
  m_compile_unit_infos[i].first_symbol_index = so_idx;
  m_compile_unit_infos[i].last_symbol_index = sibling_idx - 1;
  m_compile_unit_infos[i].first_symbol_id = so_symbol->GetID();
  m_compile_unit_infos[i].last_symbol_id = last_symbol->GetID();

The symptom is that LLDB will only read debug_line for one CU and miss all the 
rest. Thus, breakpoints in other CUs can’t be associated with line information.

I wonder if there is a good way to populate the correct number of compile units 
from the OSO entry at this point?

The situation may appear similar to an archive file with a number of objects, 
but then we have separate OSO entries like 
“path/to/lib/libLLVMMCParser.a(AsmLexer.cpp.o)”. Furthermore LTO objects have 
one common symtab for all compile units and it was probably mixed up by 
optimization, so we cannot simply say that CUs start/end at certain symbol 
indexes as in the above code. The latter is used rarely and only in 
SymbolFileDWARFDebugMap, so there may be a workaround, but first I have to 
figure out the initial question:

How to get more information about compile units in an LTO object? Any ideas 
welcome!

If that’s not possible, I may find another way to fix it further down the road, 
but then the name m_compile_unit_infos seems not exactly correct here. It’s 
rather something like m_referenced_object_infos, right?
Btw.: My first attempt was a workaround for the symptom (see 
https://reviews.llvm.org/D51546). It simply reads all debug_lines for a single 
CU, but I’d really appreciate a better solution.

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

Re: [lldb-dev] Extract compile unit infos from OSO entries for LTO objects

[Stefan Gränitz via lldb-dev]

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 used to be that even if we had a dSYM 
>> file, the loop that selected the symbol file plug-in would give each and 
>> every symbol file plugin a chance ...

Ok makes total sense, kind of historical reason.

>> But that being said, in the past I re-ordered how the SymbolFile plug-ins 
>> were initialized to always put SymbolFileDWARF first and if it finds DWARF 
>> debug info or a dSYM file and has all the abilities then we stop looking for 
>> symbol file plug-ins that can load the current file. [...] So as soon as a 
>> SymbolFile plug-in can do everything we now stop.

Good to know!

> Note that counting the number of compile units can be done extremely cheaply 
> (of course, except the cost of opening the file). Each unit as a header that 
> contain its length (which gives you the next unit). I’m not sure we have a 
> primitive that does this without parsing the DWARF, but it should be easy to 
> add.


Right, so we only need to parse the CU headers. That should be fast.
Opening each candidate .o file for the relatively rare case of having multiple 
CUs still sounds expensive, assuming that “thousands of .o files” may actually 
happen.

CalculateAbilities() does indeed call GetNumCompileUnits(), but what it really 
wants to know at this time is “do we have any CU in there”:

uint32_t SymbolFileDWARFDebugMap::CalculateAbilities() {
  ...
  const uint32_t oso_index_count = GetNumCompileUnits();
  if (oso_index_count > 0) {
InitOSO();
if (!m_compile_unit_infos.empty()) {
  return SymbolFile::CompileUnits | SymbolFile::Functions | …;
  }
}

As far as I can tell, we need the actual number of CUs only after we discovered 
plugins. In my case it’s during breakpoint resolution (i.e. 
BreakpointResolverFileLine::SearchCallback()). If we separated these two 
concerns conceptually (into HasCompileUnits() and GetNumCompileUnits()), 
couldn’t we then also do InitOSO() in two steps? Especially since lazy init is 
used everywhere already. This would avoid impact on CalculateAbilities() 
entirely.

That said, I don’t really know how big the change would get then. And it 
probably adds complexity, while the implementation is quite complex already.
Anyway, for now what do you think about the idea?


> Do we really need this CU <-> Symbol mapping?

It’s used in SymbolFileDWARFDebugMap::SymbolContainsSymbolWithIndex(), which 
looks like dead code.
It’s also used in SymbolFileDWARFDebugMap::CompileUnitInfo::GetFileRangeMap(), 
which initialises the OSO range map once. In order to do that it iterates over 
all CUs, so changing this or adding a special case here seems possible.

https://github.com/llvm-mirror/lldb/blob/59608853be9b52d3c01609196d152b3e3dbb4dac/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp#L172

What do you think?

Best
Stefan

> On 11. Sep 2018, at 18:03, Frédéric Riss  wrote:
> 
> 
>> On Sep 11, 2018, at 8:48 AM, Greg Clayton > > wrote:
>> 
>>> 
>>> On Sep 11, 2018, at 2:55 AM, Stefan Gränitz >> > wrote:
>>> 
>>> 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 objects have more 
>>> than that:
>>> 
>>> void SymbolFileDWARFDebugMap::InitOSO() {
>>> ...
>>>   const uint32_t oso_index_count =
>>> symtab->AppendSymbolIndexesWithTypeAndFlagsValue(
>>> eSymbolTypeObjectFile, k_oso_symbol_flags_value, oso_indexes);
>>> ...
>>>   m_compile_unit_infos.resize(oso_index_count); // <—— one CU per OSO entry 
>>> in the Symtab
>>> 
>>>   for (uint32_t i = 0; i < oso_index_count; ++i) {
>>> const uint32_t so_idx = oso_indexes[i] - 1;
>>> const uint32_t oso_idx = oso_indexes[i];
>>> const Symbol *so_symbol = symtab->SymbolAtIndex(so_idx);
>>> const Symbol *oso_symbol = symtab->SymbolAtIndex(oso_idx);
>>> ...
>>>   const Symbol *last_symbol = symtab->SymbolAtIndex(sibling_idx - 1);
>>>   m_compile_unit_infos[i].first_symbol_index = so_idx;
>>>   m_compile_unit_infos[i].last_symbol_index = sibling_idx - 1;
>>>   m_compile_unit_infos[i].first_symbol_id = so_symbol->GetID();
>>>   m_compile_unit_infos[i].last_symbol_id = last_symbol->GetID();
>>> 
>>> The symptom is that LLDB will only read debug_line for one CU and miss all 
>>> the rest. Thus, breakpoints in other CUs can’t be associated with line 
>>> information.
>>> 
>>> I wonder if there is a good way to populate the correct number of compile 
>>> units from the OSO entry at this point?

Re: [lldb-dev] Extract compile unit infos from OSO entries for LTO objects

[Stefan Gränitz via lldb-dev]

I made some progress on this and next to many small issues, I found that 
DWARFDebugAranges::FindAddress() returns 0 as the CU offset for my file 
addresses and wonder if this is expected?

DWARFDebugAranges::FindAddress() is supposed to read from .debug_aranges 
section or DW_AT_ranges attributes right? When dumping with llvm-dwarfdump, it 
looks like regular objects have exactly one DW_TAG_compile_unit and it has a 
DW_AT_ranges attribute. Same for the top-level DW_TAG_compile_unit in LTO 
objects, but all further DW_TAG_compile_unit tags have no DW_AT_ranges 
attribute here. The comment in DWARFUnit::BuildAddressRangeTable() states that 
Clang “emits DW_AT_ranges for DW_TAG_compile_units”.

Are the nested DW_TAG_compile_unit tags in my LTO object missing their 
DW_AT_ranges or is that expected?
It looks like FindAddress() would return the offset correctly if it was there 
and the fix may get simpler.

Top-level:
0x000b: DW_TAG_compile_unit
...
DW_AT_low_pc.  (0x)
DW_AT_ranges.  (0x0040
   [0x, 0x07de)
   [0x07f0, 0x33cd))

Nested:
0x000130b3: DW_TAG_compile_unit
...
DW_AT_low_pc   (0x3f50)
DW_AT_high_pc. (0xdd0f)


> As far as I can tell, we need the actual number of CUs only after we 
> discovered plugins.

Split that off into HasCompileUnits() and GetNumCompileUnits(). It works well 
so far. Also managed to extract the single CUs with correct offsets in the LTO 
object file once GetNumCompileUnits() calls InitOSO(). I kept the logic for 
associating the CUs with line ranges in the Symtab, so 
first/last_symbol_id/index are the same for all those CUs. Maybe the code needs 
a few more adjustments to support this, but so far I don’t see showstoppers.

Short recap for what works after the simple changes:
* We iterate over the actual CUs in 
BreakpointResolverFileLine::SearchCallback().
* For the matching CU, we get the actual list of support files and find the 
correct file_idx and line_entry in CompileUnit::ResolveSymbolContext().
* We correctly link the OSO line table for this CU (with some overhead due to 
overlapping symbol ranges, but IIUC it’s fine as we only pick the ones for the 
CU).


>>> IF you do make a patch, please remove any functions in 
>>> SymbolFileDWARFDebugMap that are dead code. 
>>> SymbolFileDWARFDebugMap::GetModuleByOSOIndex() seems to be dead. If that is 
>>> dead thenvSymbolFileDWARFDebugMap::GetObjectFileByOSOIndex() seems to be 
>>> dead also.

Yes both functions are dead and yes sure, I can include that in my patch. 
Another one is 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 2018, at 20:13, Stefan Gränitz via lldb-dev 
>  wrote:
> 
> 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 used to be that even if we had a dSYM 
>>> file, the loop that selected the symbol file plug-in would give each and 
>>> every symbol file plugin a chance ...
> 
> Ok makes total sense, kind of historical reason.
> 
>>> But that being said, in the past I re-ordered how the SymbolFile plug-ins 
>>> were initialized to always put SymbolFileDWARF first and if it finds DWARF 
>>> debug info or a dSYM file and has all the abilities then we stop looking 
>>> for symbol file plug-ins that can load the current file. [...] So as soon 
>>> as a SymbolFile plug-in can do everything we now stop.
> 
> Good to know!
> 
>> Note that counting the number of compile units can be done extremely cheaply 
>> (of course, except the cost of opening the file). Each unit as a header that 
>> contain its length (which gives you the next unit). I’m not sure we have a 
>> primitive that does this without parsing the DWARF, but it should be easy to 
>> add.
> 
> 
> Right, so we only need to parse the CU headers. That should be fast.
> Opening each candidate .o file for the relatively rare case of having 
> multiple CUs still sounds expensive, assuming that “thousands of .o files” 
> may actually happen.
> 
> CalculateAbilities() does indeed call GetNumCompileUnits(), but what it 
> really wants to know at this time is “do we have any CU in there”:
> 
> uint32_t SymbolFileDWARFDebugMap::CalculateAbilities() {
>   ...
>   const uint32_t oso_inde

Re: [lldb-dev] Extract compile unit infos from OSO entries for LTO objects

[Stefan Gränitz via lldb-dev]

Hi Paul, thanks for the clarification. Yes, that was my fault. The LTO object 
DWARF has multiple top-level compile unit tags and only the first one has a 
DW_AT_ranges attribute.

One more thought here: In DWARFDebugInfo::GetCompileUnitAranges() LLDB 
currently tries to read .debug_aranges and if it can’t, it falls back to 
reading DW_AT_ranges from the compile unit tags. Would you have  objections 
from constructing that range from DW_AT_low_pc and DW_AT_high_pc here, if they 
exist? IIUC code for a single compile unit is not guaranteed to be compact, but 
in practice it usually is right?

Thanks
Stefan

> On 18. Sep 2018, at 15:01, paul.robin...@sony.com wrote:
> 
> Are the nested DW_TAG_compile_unit tags in my LTO object missing their 
> DW_AT_ranges or is that expected?
>  
> Compile units should never be nested. That's invalid DWARF.  A unit is the 
> 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, September 14, 2018 11:57 AM
> To: LLDB Dev
> Subject: Re: [lldb-dev] Extract compile unit infos from OSO entries for LTO 
> objects
>  
> I made some progress on this and next to many small issues, I found that 
> DWARFDebugAranges::FindAddress() returns 0 as the CU offset for my file 
> addresses and wonder if this is expected?
>  
> DWARFDebugAranges::FindAddress() is supposed to read from .debug_aranges 
> section or DW_AT_ranges attributes right? When dumping with llvm-dwarfdump, 
> it looks like regular objects have exactly one DW_TAG_compile_unit and it has 
> a DW_AT_ranges attribute. Same for the top-level DW_TAG_compile_unit in LTO 
> objects, but all further DW_TAG_compile_unit tags have no DW_AT_ranges 
> attribute here. The comment in DWARFUnit::BuildAddressRangeTable() states 
> that Clang “emits DW_AT_ranges for DW_TAG_compile_units”.
>  
> Are the nested DW_TAG_compile_unit tags in my LTO object missing their 
> DW_AT_ranges or is that expected?
> It looks like FindAddress() would return the offset correctly if it was there 
> and the fix may get simpler.
>  
> Top-level:
> 0x000b: DW_TAG_compile_unit
> ...
> DW_AT_low_pc.  (0x)
> DW_AT_ranges.  (0x0040
>[0x, 0x07de)
>[0x07f0, 0x33cd))
>  
> Nested:
> 0x000130b3: DW_TAG_compile_unit
> ...
> DW_AT_low_pc   (0x3f50)
> DW_AT_high_pc. (0xdd0f)
>  
> 
> 
> As far as I can tell, we need the actual number of CUs only after we 
> discovered plugins.
>  
> Split that off into HasCompileUnits() and GetNumCompileUnits(). It works well 
> so far. Also managed to extract the single CUs with correct offsets in the 
> LTO object file once GetNumCompileUnits() calls InitOSO(). I kept the logic 
> for associating the CUs with line ranges in the Symtab, so 
> first/last_symbol_id/index are the same for all those CUs. Maybe the code 
> needs a few more adjustments to support this, but so far I don’t see 
> showstoppers.
>  
> Short recap for what works after the simple changes:
> * We iterate over the actual CUs in 
> BreakpointResolverFileLine::SearchCallback().
> * For the matching CU, we get the actual list of support files and find the 
> correct file_idx and line_entry in CompileUnit::ResolveSymbolContext().
> * We correctly link the OSO line table for this CU (with some overhead due to 
> overlapping symbol ranges, but IIUC it’s fine as we only pick the ones for 
> the CU).
>  
>  
> IF you do make a patch, please remove any functions in 
> SymbolFileDWARFDebugMap that are dead code. 
> SymbolFileDWARFDebugMap::GetModuleByOSOIndex() seems to be dead. If that is 
> dead thenvSymbolFileDWARFDebugMap::GetObjectFileByOSOIndex() seems to be dead 
> also.
>  
> Yes both functions are dead and yes sure, I can include that in my patch. 
> Another one is 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 2018, at 20:13, Stefan Gränitz via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
>  
> 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 

[lldb-dev] [CMake] LLDB framework / shared library

[Stefan Gränitz via lldb-dev]

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 work is still todo for the LLDB shared library/framework (for simplicity I 
will call it LLDB.framework). It would be great to know, if you have concerns 
or comments on the following points:

(1) The liblldb target builds the actual LLDB.framework, while the 
lldb-framework target adds headers, symlinks, etc. What is the reason for this 
separation? Can I merge that into one target with post-build steps?

(2) In previous reviews there was an effort to centralize the code for building 
LLDB.framework, which makes sense to me. With the current LLDBFramework.cmake 
approach, however, it’s spread over at least 3 different files 
(lldb/CMakeLists.txt for init and lldb/source/API/CMakeLists.txt for actual 
definition). In a similar case downstream, I did all that in a single 
CMakeLists.txt in the source folder. While I see that LLDBFramework affects the 
whole project, I don’t see why we need a separate LLDBFramework.cmake (BTW 
upstream it’s included only once). Do you think I can move things to 
lldb/source/API/CMakeLists.txt where possible?

(3) Currently the build directory for LLDB.framework is determined from 
LLDB_FRAMEWORK_INSTALL_DIR, which I think is a little confusing. Can I clean 
this up? (e.g. having a LLDB_FRAMEWORK_BUILD_DIR)

(4) With Xcode, executables are emitted in bin and copied to LLDB.framework 
where necessary. CMake emits them into LLDB.framework directly and creates 
symlinks to bin. With LLVM_EXTERNALIZE_DEBUGINFO on Darwin, this has the 
effect, that by default their dSYMs will end up in LLDB.framework. Thus, I 
would prefer the Xcode behaviour here.

(5) Couldn’t (4) also simplify the INCLUDE_IN_SUITE logic? I would consider it 
to be LLDB.framework’s responsibility to set dependencies and adjust RPATHs for 
all required artefacts. The tools wouldn’t need to care about that (though, 
they could still check LLDB_BUILD_FRAMEWORK). The RPATH-login for case 
ARG_INCLUDE_IN_SUITE && LLDB_BUILD_FRAMEWORK is quite complicated though and I 
wonder if there are strong reasons not to do that. What do you think?

(6) Just out of interest: why is LLDB_BUILD_FRAMEWORK is not supported on CMake 
< 3.7?

Best
Stefan



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

Re: [lldb-dev] [CMake] LLDB framework / shared library

[Stefan Gränitz via lldb-dev]

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.

I will see how far I get without changing the processing order. I am a little 
afraid about Pandora's box here. Anyway, thanks for the explanation and 
proposal!

Had a look at the history and it turned out the reason for the 3.7 requirement 
was a bug in CMake (https://gitlab.kitware.com/cmake/cmake/issues/16363). There 
was a workaround, but it was dropped (https://reviews.llvm.org/rLLDB289841). 
Policy-wise CMake always acts as if it was cmake_minimum_required, so I am 
always sceptic about version checks, but for a bug like this it seems fine. 
Let’s keep it as long as cmake_minimum_required is below.

Best
Stefan

> On 10. Nov 2018, at 11:22, Pavel Labath  wrote:
> 
> Hello Stefan,
> 
> first off, I want to point out that although I spent a lot of time
> digging through our cmake files, I am not using the framework build, nor
> am familiar with it's details.
> 
> I also don't know why the framework was split into multiple targets.
> What I do know is that we then ended up adding extra indirections so
> that we can make setting up dependencies easier (lldb can just depend on
> ${LLDB_SUITE_TARGET} without knowing whether framework was enabled or
> not). If you can merge everything into a single target, then this
> indirection could also go away.
> 
> Your ideas sound reasonable to me. As Alex points out, centralizing
> everything to API/CMakeLists.txt may be tricky, although I agree that is
> the natural place to do this sort of thing. The trickyness comes from
> the fact that our cmake files are not processed in dependency order.
> Although this would be somewhat unconventional, I wouldn't be opposed to
> changing the cmake processing order so that it more closely matches the
> dependencies. If that makes things easier for you, that is.
> 
> One way to achieve this would be to take out source/API and
> tools/debugserver invocations out of source and tools CMakeLists.txt
> files, respectively. and put them into the top level file. So then the
> top level file would do something like:
> ```
> add_subdirectory(source) # Build all consituent libraries
> 
> # Tools going into the lldb framework
> add_subdirectory(tools/debugserver)
> add_subdirectory(tools/argdumper)
> ...
> 
> add_subdirectory(source/API) # Build LLDB.framework (or liblldb) itself
> add_subdirectory(tools) # Build tools that depend on the framework
> ```
> 
> This could be cleaned up if we moved the source code around, but I'm not
> sure we want to take that hit (I don't think it's worth it). Also, it's
> just an idea, I don't know whether that will make your job easier or not.
> 
> Good luck,
> pavel
> 
> On 09/11/18 21:31, Alex Langford wrote:
>> Hi Stefan,
>> 
>> Thanks for taking the time to improve LLDB's CMake infrastructure!
>> 
>> (1) I don't entirely remember the reason I had separated them out into 
>> separate targets. A post-build step would be fine, so feel free to merge 
>> these.
>> (2) I have no problems with this. If I remember correctly, I wanted to put 
>> everything into LLDBFramework.cmake originally and include it if 
>> LLDB_BUILD_FRAMEWORK got set, but that proved more difficult than I 
>> realized. I think what you are suggesting is better than what I ended up 
>> doing. Feel free to make that change.
>> (3) I think this is a good idea. I found this confusing as well.
>> (4) If that is the case, I think I agree that the Xcode behavior is better. 
>> (5) I'm not sure that this is going to actually simplify things. I don't 
>> think it's possible to do in source/API/CMakeLists.txt because the tools 
>> haven't been added as targets yet. With the current CMake logic, you could 
>> pull this logic into its own section that happens after the tools are added 
>> as targets. I don't find this any better than what we have now.
>> (6) I'm not sure why this is the case actually. I believe this was added by 
>> beanz originally, I just moved this check to be closer to the beginning of 
>> the build. If it works with CMake versions less than 3.7 then I have no 
>> issues with removing it.
>> 
>> Let me know if something is unclear or you have further questions/concerns.
>> 
>> Alex
>> 
>> 
>> On 11/9/18, 9:38 AM, "sgraen...@apple.com on behalf of Stefan Gränitz" 
>>  wrote:
>> 
>>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 work is still todo for the LLDB shared library/framework (for 
>> simplicity I will call it LLDB.framework). It would be great to kno

[lldb-dev] [CMake] LLDB_TEST_(C/CXX)_COMPILER in patches for standalone and testing

[Stefan Gränitz via lldb-dev]

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 deprecates 
LLDB_TEST_C/CXX_COMPILER in favor of a unified LLDB_TEST_COMPILER (for details 
on the change itself, let's discuss in the review). 
As this may affect build bot configurations etc., the old parameters are only 
marked deprecated for now and will continue to work. I imagined to phase them 
out until the 8.0 release. What do you think?

The other related reviews are linked below.

Best
Stefan

--

[1] https://bugs.llvm.org/show_bug.cgi?id=40201 

[2] https://reviews.llvm.org/D56399 
[3] https://reviews.llvm.org/D56400 
[4] https://reviews.llvm.org/D56440 
[5] https://reviews.llvm.org/D56443 

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

Re: [lldb-dev] [RFC] Using Sphinx to generate documentation

[Stefan Gränitz via lldb-dev]

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 written in HTML which is hard to maintain. We 
> have quite a bit of HTML code checked in which can make it hard to 
> differentiate between documentation written by us and documentation generated 
> by a tool. Furthermore I think text/RST files provide a lower barrier for new 
> or casual contributors to fix or update.
> 
> In line with the other LLVM projects I propose generating the documentation 
> with Sphix. I created a patch (https://reviews.llvm.org/D55376 
> ) that adds a new target docs-lldb-html when 
> -DLLVM_ENABLE_SPHINX:BOOL is enabled. I've ported over some pages to give an 
> idea of what this would look like in-tree. Before continuing with this rather 
> tedious work I'd like to get feedback form the community.
> 
> Initially I started with the theme used by Clang because it's a default theme 
> and doesn't require configuration. If we want to keep the sidebar we could 
> use the one used by LLD.
> 
> Please let me know what you think.
> 
> Thanks,
> Jonas
> ___
> 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] [RFC] Using Sphinx to generate documentation

[Stefan Gränitz via lldb-dev]

Hey Jonas that looks great! And what a nice way to do the review.

Two of the pages from "RESOURCES" are in the new docs now: Testing LLDB and The 
SB API Coding Rules
Will they be removed from the root page and/or do the others follow?

Added a few notes on escape characters to the review.

> The biggest issue is that the GDB to LLDB command map is totally unreadable 
> with the RST generated table. I spent a little time tweaking the CSS, but 
> this needs some attention. Worst case we'll have to have an HTML table here. 

GDB to LLDB map is one of  the most viewed pages in the docs right? I had a 
look and got the below result with a few CSS tweaks in the layout "debugger":

p, blockquote { margin-top: 0px; margin-bottom: 0px; }
tr.row-even { background: #eee; }
tr.row-odd td { font-family: monospace; padding-bottom: 15px; }
table.docutils { width: 100%; }

The last one sets full width on all tables. About columns having 
content-specific width, I am not sure. Might be interesting to see with a 50/50 
setting in all 's.
Maybe we could also get rid of the column headers? The prompts say it all :)




> On 8. Jan 2019, at 19:12, Jonas Devlieghere  wrote:
> 
> For those interested, I've uploaded the latest version of the generated HTML:
> 
> https://jonasdevlieghere.com/static/lldb/ 
> <https://jonasdevlieghere.com/static/lldb/>
> 
> I'd have to double check but I think that almost everything was ported over. 
> The biggest issue is that the GDB to LLDB command map is totally unreadable 
> with the RST generated table. I spent a little time tweaking the CSS, but 
> this needs some attention. Worst case we'll have to have an HTML table here. 
> 
> Theme-wise I went with the one used by clang. I think it's the most readable 
> and I personally really like the local ToC. The disadvantage is that it 
> doesn't have a sidebar, so you have to navigate back to "contents" in the top 
> right corner.
> 
> The alternative is the LLVM theme where we can have Sphinx generate the 
> global ToC in the sidebar. When I tried this it was missing the section names 
> (e.g. "Goals & Status" as seen on the main page).  Another issue is that the 
> local ToC gets totally lost beneath it because everything doesn'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  <mailto:jo...@devlieghere.com>> wrote:
> 
> 
> On Tue, Jan 8, 2019 at 8:52 AM Stefan Gränitz via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 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?
> 
> Thanks for the heads up Stefan. This should be fine, I'll copy over your 
> change in the rst files. 
> 
> 
> Best
> Stefan
> 
>> On 6. Dec 2018, at 18:02, Jonas Devlieghere via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> Hi everyone,
>> 
>> The current LLDB website is written in HTML which is hard to maintain. We 
>> have quite a bit of HTML code checked in which can make it hard to 
>> differentiate between documentation written by us and documentation 
>> generated by a tool. Furthermore I think text/RST files provide a lower 
>> barrier for new or casual contributors to fix or update.
>> 
>> In line with the other LLVM projects I propose generating the documentation 
>> with Sphix. I created a patch (https://reviews.llvm.org/D55376 
>> <https://reviews.llvm.org/D55376>) that adds a new target docs-lldb-html 
>> when -DLLVM_ENABLE_SPHINX:BOOL is enabled. I've ported over some pages to 
>> give an idea of what this would look like in-tree. Before continuing with 
>> this rather tedious work I'd like to get feedback form the community.
>> 
>> Initially I started with the theme used by Clang because it's a default 
>> theme and doesn't require configuration. If we want to keep the sidebar we 
>> could use the one used by LLD.
>> 
>> Please let me know what you think.
>> 
>> Thanks,
>> Jonas
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> <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] [ASTImporter][macOS] Cannot link debugserver, keychain error

[Stefan Gränitz via lldb-dev]

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_DEBUGSERVER=ON, though that may 
> change in the future (/me points at Stefan).


My changes that landed last week kept the default behavior intact: build 
debugserver from source and code sign with lldb_codesign.
In order to change this you can configure with:

* -DLLDB_USE_SYSTEM_DEBUGSERVER=ON to use a copy of the system's debugserver 
instead
* -DLLDB_NO_DEBUGSERVER=ON to have no debugserver at all

Best
Stefan

> On 10. Dec 2018, at 20:28, Gábor Márton via lldb-dev 
>  wrote:
> 
> Hi,
> 
> Recently I have updated the LLDB source and now I cannot link the debugserver.
> I guess, the problem is started in one of the commits at last week, because 
> before that I had not experienced it.
> Any help would be appreciated. I'd like to get a command line only solution 
> because I am building via ssh, so I can't click on any windows.
> With respect to Clang/ASTImporter,
> would it be a solution to disable the build of the debugserver and use the 
> system debugserver? Do you think I would loose some ASTImporter related test 
> coverage? How to disable the build of the debugserver?
> 
> Thanks,
> Gabor
> 
> [4/172] Linking CXX executable bin/debugserver
> FAILED: bin/debugserver
> : && /usr/local/opt/ccache/libexec/c++  -fPIC -fvisibility-inlines-hidden 
> -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -fmodules 
> -fmodules-cache-path=/Users/egbomrt/llvm/build/release_assert/module.cache 
> -fcxx-modules -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
> -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough 
> -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
> -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color 
> -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing 
> -Wno-deprecated-register -Wno-vla-extension 
> -Wno-gnu-zero-variadic-macro-arguments -Wno-zero-length-array 
> -Wno-extended-offsetof -O3  -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
>  -Wl,-search_paths_first -Wl,-headerpad_max_install_names -stdlib=libc++ 
> -Wl,-sectcreate,__TEXT,__info_plist,/Users/egbomrt/llvm/git/llvm/tools/lldb/tools/debugserver/source/../resources/lldb-debugserver-Info.plist
> -Wl,-dead_strip 
> tools/lldb/tools/debugserver/source/CMakeFiles/debugserver.dir/debugserver.cpp.o
>   -o bin/debugserver  -Wl,-rpath,@loader_path/../lib 
> lib/liblldbDebugserverCommon.a -framework Cocoa -framework CoreFoundation 
> -framework Foundation lib/liblldbDebugserverArchSupport.a 
> lib/liblldbDebugserverDarwin_DarwinLog.a -lcompression && cd 
> /Users/egbomrt/llvm/build/release_assert/tools/lldb/tools/debugserver/source 
> && /usr/local/Cellar/cmake/3.12.4/bin/cmake -E env 
> CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
>  codesign --force --sign lldb_codesign --entitlements 
> /Users/egbomrt/llvm/git/llvm/tools/lldb/tools/debugserver/source/../../../resources/debugserver-macosx-entitlements.plist
>  /Users/egbomrt/llvm/build/release_assert/bin/debugserver
> error: The specified item could not be found in the keychain.
> ___
> 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] [llvm-dev] [8.0.0 Release] rc1 has been tagged

[Stefan Gränitz via lldb-dev]

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 was just tagged (from the branch at r351980).
>
> It took a little longer than planned, but it's looking good.
>
> Please run the test script, share your results, and upload binaries.
>
> I'll get the source tarballs and docs published as soon as possible,
> and binaries as they become available.
>
> Thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
https://weliveindetail.github.io/blog/
https://cryptup.org/pub/stefan.graen...@gmail.com

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

[lldb-dev] [Docs] Unify build instructions

[Stefan Gränitz via lldb-dev]

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 
instructions for the monorepo?

* In "Building LLDB with CMake and Other Generators": Using an IDE generator 
for all of LLDB/LLVM/Clang/libc++ results in a huge workspace that is not 
really manageable anymore (at least in Xcode). Do you think it's worth 
explaining here that we can generate the IDE workspace for standalone LLDB and 
have the dependencies in a provided Ninja build-tree?

* Either as another section or (maybe for now) as a note in the existing per-OS 
sections, I would explain how to use the CMake caches. I think that could be 
useful with the above two proposals.

What do you think?
I will rebase my current state on yours on Monday and then submit a proposal 
during the week.

Best
Stefan

> On 3. Jul 2019, at 22:51, Jonas Devlieghere via Phabricator 
>  wrote:
> 
> JDevlieghere closed this revision.
> JDevlieghere added a comment.
> 
> Landed in rL365081 
> 
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D64154/new/
> 
> https://reviews.llvm.org/D64154
> 
> 
> 

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

Re: [lldb-dev] Cannot use system debugserver for testing

[Stefan Gränitz via lldb-dev]

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
happens again (or to anyone else), a clean build seems to be a good
first step.

Best,
Stefan

On 19/07/2019 19:36, Gábor Márton wrote:

> Actually, it is embarrassing (perhaps for macOS and not for me) that
> after a reboot the problem is gone.
> Perhaps after "sudo /usr/sbin/DevToolsSecurity --enable" a reboot is
> required, but could not find anything official about that.
>
> On Fri, Jul 19, 2019 at 7:20 PM Gábor Márton  > wrote:
>
> This might not be related to the debugserver, I just realized that
> I get 
> "error: process exited with status -1 (Error 1)"
> even with the simplest main.c.
> This may be some kind of security issue on mac OS...
> Though I've checked and I have SIP disabled and I have executed
> "sudo /usr/sbin/DevToolsSecurity --enable".
>
> On Fri, Jul 19, 2019 at 4:46 PM Gábor Márton
> mailto:martongab...@gmail.com>> wrote:
>
> Hi Stefan,
>
> Since the commit
> "[CMake] Always build debugserver on Darwin and allow tests to
> use the system's one"
> I cannot use the system debugserver for testing.
> I receive the following error message from lldb when I execute
> "ninja check-lldb":
> ```
> runCmd: run
> runCmd failed!
> error: process exited with status -1 (Error 1)
> ```
>
> I do set up "-DLLDB_USE_SYSTEM_DEBUGSERVER=ON" with cmake so I see
> ```
> -- LLDB tests use out-of-tree debugserver:
> 
> /Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Resources/debugserver
> ```
>
> Also, I have inspected the following test output
> ```
> Command invoked: /usr/bin/python
> /Users/egbomrt/llvm2/git/llvm/tools/lldb/test/dotest.py -q
> --arch=x86_64 -s
> /Users/egbomrt/llvm2/build/release_assert/lldb-test-traces
> --build-dir
> /Users/egbomrt/llvm2/build/release_assert/lldb-test-build.noindex
> -S nm -u CXXFLAGS -u CFLAGS --executable
> /Users/egbomrt/llvm2/build/release_assert/./bin/lldb
> --dsymutil
> /Users/egbomrt/llvm2/build/release_assert/./bin/dsymutil
> --filecheck
> /Users/egbomrt/llvm2/build/release_assert/./bin/FileCheck -C
> /Users/egbomrt/llvm2/build/release_assert/bin/clang
> --codesign-identity - --out-of-tree-debugserver --arch x86_64
> -t --env TERM=vt100 -p TestCModules.py --results-port 49931 -S
> nm --inferior -p TestCModules.py
> 
> /Users/egbomrt/llvm2/git/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/c/modules
> --event-add-entries worker_index=0:int
>   1 out of 736 test suites processed - TestCModules.py
> ```
> so it seems like the argument for --out-of-tree-debugserver is
> missing...
>
> Could you please advise?
>
> Thank you,
> Gabor
>
-- 
https://flowcrypt.com/pub/stefan.graen...@gmail.com

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

Re: [lldb-dev] Cannot use system debugserver for testing

[Stefan Gränitz via lldb-dev]

> 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 system binaries, you may need to disable SIP.

On 22/07/2019 16:14, Gábor Márton wrote:
> I am still struggling with this issue. Now I decided to work with the
> codesigned version of the debugserver, becasue I had an error when I
> tried to use the system debugserver.
> So I've run scripts/macos-setup-codesign.sh
> After a reboot and fresh build (I have removed the CMakeCache.txt and
> the whole build dir) I have the debugserver signed:
> ```
> $ codesign -d ~/llvm2/build/release_assert/bin/debugserver
> Executable=/Users/egbomrt/llvm2/build/release_assert/bin/debugserver
> Identifier=com.apple.debugserver
> Format=Mach-O thin (x86_64)
> CodeDirectory v=20100 size=38534 flags=0x0(none) hashes=1197+5
> location=embedded
> VersionPlatform=1
> VersionMin=658944
> VersionSDK=658944
> Hash type=sha256 size=32
> CandidateCDHash sha256=7b475cfa7127c84281ceb206093d13dd464dad74
> Hash choices=sha256
> Page size=4096
> CDHash=7b475cfa7127c84281ceb206093d13dd464dad74
> Signature size=1611
> Authority=lldb_codesign
> Signed Time=2019. Jul 22. 15:26:29
> Info.plist entries=6
> TeamIdentifier=not set
> Sealed Resources=none
> Internal requirements count=1 size=100
> $
> ```
>
> So far so good.
> But then when I try to use lldb I have permission problems:
> ```
> 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)*
> (lldb) ^D
> egbomrt@msmarple ~/llvm2/build/release_assert $
> ```
>
> However, as root I can use lldb:
> ```
> egbomrt@msmarple ~/llvm2/build/release_assert $ sudo ./bin/lldb /bin/ls
> (lldb) target create "/bin/ls"
> Current executable set to '/bin/ls' (x86_64).
> (lldb) r
> Process 28052 launched: '/bin/ls' (x86_64)
> .ninja_deps                     compile_commands.json
> .ninja_log                      docs
> CMakeCache.txt                  examples
> CMakeDoxyfile.in                include
> ...
> Process 28052 exited with status = 0 (0x)
> (lldb) ^D
> egbomrt@msmarple ~/llvm2/build/release_assert $
> ```
>
> Is it possible to codesign in a way that a regular user can run the
> built debugserver? Or what else could be the reason behind this
> permission problem?
>
> Thanks,
> Gabor
>
> On Fri, Jul 19, 2019 at 11:47 PM Stefan Gränitz
> mailto:stefan.graen...@gmail.com>> wrote:
>
> 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 happens again (or to anyone else), a clean build
> seems to be a good first step.
>
> Best,
> Stefan
>
> On 19/07/2019 19:36, Gábor Márton wrote:
>
>> Actually, it is embarrassing (perhaps for macOS and not for me)
>> that after a reboot the problem is gone.
>> Perhaps after "sudo /usr/sbin/DevToolsSecurity --enable" a reboot
>> is required, but could not find anything official about that.
>>
>> On Fri, Jul 19, 2019 at 7:20 PM Gábor Márton
>> mailto:martongab...@gmail.com>> wrote:
>>
>> This might not be related to the debugserver, I just realized
>> that I get 
>> "error: process exited with status -1 (Error 1)"
>> even with the simplest main.c.
>> This may be some kind of security issue on mac OS...
>> Though I've checked and I have SIP disabled and I have
>> executed "sudo /usr/sbin/DevToolsSecurity --enable".
>>
>> On Fri, Jul 19, 2019 at 4:46 PM Gábor Márton
>> mailto:martongab...@gmail.com>> wrote:
>>
>> Hi Stefan,
>>
>> Since the commit
>> "[CMake] Always build debugserver on Darwin and allow
>> tests to use the system's one"
>> I cannot use the system debugserver for testing.
>> I receive the following error message from lldb when I
>> execute "ninja check-lldb":
>> ```
>> runCmd: run
>> runCmd failed!
>> error: process exited with status -1 (Error 1)
>> ```
>>
>> I do set up "-DLLDB_USE_SYSTEM_DEBUGSERVER=ON" with cmake
>> so I see
>> ```
>> -- LLDB tests use out-of-tree debugserver:
>> 
>> /Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Resources/debugserver
>> ```
>>
>> Also, I have inspected the following test output
>> ```
>> Command invoked: 

Re: [lldb-dev] Cannot use system debugserver for testing

[Stefan Gränitz via lldb-dev]

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 Integrity Protection status: disabled.
> egbomrt@msmarple ~/llvm2/build/release_assert $ ./bin/lldb ~/a.out
> (lldb) target create "/Users/egbomrt/a.out"
> Current executable set to '/Users/egbomrt/a.out' (x86_64).
> (lldb) r
> error: process exited with status -1 (Error 1)
> (lldb) ^D
> egbomrt@msmarple ~/llvm2/build/release_assert $ ls -la ~/a.out
> -rwxr-xr-x  1 egbomrt  admin  8736 Júl 22 16:16 /Users/egbomrt/a.out
> egbomrt@msmarple ~/llvm2/build/release_assert $
> ```
>
> On Mon, Jul 22, 2019 at 4:29 PM Stefan Gränitz
> mailto:stefan.graen...@gmail.com>> wrote:
>
>> 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 system binaries, you may need to disable SIP.
>
> On 22/07/2019 16:14, Gábor Márton wrote:
>> I am still struggling with this issue. Now I decided to work with
>> the codesigned version of the debugserver, becasue I had an error
>> when I tried to use the system debugserver.
>> So I've run scripts/macos-setup-codesign.sh
>> After a reboot and fresh build (I have removed the CMakeCache.txt
>> and the whole build dir) I have the debugserver signed:
>> ```
>> $ codesign -d ~/llvm2/build/release_assert/bin/debugserver
>> Executable=/Users/egbomrt/llvm2/build/release_assert/bin/debugserver
>> Identifier=com.apple.debugserver
>> Format=Mach-O thin (x86_64)
>> CodeDirectory v=20100 size=38534 flags=0x0(none) hashes=1197+5
>> location=embedded
>> VersionPlatform=1
>> VersionMin=658944
>> VersionSDK=658944
>> Hash type=sha256 size=32
>> CandidateCDHash sha256=7b475cfa7127c84281ceb206093d13dd464dad74
>> Hash choices=sha256
>> Page size=4096
>> CDHash=7b475cfa7127c84281ceb206093d13dd464dad74
>> Signature size=1611
>> Authority=lldb_codesign
>> Signed Time=2019. Jul 22. 15:26:29
>> Info.plist entries=6
>> TeamIdentifier=not set
>> Sealed Resources=none
>> Internal requirements count=1 size=100
>> $
>> ```
>>
>> So far so good.
>> But then when I try to use lldb I have permission problems:
>> ```
>> 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)*
>> (lldb) ^D
>> egbomrt@msmarple ~/llvm2/build/release_assert $
>> ```
>>
>> However, as root I can use lldb:
>> ```
>> egbomrt@msmarple ~/llvm2/build/release_assert $ sudo ./bin/lldb
>> /bin/ls
>> (lldb) target create "/bin/ls"
>> Current executable set to '/bin/ls' (x86_64).
>> (lldb) r
>> Process 28052 launched: '/bin/ls' (x86_64)
>> .ninja_deps                     compile_commands.json
>> .ninja_log                      docs
>> CMakeCache.txt                  examples
>> CMakeDoxyfile.in                include
>> ...
>> Process 28052 exited with status = 0 (0x)
>> (lldb) ^D
>> egbomrt@msmarple ~/llvm2/build/release_assert $
>> ```
>>
>> Is it possible to codesign in a way that a regular user can run
>> the built debugserver? Or what else could be the reason behind
>> this permission problem?
>>
>> Thanks,
>> Gabor
>>
>> On Fri, Jul 19, 2019 at 11:47 PM Stefan Gränitz
>> mailto:stefan.graen...@gmail.com>> wrote:
>>
>> 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 happens again (or to anyone else),
>> a clean build seems to be a good first step.
>>
>> Best,
>> Stefan
>>
>> On 19/07/2019 19:36, Gábor Márton wrote:
>>
>>> Actually, it is embarrassing (perhaps for macOS and not for
>>> me) that after a reboot the problem is gone.
>>> Perhaps after "sudo /usr/sbin/DevToolsSecurity --enable" a
>>> reboot is required, but could not find anything official
>>> about that.
>>>
>>> On Fri, Jul 19, 2019 at 7:20 PM Gábor Márton
>>> mailto:martongab...@gmail.com>> wrote:
>>>
>>> This might not be related to the debugserver, I just
>>> realized that I ge

Re: [lldb-dev] [llvm-dev] ORC JIT Weekly #7 -- JITEventListener support and Swift Immediate Mode Migration

[Stefan Gränitz via lldb-dev]

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()` here:
https://code.woboq.org/llvm/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.cpp.html#_ZNK12_GLOBAL__N_121LoadedMachOObjectInfo17getObjectForDebugERKN4llvm6object10ObjectFileE

Best,
Stefan

On 10/03/2020 09:28, Geoff Levner via llvm-dev wrote:
> +1. Once ORC JIT supports debugging and profiling, it will have
> everything we need.
>
> Thanks, Lang!
>
>
> On Mon, Mar 9, 2020 at 9:21 PM Frank Tetzel via llvm-dev
> mailto:llvm-...@lists.llvm.org>> wrote:
>
> Hi Lang,
>
> > First: there is a preview patch up at
> https://reviews.llvm.org/D75838
> > to enable use of JITEventListeners in RTDyldObjectLinkingLayer. I've
> > only done very preliminary testing on it, but was able to debug
> > simple JIT'd programs on Linux using the GDB registration listener.
> > If you've been wanting to move to ORC but held up by lack of
> debugger
> > / profiler registration, chime in on the review -- I'd appreciate
> > feedback and help with testing. I will also post a bug tomorrow for
> > investigating similar (or hopefully better) debugger registration
> > functionality for JITLink.
>
> Does this also include support for PerfEventListener for profiling
> with
> perf?
>
> I think, debugging and profiling support is very important for a JIT
> engine. I could never get it to work with older LLVM versions. Is
> there
> example code somewhere available?
>
> Best regards,
> Frank
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
https://flowcrypt.com/pub/stefan.graen...@gmail.com

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