Someone may want to do something crazy, like replace these objects if they
change or something.

No functionality change intended.

llvm-svn: 184175

llvm-svn: 184174

llvm-svn: 184173

llvm-svn: 184172

Some embedded targets use ARM's AAPCS with iOS header files that define size_t
as unsigned long, which conflicts with the usual AAPCS definition of size_t
as unsigned int.

llvm-svn: 184171

These APIs are still used, and the constant APIs are actually really important.

Removing these makes -Wdocumentation more useful.

llvm-svn: 184170

llvm-svn: 184169

llvm-svn: 184168

llvm-svn: 184167

llvm-svn: 184166

llvm-svn: 184165

llvm-svn: 184164

Only add the — (double dash) separator to a command syntax if it has any options to be separated from arguments
Also remove the unused Translate() method from CommandObject 

llvm-svn: 184163

llvm-svn: 184162

A bug in libObject will cause it to assert() if a symbol table's string
table and the section header string table are the same section, so we
need to ensure that we emit two different string tables (among other
things). The problematic code is the hardcoded usage of ".strtab"
(`dot_strtab_sec`) for looking up symbol names in
ELFObjectFile<ELFT>::getSymbolName.

I discussed this with Michael, and he has some local improvements to the
ELF code in libObject that, among other things, should fix our handling
of this scenario.

llvm-svn: 184161

I was spotting garbage in the output. I'd like to just zero the entire
ELFYAML::Section to be sure, but it contains non-POD types. (I'm also
trying to avoid bloating the ELFYAML::Foo classes with a bunch of
constructor code).

No test, since this is by its very nature unpredictable. I'm pretty sure
that one of the sanitizers would catch it immediately though.

llvm-svn: 184160

The first two questions I have added explanations and answers to are:
- File and line breakpoints are not getting hit
- How do I check if I have debug symbols?

llvm-svn: 184159

Allow “command script import” to work with folder names that have a ‘ (tick) in them

Kudos to StackOverflow (question 1494399) for the replace_all code!

llvm-svn: 184158

between a block assignment and the entry of the block function. In reality
this wouldn't work anyway because blocks are predominantly created
on-the-fly inside of an ObjC method invocation.
The proper fix for the ambiguity is to use -gcolumn-info to differentiate
the breakpoints.

This is expected to break some block-related darwin-gdb tests.

rdar://problem/14039866

llvm-svn: 184157

llvm-svn: 184155

llvm-svn: 184154

3 patches, aiming to improve PE/COFF support:
- First patch fix symbol reading (invalid header size from sizeof() == 20 != 18, and various bugfixes such as invalid skipping of auxiliary symbols, 4 bytes shift from beginning, etc...).
- Second patch add image_base to section vmaddr offset so that VM addr is in image_base space.
- Third patch add support for DWARF section in PECOFF (taken from ELF counterpart), since they are generated by gcc/clang under windows.

llvm-svn: 184153

later with dwarf4 type hashing.

llvm-svn: 184152

llvm-svn: 184151

Found by skimming over lcov report.

llvm-svn: 184150

llvm-svn: 184149

llvm-svn: 184148

Renaming the "--wipe" option to "command history" to "--clear" (-C) for coherence with the rest of the LLDB command-line interface

llvm-svn: 184147

llvm-svn: 184143

This is a rewrite of the command history facility of LLDB

It takes the history management out of the CommandInterpreter into its own CommandHistory class
It reimplements the command history command to allow more combinations of options to work correctly (e.g. com hist -c 1 -s 5)
It adds a new --wipe (-w) option to command history to allow clearing the history on demand
It extends the lldbtest runCmd: and expect: methods to allow adding commands to history if need be
It adds a test case for the reimplemented facility

llvm-svn: 184140

llvm-svn: 184139

The error message was:

/home/espindola/llvm/llvm/tools/gold/gold-plugin.cpp: In function ‘ld_plugin_status cleanup_hook()’:
/home/espindola/llvm/llvm/tools/gold/gold-plugin.cpp:461:30: error: cannot pass objects of non-trivially-copyable type ‘std::string {aka class std::basic_string<char>}’ through ‘...’

I will check if this was a clang or gcc issue.

llvm-svn: 184138

llvm-svn: 184137

llvm-svn: 184136

llvm-svn: 184135

llvm-svn: 184134

llvm-svn: 184133

A complex, expensive heuristic with little value in the current design.

llvm-svn: 184132

llvm-svn: 184131

llvm-svn: 184130