This is an archive of the discontinued LLVM Phabricator instance.

Differential D65128

[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)
ClosedPublic

Authored by JDevlieghere on Jul 22 2019, 6:32 PM.

Details

Reviewers
jasonmolenda
jingham
labath
• espindola
shafik
davide
xiaobai
martong
Commits
rG63e5fb76ecfe: [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)
rL366936: [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)
rLLDB366936: [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)
Summary

This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.

So instead of writing:

if (log)
  log->Printf("%s\n", str);

You'd write:

LLDB_LOG(log, "%s\n", str);

This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.

find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +

Diff Detail

Event Timeline

JDevlieghere created this revision.Jul 22 2019, 6:32 PM
Herald added a reviewer: martong. · View Herald TranscriptJul 22 2019, 6:32 PM
Herald added a reviewer: • espindola. · View Herald Transcript
Herald added a reviewer: shafik. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
Herald added subscribers: teemperor, atanasyan, MaskRay and 8 others. · View Herald Transcript
JDevlieghere added reviewers: davide, xiaobai.Jul 22 2019, 6:34 PM
Herald added subscribers: • wuzish, rnkovacs. · View Herald TranscriptJul 22 2019, 6:34 PM
jingham added a comment.Jul 22 2019, 6:43 PM

IIUC, LLDB_LOG already adds the file and function. A bunch of these logs are also adding FUNCTION, so that's probably going to come out twice now. You should probably remove the duplicates.

jingham requested changes to this revision.Jul 22 2019, 6:52 PM

Actually, I don't want this change as is. Some logs - like the expression and step logs - are laid out for readability, and LLDB_LOG automatically adds the file & function which will make them much harder to read.

We need a variant that doesn't inject this information, and then this change should use that variant. Or we can remove the file & function from LLDB_LOG and decide to let the people add those as they wish. I don't have a strong opinion one way or the other, but I certainly don't want this extra noise in the step or expression logs.

This revision now requires changes to proceed.Jul 22 2019, 6:52 PM
JDevlieghere added a comment.Jul 22 2019, 6:57 PM
In D65128#1596809, @jingham wrote:

Actually, I don't want this change as is. Some logs - like the expression and step logs - are laid out for readability, and LLDB_LOG automatically adds the file & function which will make them much harder to read.

We need a variant that doesn't inject this information, and then this change should use that variant. Or we can remove the file & function from LLDB_LOG and decide to let the people add those as they wish. I don't have a strong opinion one way or the other, but I certainly don't want this extra noise in the step or expression logs.

I agree with you. I always use LLDB_LOG, but not because it includes the file and function, but because it's consistent, it gives me the ability to use the LLVM formatter, and I don't have to explicitly check whether the log is NULL or not. I can only speak for myself of course.

@labath Since you added the macro, what's your take on this? Do you care a lot about the file and function, and should we have two macros, one that includes this and one that doesn't? Or should we have just one macro, and have users decide whether they need this information or not?

labath added a comment.Jul 23 2019, 12:59 AM

I don't think you can make a change like this mechanically, and the reason is not the file-function prepending, but the fact that the two styles use a different format specifier syntax (printf vs. the llvm formatv thingy). If you change the function without changing the format strings, you just create a bunch of static log messages...

In D65128#1596813, @JDevlieghere wrote:
In D65128#1596809, @jingham wrote:

Actually, I don't want this change as is. Some logs - like the expression and step logs - are laid out for readability, and LLDB_LOG automatically adds the file & function which will make them much harder to read.

We need a variant that doesn't inject this information, and then this change should use that variant. Or we can remove the file & function from LLDB_LOG and decide to let the people add those as they wish. I don't have a strong opinion one way or the other, but I certainly don't want this extra noise in the step or expression logs.

I agree with you. I always use LLDB_LOG, but not because it includes the file and function, but because it's consistent, it gives me the ability to use the LLVM formatter, and I don't have to explicitly check whether the log is NULL or not. I can only speak for myself of course.

@labath Since you added the macro, what's your take on this? Do you care a lot about the file and function, and should we have two macros, one that includes this and one that doesn't? Or should we have just one macro, and have users decide whether they need this information or not?

The reason I added the file-function prepending stuff was because a lot of our logging statements do things like:

if(log)
  log->Printf("MyUsuallyVeryLongClassName::%s real stuff...", args..., __FUNCTION__);

This means that the Printf call usually does not fit a single line, and so each logging statement ends up taking at least three lines (together with the if(log) stuff). By making sure the origin of the log statement is automatically added to the message, I was hoping that we'd only log the actual interesting stuff, and so we'd have succinct log statements which don't interfere with the flow of the rest of the code (LLDB_LOG(log, "real stuff...", args...)).

So, that was the direction I wanted to take things in. However, I wouldn't say that has been entirely successful, so if you want to take a different direction now, that's fine with me. I just want to point out two things:

  • The file-function prepending stuff is optional. In fact it's not even enabled by default -- you have to pass a --file-function flag to the "log enable" command to get this behavior
  • The prepending code goes through a lot of trouble to make sure the file-function field is always of the same width. This means that if you have a log file which contains these things, you can just scroll to the right to avoid seeing them, or (assuming your editor supports block operations) easily cut them out.
JDevlieghere added a comment.EditedJul 23 2019, 7:36 AM
In D65128#1596964, @labath wrote:

I don't think you can make a change like this mechanically, and the reason is not the file-function prepending, but the fact that the two styles use a different format specifier syntax (printf vs. the llvm formatv thingy). If you change the function without changing the format strings, you just create a bunch of static log messages...

Thanks for pointing this out. Somehow I convinced myself that formatv supported both, but on further inspection that is not true. I guess we could change the format strings too, but I'm afraid that is a more controversial change.

In D65128#1596813, @JDevlieghere wrote:
In D65128#1596809, @jingham wrote:

Actually, I don't want this change as is. Some logs - like the expression and step logs - are laid out for readability, and LLDB_LOG automatically adds the file & function which will make them much harder to read.

We need a variant that doesn't inject this information, and then this change should use that variant. Or we can remove the file & function from LLDB_LOG and decide to let the people add those as they wish. I don't have a strong opinion one way or the other, but I certainly don't want this extra noise in the step or expression logs.

I agree with you. I always use LLDB_LOG, but not because it includes the file and function, but because it's consistent, it gives me the ability to use the LLVM formatter, and I don't have to explicitly check whether the log is NULL or not. I can only speak for myself of course.

@labath Since you added the macro, what's your take on this? Do you care a lot about the file and function, and should we have two macros, one that includes this and one that doesn't? Or should we have just one macro, and have users decide whether they need this information or not?

The reason I added the file-function prepending stuff was because a lot of our logging statements do things like:

if(log)
  log->Printf("MyUsuallyVeryLongClassName::%s real stuff...", args..., __FUNCTION__);

This means that the Printf call usually does not fit a single line, and so each logging statement ends up taking at least three lines (together with the if(log) stuff). By making sure the origin of the log statement is automatically added to the message, I was hoping that we'd only log the actual interesting stuff, and so we'd have succinct log statements which don't interfere with the flow of the rest of the code (LLDB_LOG(log, "real stuff...", args...)).

So, that was the direction I wanted to take things in. However, I wouldn't say that has been entirely successful, so if you want to take a different direction now, that's fine with me. I just want to point out two things:

  • The file-function prepending stuff is optional. In fact it's not even enabled by default -- you have to pass a --file-function flag to the "log enable" command to get this behavior
  • The prepending code goes through a lot of trouble to make sure the file-function field is always of the same width. This means that if you have a log file which contains these things, you can just scroll to the right to avoid seeing them, or (assuming your editor supports block operations) easily cut them out.

That explains my confusion as to it being part of the macro. I never noticed it showing up in the log, and this explains why.

martong resigned from this revision.Jul 23 2019, 8:00 AM
JDevlieghere updated this revision to Diff 211350.Jul 23 2019, 1:19 PM
JDevlieghere edited the summary of this revision. (Show Details)

Introduce LLDB_LOGF macro to support printf-style format strings.

labath accepted this revision.Jul 24 2019, 1:20 AM

I'm fine with this if Jim is.

lldb/source/Expression/IRExecutionUnit.cpp
601

looks like there are some if(log)s still remaining. Maybe the {} around the printf confused your vim macro?

jingham accepted this revision.Jul 24 2019, 10:05 AM

Sure, this is okay.

lldb/source/Expression/IRExecutionUnit.cpp
601

There will always be some "if (log)" statements. Whenever consing up the log message involves work, you should always say:

if (log) {

/// Do expensive work
LLDB_LOG...

}

Not saying that all the remaining "if (logs)" are for that reason, but then intent is NOT to remove all such statements as they serve a useful purpose.

This revision is now accepted and ready to land.Jul 24 2019, 10:05 AM
Closed by commit rL366936: [Logging] Replace Log::Printf with LLDB_LOG macro (NFC) (authored by JDevlieghere). · Explain WhyJul 24 2019, 10:59 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJul 24 2019, 10:59 AM
Herald added subscribers: llvm-commits, jrtc27. · View Herald Transcript
labath added inline comments.Jul 24 2019, 11:00 PM
lldb/source/Expression/IRExecutionUnit.cpp
601

I'm fine with if(log)s staying if they serve a purpose (or even if they're hard to remove in this patch). However, I would expect that with LLDB_LOG, they become much less frequently needed, because the formatter is much more powerful (e.g., there is no need to write a for loop just to print an array, etc.)

jingham added inline comments.Jul 25 2019, 10:50 AM
lldb/source/Expression/IRExecutionUnit.cpp
601

Yes, it's also not entirely obvious (YAY for macros!!!) that code in the LLDB_LOG* arguments doesn't get evaluated if log == nullptr, but that also reduces the need for standalone if (logs).

BTW, we were going to document somewhere that LLDB_LOG actually used format_providers but I didn't see that anywhere. I submitted:

https://reviews.llvm.org/D65293

to put this somewhere in the lldb sources. Not sure if this is the best place, or if there is more that it would be useful to add.

JDevlieghere mentioned this in D151764: [lldb] Support file and function names in LLDB_LOGF macro.May 30 2023, 4:45 PM
JDevlieghere mentioned this in rG6099d519bb83: [lldb] Support file and function names in LLDB_LOGF macro.Jun 6 2023, 12:25 PM

Large Diff

This large diff affects 191 files. Files without inline comments have been collapsed. Expand All Files

Revision Contents

PathSize
lldb/
include/
lldb/
Utility/
3 lines
source/
API/
100 lines
8 lines
10 lines
Breakpoint/
21 lines
13 lines
20 lines
3 lines
2 lines
Commands/
7 lines
Core/
14 lines
5 lines
113 lines
8 lines
39 lines
15 lines
11 lines
4 lines
114 lines
DataFormatters/
129 lines
67 lines
Expression/
19 lines
18 lines
42 lines
77 lines
294 lines
64 lines
12 lines
89 lines
36 lines
Host/
common/
39 lines
21 lines
3 lines
19 lines
31 lines
44 lines
6 lines
3 lines
linux/
39 lines
macosx/
objcxx/
43 lines
5 lines
posix/
128 lines
windows/
28 lines
Interpreter/
25 lines
Plugins/
ABI/
MacOSX-arm64/
5 lines
SysV-arm64/
5 lines
SysV-mips/
25 lines
SysV-mips64/
25 lines
SysV-ppc/
24 lines
SysV-ppc64/
42 lines
SysV-s390x/
19 lines
SysV-x86_64/
26 lines
Windows-x86_64/
24 lines
Architecture/
Mips/
8 lines
DynamicLoader/
Darwin-Kernel/
90 lines
Hexagon-DYLD/
50 lines
32 lines
MacOSX-DYLD/
82 lines
8 lines
29 lines
POSIX-DYLD/
97 lines
196 lines
Windows-DYLD/
42 lines
ExpressionParser/
Clang/
4 lines
30 lines
358 lines
228 lines
57 lines
3 lines
21 lines
24 lines
22 lines
179 lines
JITLoader/
GDB/
45 lines
LanguageRuntime/
CPlusPlus/
ItaniumABI/
67 lines
ObjC/
AppleObjCRuntime/
113 lines
12 lines
145 lines
56 lines
25 lines
7 lines
RenderScript/
RenderScriptRuntime/
8 lines
646 lines
10 lines
ObjectFile/
ELF/
95 lines
Mach-O/
19 lines
PECOFF/
49 lines
OperatingSystem/
Python/
54 lines
Platform/
Android/
28 lines
26 lines
MacOSX/
14 lines
16 lines
74 lines
76 lines
12 lines
14 lines
14 lines
14 lines
67 lines
10 lines
12 lines
POSIX/
26 lines
gdb-server/
105 lines
Process/
Darwin/
42 lines
194 lines
564 lines
18 lines
FreeBSD/
28 lines
57 lines
79 lines
Linux/
9 lines
9 lines
4 lines
31 lines
MacOSX-Kernel/
26 lines
88 lines
NetBSD/
4 lines
POSIX/
2 lines
Utility/
6 lines
8 lines
15 lines
9 lines
6 lines
10 lines
75 lines
elf-core/
2 lines
5 lines
gdb-remote/
68 lines
179 lines
79 lines
8 lines
7 lines
11 lines
500 lines
24 lines
48 lines
544 lines
8 lines
mach-core/
117 lines
ScriptInterpreter/
Python/
34 lines
StructuredData/
DarwinLog/
271 lines
SymbolFile/
DWARF/
167 lines
4 lines
44 lines
15 lines
SystemRuntime/
MacOSX/
55 lines
60 lines
52 lines
57 lines
14 lines
Symbol/
32 lines
2 lines
181 lines
4 lines
13 lines
8 lines
66 lines
35 lines
3 lines
38 lines
Target/
28 lines
5 lines
98 lines
667 lines
12 lines
13 lines
100 lines
152 lines
190 lines
55 lines
3 lines
40 lines
86 lines
5 lines
30 lines
3 lines
13 lines
47 lines
22 lines
4 lines
17 lines
14 lines
57 lines
16 lines
3 lines
Utility/
6 lines
11 lines
69 lines
tools/
lldb-server/
13 lines
unittests/
Host/
2 lines
TestingSupport/
2 lines

Diff 211240

lldb/include/lldb/Utility/Log.h

lldb/source/API/SBDebugger.cpp

lldb/source/API/SBFrame.cpp

lldb/source/API/SBTarget.cpp

lldb/source/Breakpoint/Breakpoint.cpp

lldb/source/Breakpoint/BreakpointLocation.cpp

lldb/source/Breakpoint/BreakpointResolver.cpp

lldb/source/Breakpoint/BreakpointResolverAddress.cpp

lldb/source/Breakpoint/BreakpointResolverName.cpp

lldb/source/Commands/CommandObjectTarget.cpp

lldb/source/Core/AddressResolverFileLine.cpp

lldb/source/Core/Communication.cpp

lldb/source/Core/FormatEntity.cpp

lldb/source/Core/Mangled.cpp

lldb/source/Core/Module.cpp

lldb/source/Core/ModuleList.cpp

lldb/source/Core/ValueObject.cpp

lldb/source/Core/ValueObjectDynamicValue.cpp

lldb/source/Core/ValueObjectSyntheticFilter.cpp

lldb/source/DataFormatters/FormatManager.cpp

lldb/source/DataFormatters/TypeCategoryMap.cpp

lldb/source/Expression/DWARFExpression.cpp

lldb/source/Expression/ExpressionVariable.cpp

lldb/source/Expression/FunctionCaller.cpp

lldb/source/Expression/IRExecutionUnit.cpp

Context not available.
return ret; return ret;
} }
if (log) LLDB_LOG(log,
log->Printf("Found function, has local address 0x%" PRIx64 "Found function, has local address 0x%" PRIx64
" and remote address 0x%" PRIx64, " and remote address 0x%" PRIx64,
(uint64_t)func_local_addr, (uint64_t)func_remote_addr); (uint64_t)func_local_addr, (uint64_t)func_remote_addr);
std::pair<lldb::addr_t, lldb::addr_t> func_range; std::pair<lldb::addr_t, lldb::addr_t> func_range;
Context not available.
return ret; return ret;
} }
if (log) LLDB_LOG(log, "Function's code range is [0x%" PRIx64 "+0x%" PRIx64 "]",
log->Printf("Function's code range is [0x%" PRIx64 "+0x%" PRIx64 "]", func_range.first, func_range.second);
func_range.first, func_range.second);
Target *target = exe_ctx.GetTargetPtr(); Target *target = exe_ctx.GetTargetPtr();
if (!target) { if (!target) {
Context not available.
target->GetArchitecture().GetAddressByteSize()); target->GetArchitecture().GetAddressByteSize());
if (log) { if (log) {
log->Printf("Function data has contents:"); LLDB_LOG(log, "Function data has contents:");
extractor.PutToLog(log, 0, extractor.GetByteSize(), func_remote_addr, 16, extractor.PutToLog(log, 0, extractor.GetByteSize(), func_remote_addr, 16,
DataExtractor::TypeUInt8); DataExtractor::TypeUInt8);
} }
Context not available.
oss.flush(); oss.flush();
log->Printf("Module being sent to JIT: \n%s", s.c_str()); LLDB_LOG(log, "Module being sent to JIT: \n%s", s.c_str());
} }
m_module_up->getContext().setInlineAsmDiagnosticHandler(ReportInlineAsmError, m_module_up->getContext().setInlineAsmDiagnosticHandler(ReportInlineAsmError,
Context not available.
} }
if (log) { if (log) {
log->Printf("Code can be run in the target."); LLDB_LOG(log, "Code can be run in the target.");
StreamString disassembly_stream; StreamString disassembly_stream;
Status err = DisassembleFunction(disassembly_stream, process_sp); Status err = DisassembleFunction(disassembly_stream, process_sp);
if (!err.Success()) { if (!err.Success()) {
log->Printf("Couldn't disassemble function : %s", LLDB_LOG(log, "Couldn't disassemble function : %s",
err.AsCString("unknown error")); err.AsCString("unknown error"));
} else { } else {
log->Printf("Function disassembly:\n%s", disassembly_stream.GetData()); LLDB_LOG(log, "Function disassembly:\n%s", disassembly_stream.GetData());
} }
log->Printf("Sections: "); LLDB_LOG(log, "Sections: ");
for (AllocationRecord &record : m_records) { for (AllocationRecord &record : m_records) {
if (record.m_process_address != LLDB_INVALID_ADDRESS) { if (record.m_process_address != LLDB_INVALID_ADDRESS) {
record.dump(log); record.dump(log);
Context not available.
Alignment, SectionID, SectionName.str().c_str())); Alignment, SectionID, SectionName.str().c_str()));
if (log) { if (log) {
labathUnsubmitted
Not Done
ReplyInline Actions

looks like there are some if(log)s still remaining. Maybe the {} around the printf confused your vim macro?

labath: looks like there are some `if(log)`s still remaining. Maybe the `{}` around the printf confused…
jinghamUnsubmitted
Not Done
ReplyInline Actions

There will always be some "if (log)" statements. Whenever consing up the log message involves work, you should always say:

if (log) {

/// Do expensive work
LLDB_LOG...

}

Not saying that all the remaining "if (logs)" are for that reason, but then intent is NOT to remove all such statements as they serve a useful purpose.

jingham: There will always be some "if (log)" statements. Whenever consing up the log message involves…
labathUnsubmitted
Not Done
ReplyInline Actions

I'm fine with if(log)s staying if they serve a purpose (or even if they're hard to remove in this patch). However, I would expect that with LLDB_LOG, they become much less frequently needed, because the formatter is much more powerful (e.g., there is no need to write a for loop just to print an array, etc.)

labath: I'm fine with `if(log)`s staying if they serve a purpose (or even if they're hard to remove in…
jinghamUnsubmitted
Not Done
ReplyInline Actions

Yes, it's also not entirely obvious (YAY for macros!!!) that code in the LLDB_LOG* arguments doesn't get evaluated if log == nullptr, but that also reduces the need for standalone if (logs).

BTW, we were going to document somewhere that LLDB_LOG actually used format_providers but I didn't see that anywhere. I submitted:

https://reviews.llvm.org/D65293

to put this somewhere in the lldb sources. Not sure if this is the best place, or if there is more that it would be useful to add.

jingham: Yes, it's also not entirely obvious (YAY for macros!!!) that code in the LLDB_LOG* arguments…
log->Printf("IRExecutionUnit::allocateCodeSection(Size=0x%" PRIx64 LLDB_LOG(log,
", Alignment=%u, SectionID=%u) = %p", "IRExecutionUnit::allocateCodeSection(Size=0x%" PRIx64
(uint64_t)Size, Alignment, SectionID, (void *)return_value); ", Alignment=%u, SectionID=%u) = %p",
(uint64_t)Size, Alignment, SectionID, (void *)return_value);
} }
if (m_parent.m_reported_allocations) { if (m_parent.m_reported_allocations) {
Context not available.
GetSectionTypeFromSectionName(SectionName, AllocationKind::Data), Size, GetSectionTypeFromSectionName(SectionName, AllocationKind::Data), Size,
Alignment, SectionID, SectionName.str().c_str())); Alignment, SectionID, SectionName.str().c_str()));
if (log) { if (log) {
log->Printf("IRExecutionUnit::allocateDataSection(Size=0x%" PRIx64 LLDB_LOG(log,
", Alignment=%u, SectionID=%u) = %p", "IRExecutionUnit::allocateDataSection(Size=0x%" PRIx64
(uint64_t)Size, Alignment, SectionID, (void *)return_value); ", Alignment=%u, SectionID=%u) = %p",
(uint64_t)Size, Alignment, SectionID, (void *)return_value);
} }
if (m_parent.m_reported_allocations) { if (m_parent.m_reported_allocations) {
Context not available.
lldb::addr_t ret = m_parent.FindSymbol(name_cs, missing_weak); lldb::addr_t ret = m_parent.FindSymbol(name_cs, missing_weak);
if (ret == LLDB_INVALID_ADDRESS) { if (ret == LLDB_INVALID_ADDRESS) {
if (log) LLDB_LOG(log,
log->Printf( "IRExecutionUnit::getSymbolAddress(Name=\"%s\") = <not found>",
"IRExecutionUnit::getSymbolAddress(Name=\"%s\") = <not found>", Name.c_str());
Name.c_str());
m_parent.ReportSymbolLookupError(name_cs); m_parent.ReportSymbolLookupError(name_cs);
return 0; return 0;
} else { } else {
if (log) LLDB_LOG(log, "IRExecutionUnit::getSymbolAddress(Name=\"%s\") = %" PRIx64,
log->Printf("IRExecutionUnit::getSymbolAddress(Name=\"%s\") = %" PRIx64, Name.c_str(), ret);
Name.c_str(), ret);
return ret; return ret;
} }
} }
Context not available.
record.m_process_address + (local_address - record.m_host_address); record.m_process_address + (local_address - record.m_host_address);
if (log) { if (log) {
log->Printf( LLDB_LOG(log,
"IRExecutionUnit::GetRemoteAddressForLocal() found 0x%" PRIx64 "IRExecutionUnit::GetRemoteAddressForLocal() found 0x%" PRIx64
" in [0x%" PRIx64 "..0x%" PRIx64 "], and returned 0x%" PRIx64 " in [0x%" PRIx64 "..0x%" PRIx64 "], and returned 0x%" PRIx64
" from [0x%" PRIx64 "..0x%" PRIx64 "].", " from [0x%" PRIx64 "..0x%" PRIx64 "].",
local_address, (uint64_t)record.m_host_address, local_address, (uint64_t)record.m_host_address,
(uint64_t)record.m_host_address + (uint64_t)record.m_size, ret, (uint64_t)record.m_host_address + (uint64_t)record.m_size, ret,
record.m_process_address, record.m_process_address + record.m_size); record.m_process_address,
record.m_process_address + record.m_size);
} }
return ret; return ret;
Context not available.
if (!log) if (!log)
return; return;
log->Printf("[0x%llx+0x%llx]->0x%llx (alignment %d, section ID %d, name %s)", LLDB_LOG(log,
(unsigned long long)m_host_address, (unsigned long long)m_size, "[0x%llx+0x%llx]->0x%llx (alignment %d, section ID %d, name %s)",
(unsigned long long)m_process_address, (unsigned)m_alignment, (unsigned long long)m_host_address, (unsigned long long)m_size,
(unsigned)m_section_id, m_name.c_str()); (unsigned long long)m_process_address, (unsigned)m_alignment,
(unsigned)m_section_id, m_name.c_str());
} }
lldb::ByteOrder IRExecutionUnit::GetByteOrder() const { lldb::ByteOrder IRExecutionUnit::GetByteOrder() const {
Context not available.

lldb/source/Expression/IRInterpreter.cpp

lldb/source/Expression/IRMemoryMap.cpp

lldb/source/Expression/LLVMUserExpression.cpp

lldb/source/Expression/Materializer.cpp

lldb/source/Expression/UserExpression.cpp

lldb/source/Host/common/Host.cpp

lldb/source/Host/common/HostInfoBase.cpp

lldb/source/Host/common/HostNativeThreadBase.cpp

lldb/source/Host/common/NativeProcessProtocol.cpp

lldb/source/Host/common/NativeRegisterContext.cpp

lldb/source/Host/common/Socket.cpp

lldb/source/Host/common/TCPSocket.cpp

lldb/source/Host/common/UDPSocket.cpp

lldb/source/Host/linux/HostInfoLinux.cpp

lldb/source/Host/macosx/objcxx/Host.mm

lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm

lldb/source/Host/posix/ConnectionFileDescriptorPosix.cpp

lldb/source/Host/windows/ConnectionGenericFileWindows.cpp

lldb/source/Interpreter/CommandInterpreter.cpp

lldb/source/Plugins/ABI/MacOSX-arm64/ABIMacOSX_arm64.cpp

lldb/source/Plugins/ABI/SysV-arm64/ABISysV_arm64.cpp

lldb/source/Plugins/ABI/SysV-mips/ABISysV_mips.cpp

lldb/source/Plugins/ABI/SysV-mips64/ABISysV_mips64.cpp

lldb/source/Plugins/ABI/SysV-ppc/ABISysV_ppc.cpp

lldb/source/Plugins/ABI/SysV-ppc64/ABISysV_ppc64.cpp

lldb/source/Plugins/ABI/SysV-s390x/ABISysV_s390x.cpp

lldb/source/Plugins/ABI/SysV-x86_64/ABISysV_x86_64.cpp

lldb/source/Plugins/ABI/Windows-x86_64/ABIWindows_x86_64.cpp

lldb/source/Plugins/Architecture/Mips/ArchitectureMips.cpp

lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp

lldb/source/Plugins/DynamicLoader/Hexagon-DYLD/DynamicLoaderHexagonDYLD.cpp

lldb/source/Plugins/DynamicLoader/Hexagon-DYLD/HexagonDYLDRendezvous.cpp

lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp

lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOS.cpp

lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.cpp

lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp

lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp

lldb/source/Plugins/DynamicLoader/Windows-DYLD/DynamicLoaderWindowsDYLD.cpp

lldb/source/Plugins/ExpressionParser/Clang/ASTDumper.cpp

lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp

lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp

lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp

lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp

lldb/source/Plugins/ExpressionParser/Clang/ClangFunctionCaller.cpp

lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp

lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp

lldb/source/Plugins/ExpressionParser/Clang/IRDynamicChecks.cpp

lldb/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp

lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp

lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCDeclVendor.cpp

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.cpp

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp

lldb/source/Plugins/LanguageRuntime/ObjC/ObjCLanguageRuntime.cpp

lldb/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptExpressionOpts.cpp

lldb/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp

lldb/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptx86ABIFixups.cpp

lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp

lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp

lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp

lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp

lldb/source/Plugins/Platform/Android/PlatformAndroid.cpp

lldb/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp

lldb/source/Plugins/Platform/MacOSX/PlatformAppleTVSimulator.cpp

lldb/source/Plugins/Platform/MacOSX/PlatformAppleWatchSimulator.cpp

lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp

lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp

lldb/source/Plugins/Platform/MacOSX/PlatformMacOSX.cpp

lldb/source/Plugins/Platform/MacOSX/PlatformRemoteAppleBridge.cpp

lldb/source/Plugins/Platform/MacOSX/PlatformRemoteAppleTV.cpp

lldb/source/Plugins/Platform/MacOSX/PlatformRemoteAppleWatch.cpp

lldb/source/Plugins/Platform/MacOSX/PlatformRemoteDarwinDevice.cpp

lldb/source/Plugins/Platform/MacOSX/PlatformRemoteiOS.cpp

lldb/source/Plugins/Platform/MacOSX/PlatformiOSSimulator.cpp

lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp

lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp

lldb/source/Plugins/Process/Darwin/DarwinProcessLauncher.cpp

lldb/source/Plugins/Process/Darwin/MachException.cpp

lldb/source/Plugins/Process/Darwin/NativeProcessDarwin.cpp

lldb/source/Plugins/Process/Darwin/NativeThreadListDarwin.cpp

lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp

lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp

lldb/source/Plugins/Process/FreeBSD/ProcessMonitor.cpp

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp

lldb/source/Plugins/Process/Linux/NativeThreadLinux.cpp

lldb/source/Plugins/Process/MacOSX-Kernel/CommunicationKDP.cpp

lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp

lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp

lldb/source/Plugins/Process/POSIX/NativeProcessELF.cpp

lldb/source/Plugins/Process/Utility/AuxVector.cpp

lldb/source/Plugins/Process/Utility/HistoryThread.cpp

lldb/source/Plugins/Process/Utility/RegisterContextDarwin_arm.cpp

lldb/source/Plugins/Process/Utility/RegisterContextDarwin_arm64.cpp

lldb/source/Plugins/Process/Utility/RegisterContextDarwin_i386.cpp

lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp

lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp

lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp

lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp

lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationHistory.cpp

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp

lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp

lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp

lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp

lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

lldb/source/Plugins/StructuredData/DarwinLog/StructuredDataDarwinLog.cpp

lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugAranges.cpp

lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugLine.cpp

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp

lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp

lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp

lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp

lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp

lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp

lldb/source/Symbol/Block.cpp

lldb/source/Symbol/ClangASTContext.cpp

lldb/source/Symbol/ClangASTImporter.cpp

lldb/source/Symbol/CompactUnwindInfo.cpp

lldb/source/Symbol/DWARFCallFrameInfo.cpp

lldb/source/Symbol/LocateSymbolFile.cpp

lldb/source/Symbol/LocateSymbolFileMacOSX.cpp

lldb/source/Symbol/ObjectFile.cpp

lldb/source/Symbol/SymbolContext.cpp

lldb/source/Symbol/UnwindPlan.cpp

lldb/source/Target/Memory.cpp

lldb/source/Target/ModuleCache.cpp

lldb/source/Target/Platform.cpp

lldb/source/Target/Process.cpp

lldb/source/Target/SectionLoadList.cpp

lldb/source/Target/StackFrameList.cpp

lldb/source/Target/StopInfo.cpp

lldb/source/Target/Target.cpp

lldb/source/Target/Thread.cpp

lldb/source/Target/ThreadList.cpp

lldb/source/Target/ThreadPlan.cpp

lldb/source/Target/ThreadPlanBase.cpp

lldb/source/Target/ThreadPlanCallFunction.cpp

lldb/source/Target/ThreadPlanCallUserExpression.cpp

lldb/source/Target/ThreadPlanPython.cpp

lldb/source/Target/ThreadPlanRunToAddress.cpp

lldb/source/Target/ThreadPlanShouldStopHere.cpp

lldb/source/Target/ThreadPlanStepInRange.cpp

lldb/source/Target/ThreadPlanStepInstruction.cpp

lldb/source/Target/ThreadPlanStepOut.cpp

lldb/source/Target/ThreadPlanStepOverBreakpoint.cpp

lldb/source/Target/ThreadPlanStepOverRange.cpp

lldb/source/Target/ThreadPlanStepRange.cpp

lldb/source/Target/ThreadPlanStepThrough.cpp

lldb/source/Target/ThreadPlanStepUntil.cpp

lldb/source/Utility/ArchSpec.cpp

lldb/source/Utility/Broadcaster.cpp

lldb/source/Utility/Listener.cpp

lldb/tools/lldb-server/lldb-gdbserver.cpp

lldb/unittests/Host/ConnectionFileDescriptorTest.cpp

lldb/unittests/TestingSupport/TestUtilities.cpp