1. gn build: unbreak libcxx build after r374116 by restoring (details)
  2. Factor out some duplication. NFC. (details)
  3. [cxx_status] Note that Clang has supported std::source_location since (details)
  4. Explicitly set entry point arch when it's thumb [Second Try] (details)
Commit 8f7a32043d7a5498bf334e222c6beadba6195b24 by nicolasweber
gn build: unbreak libcxx build after r374116 by restoring for gn
llvm-svn: 374129
The file was modifiedllvm/utils/gn/secondary/libcxx/src/
The file was addedllvm/utils/gn/secondary/libcxx/utils/
Commit 5769440b5c6cbe2e6fd0f7e98c9c4698e4e73ab6 by richard-llvm
Factor out some duplication. NFC.
llvm-svn: 374130
The file was modifiedclang/lib/AST/ExprConstant.cpp
Commit 32377ad7cb188f60e6b1777173ee5a951116ee60 by richard-llvm
[cxx_status] Note that Clang has supported std::source_location since
version 9.
llvm-svn: 374131
The file was modifiedclang/www/cxx_status.html
Commit ad6690afa3e6e9bae6d8338016c4931e084ff380 by antonio.afonso
Explicitly set entry point arch when it's thumb [Second Try]
Summary: This is a redo of D68069 because I reverted it due to some
concerns that were now addressed along with the new comments that
@labath added.
I found a case where the main android binary (app_process32) had thumb
code at its entry point but no entry in the symbol table indicating
this. This made lldb set a 4 byte breakpoint at that address (we default
to arm code) instead of a 2 byte one (like we should for thumb). The big
deal with this is that the expression evaluator uses the entry point as
a way to know when a JITed expression has finished executing by putting
a breakpoint there. Because of this, evaluating expressions on certain
android devices (Google Pixel something) made the process crash. This
was fixed by checking this specific situation when we parse the symbol
table and add an artificial symbol for this 2 byte range and indicating
that it's arm thumb.
I created 2 unit tests for this, one to check that now we know that the
entry point is arm thumb, and the other to make sure we didn't change
the behaviour for arm code.
I also run the following on the command line with the `app_process32`
where I found the issue:
(lldb) dis -s 0x1640 -e 0x1644 app_process32[0x1640]: .long  0xf0004668
              ; unknown opcode
(lldb) dis -s 0x1640 -e 0x1644 app_process32`: app_process32[0x1640]
<+0>: mov    r0, sp app_process32[0x1642]:      andeq  r0, r0, r0
Reviewers: clayborg, labath, wallace, espindola
Reviewed By: labath
Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson,
emaste, srhines
Tags: #lldb
Differential Revision:
llvm-svn: 374132
The file was modifiedlldb/unittests/ObjectFile/ELF/TestObjectFileELF.cpp
The file was modifiedlldb/lit/SymbolFile/Breakpad/Inputs/basic-elf.yaml
The file was modifiedlldb/lit/SymbolFile/Breakpad/symtab.test
The file was modifiedlldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
The file was addedlldb/lit/SymbolFile/dissassemble-entry-point.s