[Platform] Remove Kalimba Platform

This patch removes the Kalimba platform. For more information please
refer to the corresponding thread on the mailing list.

http://lists.llvm.org/pipermail/lldb-d

[Platform] Remove Kalimba Platform

This patch removes the Kalimba platform. For more information please
refer to the corresponding thread on the mailing list.

http://lists.llvm.org/pipermail/lldb-dev/2019-March/014921.html

llvm-svn: 357086

show more ...

Bring Doxygen comment syntax in sync with LLVM coding style.
This changes '@' prefix to '\'.

llvm-svn: 355841

Pass ConstString by value (NFC)

My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.

ConstString has exactly one const char * data member, s

Pass ConstString by value (NFC)

My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.

ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.

(This fixes rdar://problem/48640859 for the Apple folks)

Differential Revision: https://reviews.llvm.org/D59030

llvm-svn: 355553

show more ...

Move RangeMap.h into Utility

Summary:
This file implements some general purpose data structures, and so it
belongs to the Utility module.

Reviewers: zturner, jingham, JDevlieghere, clayborg, espind

Move RangeMap.h into Utility

Summary:
This file implements some general purpose data structures, and so it
belongs to the Utility module.

Reviewers: zturner, jingham, JDevlieghere, clayborg, espindola

Subscribers: emaste, mgorny, javed.absar, arichardson, MaskRay, lldb-commits

Differential Revision: https://reviews.llvm.org/D58970

llvm-svn: 355509

show more ...

[Utility] Remove Triple{Environment,OS,Vendor}IsUnspecifiedUnknown from ArchSpec

Summary:
These functions should always return the opposite of the
`Triple{Environment,OS,Vendor}WasSpecified` functio

[Utility] Remove Triple{Environment,OS,Vendor}IsUnspecifiedUnknown from ArchSpec

Summary:
These functions should always return the opposite of the
`Triple{Environment,OS,Vendor}WasSpecified` functions. Unspecified unknown is
the same as unspecified, which is why one set of functions should give us what
we want. It's possible to have specified unknown, which is why we can't just
rely on checking the enum values of vendor/os/environment. We must also ensure
that the names of these are empty and not "unknown".

Differential Revision: https://reviews.llvm.org/D58653

llvm-svn: 354933

show more ...

[lldb] [ObjectFile/ELF] Fix recognizing NetBSD images

Split the recognition into NetBSD executables & shared libraries
and core(5) files.

Introduce new owner type: "NetBSD-CORE", as core(5) files a

[lldb] [ObjectFile/ELF] Fix recognizing NetBSD images

Split the recognition into NetBSD executables & shared libraries
and core(5) files.

Introduce new owner type: "NetBSD-CORE", as core(5) files are not tagged
in the same way as regular NetBSD executables.

Stop using incorrectly ABI_TAG and ABI_SIZE. Introduce IDENT_TAG,
IDENT_DECSZ, IDENT_NAMESZ and PROCINFO.

The new values detect correctly the NetBSD images.

The patch has been originally written by Kamil Rytarowski. I've added
tests and applied minor code changes per review. The work has been
sponsored by the NetBSD Foundation.

Differential Revision: https://reviews.llvm.org/D42870

llvm-svn: 354466

show more ...

Move UnwindTable from ObjectFile to Module

Summary:
This is a preparatory step to enable adding extra unwind strategies by
symbol file plugins. This has been discussed on the lldb-dev mailing
list:

Move UnwindTable from ObjectFile to Module

Summary:
This is a preparatory step to enable adding extra unwind strategies by
symbol file plugins. This has been discussed on the lldb-dev mailing
list: <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.

Reviewers: jasonmolenda, clayborg, espindola

Subscribers: lemo, emaste, lldb-commits, arichardson

Differential Revision: https://reviews.llvm.org/D58129

llvm-svn: 354033

show more ...

Replace 'ap' with 'up' suffix in variable names. (NFC)

The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique

Replace 'ap' with 'up' suffix in variable names. (NFC)

The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.

In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.

I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.

llvm-svn: 353912

show more ...

Remove redundant ::get() for smart pointer. (NFC)

This commit removes redundant calls to smart pointer’s ::get() method.

https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartpt

Remove redundant ::get() for smart pointer. (NFC)

This commit removes redundant calls to smart pointer’s ::get() method.

https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html

llvm-svn: 353795

show more ...

Simplify ObjectFile::GetUUID

instead of returning the UUID through by-ref argument and a boolean
value indicating success, we can just return it directly. Since the UUID
class already has an invalid

Simplify ObjectFile::GetUUID

instead of returning the UUID through by-ref argument and a boolean
value indicating success, we can just return it directly. Since the UUID
class already has an invalid state, it can be used to denote the failure
without the additional bool.

llvm-svn: 353714

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

ELF: Fix base address computation code for files generated by yaml2obj

The code was assuming that the elf file will have a PT_LOAD segment
starting from the first byte of the file. While this is tru

ELF: Fix base address computation code for files generated by yaml2obj

The code was assuming that the elf file will have a PT_LOAD segment
starting from the first byte of the file. While this is true for files
generated by most linkers (it's a way of saving space), it is not a
requirement. And files not satisfying this constraint can still be
perfectly executable. yaml2obj is one of the tools which produces files
like this.

This patch relaxes the check in ObjectFileELF to take the address of the
first PT_LOAD segment as the base address of the object (instead of the
one with the offset 0). Since the PT_LOAD segments are supposed to be
sorted according to the VM address, this entry will also be the one with
the lowest VM address.

If we ever run into files which don't have the PT_LOAD segments sorted,
we can easily change this code to return the lowest VM address as the
base address (if that is the correct thing to do for these files).

llvm-svn: 350923

show more ...

Implement ObjectFileELF::GetBaseAddress

Summary:
The concept of a base address was already present in the implementation
(it's needed for computing section load addresses properly), but it was
never

Implement ObjectFileELF::GetBaseAddress

Summary:
The concept of a base address was already present in the implementation
(it's needed for computing section load addresses properly), but it was
never exposed through this function. This fixes that.

llvm-svn: 350804

show more ...

ELF: create "container" sections from PT_LOAD segments

Summary:
This is the result of the discussion in D55356, where it was suggested
as a solution to representing the addresses that logically belo

ELF: create "container" sections from PT_LOAD segments

Summary:
This is the result of the discussion in D55356, where it was suggested
as a solution to representing the addresses that logically belong to a
module in memory, but are not a part of any of its sections.

The ELF PT_LOAD segments are similar to the MachO "load commands",
except that the relationship between them and the object file sections
is a bit weaker. While in the MachO case, the sections belonging to a
specific segment are placed directly inside it in the object file
logical structur, in the ELF case, the sections and segments form two
separate hierarchies. This means that it is in theory possible to create
an elf file where only a part of a section would belong to some segment
(and another part to a different one). However, I am not aware of any
tool which would produce such a file (and most tools will have problems
ingesting them), so this means it is still possible to follow the MachO
model and make sections children of the PT_LOAD segments.

In case we run into (corrupt?) files with overlapping sections, I have
added code (and tests) which adjusts the sizes and/or drops the offending
sections in order to present a reasonable image to the upper layers of
LLDB. This is mostly done for completeness, as I don't anticipate
running into this situation in the real world. However, if we do run
into it, and the current behavior is not suitable for some reason, we
can implement this logic differently.

Reviewers: clayborg, jankratochvil, krytarowski, joerg, espindola

Subscribers: emaste, arichardson, lldb-commits

Differential Revision: https://reviews.llvm.org/D55998

llvm-svn: 350742

show more ...

Simplify ObjectFile::GetArchitecture

Summary:
instead of returning the architecture through by-ref argument and a
boolean value indicating success, we can just return the ArchSpec
directly. Since th

Simplify ObjectFile::GetArchitecture

Summary:
instead of returning the architecture through by-ref argument and a
boolean value indicating success, we can just return the ArchSpec
directly. Since the ArchSpec already has an invalid state, it can be
used to denote the failure without the additional bool.

Reviewers: clayborg, zturner, espindola

Subscribers: emaste, arichardson, JDevlieghere, lldb-commits

Differential Revision: https://reviews.llvm.org/D56129

llvm-svn: 350291

show more ...

ELF: Don't create sections for section header index 0

Summary:
The first section header does not define a real section. Instead it is
used for various elf extensions. This patch skips creation of a

ELF: Don't create sections for section header index 0

Summary:
The first section header does not define a real section. Instead it is
used for various elf extensions. This patch skips creation of a section
for index 0.

This has one furtunate side-effect, in that it allows us to use the section
header index as the Section ID (where 0 is also invalid). This way, we
can get rid of a lot of spurious +1s in the ObjectFileELF code.

Reviewers: clayborg, krytarowski, joerg, espindola

Subscribers: emaste, lldb-commits, arichardson

Differential Revision: https://reviews.llvm.org/D55757

llvm-svn: 349498

show more ...

ELF: more section creation cleanup

Summary:
This patch attempts to move as much code as possible out of the
CreateSections function to make room for future improvements there. Some
of this may be sl

ELF: more section creation cleanup

Summary:
This patch attempts to move as much code as possible out of the
CreateSections function to make room for future improvements there. Some
of this may be slightly over-engineered (VMAddressProvider), but I
wanted to keep the logic of this function very simple, because once I
start taking segment headers into acount (as discussed in D55356), the
function is going to grow significantly.

While in there, I also added tests for various bits of functionality.

This should be NFC, except that I changed the order of hac^H^Heuristicks
for determining section type slightly. Previously, name-based deduction
(.symtab -> symtab) would take precedence over type-based (SHT_SYMTAB ->
symtab) one. In fact we would assert if we ran into a .text section with
type SHT_SYMTAB. Though unlikely to matter in practice, this order
seemed wrong to me, so I have inverted it.

Reviewers: clayborg, krytarowski, espindola

Subscribers: emaste, arichardson, lldb-commits

Differential Revision: https://reviews.llvm.org/D55706

llvm-svn: 349268

show more ...

Simplify Boolean expressions

This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:

run-clang-tidy.py -checks='-*,readability-simplify-

Simplify Boolean expressions

This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:

run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD

Differential revision: https://reviews.llvm.org/D55584

llvm-svn: 349215

show more ...

ELF: Clean up section type computation

Move code into a separate function, and replace the if-else chain with
llvm::StringSwitch.

A slight behavioral change is that now I use the section flags
(SHF

ELF: Clean up section type computation

Move code into a separate function, and replace the if-else chain with
llvm::StringSwitch.

A slight behavioral change is that now I use the section flags
(SHF_TLS) instead of the section name to set the thread-specific
property. There is no explanation in the original commit introducing
this (r153537) as to why that was done this way, but the new behavior
should be more correct.

llvm-svn: 348936

show more ...

ELF: Simplify program header iteration

Instead of GetProgramHeaderCount+GetProgramHeaderByIndex, expose an
ArrayRef of all program headers, to enable range-based iteration.
Instead of GetSegmentData

ELF: Simplify program header iteration

Instead of GetProgramHeaderCount+GetProgramHeaderByIndex, expose an
ArrayRef of all program headers, to enable range-based iteration.
Instead of GetSegmentDataByIndex, expose GetSegmentData, taking a
program header (reference).

This makes the code simpler by enabling range-based loops and also
allowed to remove some null checks, as it became locally obvious that
some pointers can never be null.

llvm-svn: 348928

show more ...

[LLDB] - Recommit r346848 "[LLDB] - Support the single file split DWARF.".

Test cases were updated to not use the local compilation dir which
is different between development pc and build bots.

Ori

[LLDB] - Recommit r346848 "[LLDB] - Support the single file split DWARF.".

Test cases were updated to not use the local compilation dir which
is different between development pc and build bots.

Original commit message:

[LLDB] - Support the single file split DWARF.

DWARF5 spec describes a single file split dwarf case
(when .dwo sections are in the .o files).

Problem is that LLDB does not work correctly in that case.
The issue is that, for example, both .debug_info and .debug_info.dwo
has the same type: eSectionTypeDWARFDebugInfo. And when code searches
section by type it might find the regular debug section
and not the .dwo one.

The patch fixes that. With it, LLDB is able to work with
output compiled with -gsplit-dwarf=single flag correctly.

Differential revision: https://reviews.llvm.org/D52403

llvm-svn: 346855

show more ...

Revert r346848 "[LLDB] - Support the single file split DWARF."

It broke BB:
http://green.lab.llvm.org/green/job/lldb-cmake/12522/testReport/junit/LLDB/Breakpoint/single_file_split_dwarf_test/

llvm-

Revert r346848 "[LLDB] - Support the single file split DWARF."

It broke BB:
http://green.lab.llvm.org/green/job/lldb-cmake/12522/testReport/junit/LLDB/Breakpoint/single_file_split_dwarf_test/

llvm-svn: 346853

show more ...

[LLDB] - Support the single file split DWARF.

DWARF5 spec describes a single file split dwarf case
(when .dwo sections are in the .o files).

Problem is that LLDB does not work correctly in that cas

[LLDB] - Support the single file split DWARF.

DWARF5 spec describes a single file split dwarf case
(when .dwo sections are in the .o files).

Problem is that LLDB does not work correctly in that case.
The issue is that, for example, both .debug_info and .debug_info.dwo
has the same type: eSectionTypeDWARFDebugInfo. And when code searches
section by type it might find the regular debug section
and not the .dwo one.

The patch fixes that. With it, LLDB is able to work with
output compiled with -gsplit-dwarf=single flag correctly.

Differential revision: https://reviews.llvm.org/D52296

llvm-svn: 346848

show more ...

[ObjectFileELF] Fix misaligned read/writes caught by UBSan.

llvm-svn: 346244

Add a relocation to ObjectFileELF::ApplyRelocations and a test

Summary:
pcm files can end up being processed by lldb with relocations to be
made for the .debug_info section. When a R_AARCH64_ABS64 r

Add a relocation to ObjectFileELF::ApplyRelocations and a test

Summary:
pcm files can end up being processed by lldb with relocations to be
made for the .debug_info section. When a R_AARCH64_ABS64 relocation
was required lldb would hit an `assert(false)` and die.

Add R_AARCH64_ABS64 relocations to the S+A 64 bit width code path. Add
a test for R_AARCH64_ABS64 and R_AARCH64_ABS32 .rela.debug_info
relocations in a pcm file.

Reviewers: sas, xiaobai, davide, javed.absar, espindola

Reviewed By: davide

Subscribers: labath, zturner, emaste, mgorny, arichardson, kristof.beyls

Differential Revision: https://reviews.llvm.org/D51566

llvm-svn: 346171

show more ...