Commit Graph

95 Commits

Author SHA1 Message Date
Jonas Devlieghere 09ad8c8f73 Fix integer literals which are cast to bool
This change replaces built-in types that are implicitly converted to
booleans.

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

llvm-svn: 361580
2019-05-24 00:44:33 +00:00
Jonas Devlieghere 8b3af63b89 [NFC] Remove ASCII lines from comments
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

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

llvm-svn: 358135
2019-04-10 20:48:55 +00:00
Chandler Carruth 2946cd7010 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
2019-01-19 08:50:56 +00:00
Aleksandr Urakov 8cfb12b9bd [Symbol] Search symbols with name and type in a symbol file
Summary:
This patch adds possibility of searching a public symbol with name and type in
a symbol file, not only in a symtab. It is helpful when working with PE, because
PE's symtabs contain only imported / exported symbols only. Such a search is
required for e.g. evaluation of an expression that calls some function of
the debuggee.

Reviewers: zturner, asmith, labath, clayborg, espindola

Reviewed By: clayborg

Subscribers: davide, emaste, arichardson, aleksandr.urakov, jingham,
             lldb-commits, stella.stamenova

Tags: #lldb

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

llvm-svn: 347960
2018-11-30 06:56:37 +00:00
Jonas Devlieghere 672d2c1255 Remove comments after header includes.
This patch removes the comments following the header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.

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

llvm-svn: 346625
2018-11-11 23:16:43 +00:00
Zachary Turner 991e44534a Don't type-erase the SymbolContextItem enumeration.
When we get the `resolve_scope` parameter from the SB API, it's a
`uint32_t`.  We then pass it through all of LLDB this way, as a uint32.
This is unfortunate, because it means the user of an API never actually
knows what they're dealing with.  We can call it something like
`resolve_scope` and have comments saying "this is a value from the
`SymbolContextItem` enumeration, but it makes more sense to just have it
actually *be* the correct type in the actual C++ type system to begin
with.  This way the person reading the code just knows what it is.

The reason to use integers instead of enumerations for flags is because
when you do bitwise operations on enumerations they get promoted to
integers, so it makes it tedious to constantly be casting them back
to the enumeration types, so I've introduced a macro to make this
happen magically.  By writing LLDB_MARK_AS_BITMASK_ENUM after defining
an enumeration, it will define overloaded operators so that the
returned type will be the original enum.  This should address all
the mechanical issues surrounding using rich enum types directly.

This way, we get a better debugger experience, and new users to
the codebase can get more easily acquainted with the codebase because
their IDE features can help them understand what the types mean.

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

llvm-svn: 345313
2018-10-25 20:45:19 +00:00
Davide Italiano ae3f793e9e Rollback "Fix raw address breakpoints not resolving".
It broke a bunch of bots. Ted confirmed, but can't revert for
now so I'm reverting on his behalf.

llvm-svn: 341878
2018-09-10 23:09:09 +00:00
Ted Woodward 860bafa07d Fix raw address breakpoints not resolving
Summary: An address breakpoint of the form "b 0x1000" won't resolve if it's created while the process isn't running. This patch deletes Address::SectionWasDeleted, renames Address::SectionWasDeletedPrivate to SectionWasDeleted (and makes it public), and changes the section check in Breakpoint::ModulesChanged back to its original form

Reviewers: jingham, #lldb

Reviewed By: jingham

Subscribers: davide, lldb-commits

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

llvm-svn: 341849
2018-09-10 18:19:01 +00:00
Tatyana Krasnukha 04803b3ef2 Change AddressClass type from 'enum' to 'enum class'.
If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa.

llvm-svn: 335599
2018-06-26 13:06:54 +00:00
Adrian Prantl 05097246f3 Reflow paragraphs in comments.
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.

FYI, the script I used was:

import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
  header = ""
  text = ""
  comment = re.compile(r'^( *//) ([^ ].*)$')
  special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
  for line in f:
      match = comment.match(line)
      if match and not special.match(match.group(2)):
          # skip intentionally short comments.
          if not text and len(match.group(2)) < 40:
              out.write(line)
              continue

          if text:
              text += " " + match.group(2)
          else:
              header = match.group(1)
              text = match.group(2)

          continue

      if text:
          filled = textwrap.wrap(text, width=(78-len(header)),
                                 break_long_words=False)
          for l in filled:
              out.write(header+" "+l+'\n')
              text = ""

      out.write(line)

os.rename(tmp, sys.argv[1])

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

llvm-svn: 331197
2018-04-30 16:49:04 +00:00
Pavel Labath 5f19b90783 Move ArchSpec to the Utility module
The rationale here is that ArchSpec is used throughout the codebase,
including in places which should not depend on the rest of the code in
the Core module.

This commit touches many files, but most of it is just renaming of
 #include lines. In a couple of cases, I removed the #include ArchSpec
line altogether, as the file was not using it. In one or two places,
this necessitated adding other #includes like lldb-private-defines.h.

llvm-svn: 318048
2017-11-13 16:16:33 +00:00
Pavel Labath c3c721222d Fix backtrace of noreturn functions situated at the end of a module
Summary:
When a call instruction is the last instruction in a function, the
backtrace PC will point past the end of the function. We already had
special code to handle that, but we did not handle the case where the PC
ends up outside of the bounds of the module containing the function,
which is a situation that occured in TestNoreturnUnwind on android for
some arch/compiler combinations.

I fix this by adding an argument to Address resolution code which states
that we are ok with addresses pointing to the end of a module/section to
resolve to that module/section.

I create a reproducible test case for this situation by hand-crafting an
executable which has a noreturn function at the end of a module.

Reviewers: jasonmolenda, jingham

Subscribers: lldb-commits

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

llvm-svn: 304976
2017-06-08 13:26:35 +00:00
Zachary Turner 97206d5727 Rename Error -> Status.
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.

A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error".  Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around.  Hopefully nothing too
serious.

llvm-svn: 302872
2017-05-12 04:51:55 +00:00
Zachary Turner 2f3df6137a iwyu fixes for lldbCore.
This adjusts header file includes for headers and source files
in Core.  In doing so, one dependency cycle is eliminated
because all the includes from Core to that project were dead
includes anyway.  In places where some files in other projects
were only compiling due to a transitive include from another
header, fixups have been made so that those files also include
the header they need.  Tested on Windows and Linux, and plan
to address failures on OSX and FreeBSD after watching the
bots.

llvm-svn: 299714
2017-04-06 21:28:29 +00:00
Zachary Turner 29cb868aa4 Isolate Target-specific functionality of DataExtractor.
In an effort to move the various DataBuffer / DataExtractor
classes from Core -> Utility, we have to separate the low-level
functionality from the higher level functionality.  Only a
few functions required anything other than reading/writing
raw bytes, so those functions are separated out into a
more appropriate area.  Specifically, Dump() and DumpHexBytes()
are moved into free functions in Core/DumpDataExtractor.cpp,
and GetGNUEHPointer is moved into a static function in the
only file that it's referenced from.

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

llvm-svn: 296910
2017-03-03 20:57:05 +00:00
Zachary Turner c156427ded Don't allow direct access to StreamString's internal buffer.
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.

Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.

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

llvm-svn: 287152
2016-11-16 21:15:24 +00:00
Kate Stone b9c1b51e45 *** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style.  This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort.  Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit.  The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

    find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
    find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit.  There are alternatives available that will attempt
to look through this change and find the appropriate prior commit.  YMMV.

llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Zachary Turner 9b1669ae35 Remove std::atomic from lldb::Address.
std::atomic<uint64_t> requires 64-bit alignment in order to
guarantee atomicity.  Normally the compiler is pretty good about
aligning types, but an exception to this is when the type is
passed by value as a function parameter.  In this case, if your
stack is 4-byte aligned, most modern compilers (including clang
as of LLVM 4.0) fail to align the type, rendering the atomicity
ineffective.

A deeper investigation of the class's implementation suggests
that the use of atomic was in vain anyway, because if the class
were to be shared amongst multiple threads, there were already
other data races present, and that the proper way to ensure
thread-safe access to this data would be to use a mutex from a
higher level.

Since the std::atomic was not serving its intended purpose anyway,
and since the presence of it generates compiler errors on some
platforms that cannot be workaround, we remove std::atomic from
Address here.  Although unlikely, if data races do resurface
the proper fix should involve a mutex from a higher level, or an
attempt to limit the Address's access to a single thread.

llvm-svn: 279994
2016-08-29 19:30:26 +00:00
Greg Clayton 4c8e782806 Fix the use of lldb::eSymbolContextVariable.
In Address.cpp, we were asking for the lldb::eSymbolContextVariable to be resolved, yet we weren't using the variable. This code gets called when disassembling and can cause the manual creation of all global variables variables which can take minutes. Removing eSymbolContextVariable allows disassembly to not create these long pauses.

In Module.cpp, if someone only specified the lldb::eSymbolContextVariable flag, we would not look into a module's debug info, now we will.

<rdar://problem/26907449>

llvm-svn: 273307
2016-06-21 20:00:36 +00:00
Eugene Zelenko 896ddd03e9 Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes.
llvm-svn: 262441
2016-03-02 01:09:03 +00:00
Tamas Berghammer 72ac8a840f Handle the case when a variable is only valid in part of the enclosing scope
DWARF stores this information in the DW_AT_start_scope attribute. This
CL add support for this attribute and also changes the functions
displaying frame variables to only display the variables currently in
scope.

Differential revision: http://reviews.llvm.org/D17449

llvm-svn: 261858
2016-02-25 12:23:37 +00:00
Jason Molenda 62e0681afb Add -Wimplicit-fallthrough command line option to clang in
the xcode project file to catch switch statements that have a
case that falls through unintentionally.

Define LLVM_FALLTHROUGH to indicate instances where a case has code
and intends to fall through.  This should be in llvm/Support/Compiler.h;
Peter Collingbourne originally checked in there (r237766), then
reverted (r237941) because he didn't have time to mark up all the
'case' statements that were intended to fall through.  I put together
a patch to get this back in llvm http://reviews.llvm.org/D17063 but
it hasn't been approved in the past week.  I added a new
lldb-private-defines.h to hold the definition for now.

Every place in lldb where there is a comment that the fall-through
is intentional, I added LLVM_FALLTHROUGH to silence the warning.
I haven't tried to identify whether the fallthrough is a bug or
not in the other places.

I haven't tried to add this to the cmake option build flags.
This warning will only work for clang.

This build cleanly (with some new warnings) on macosx with clang
under xcodebuild, but if this causes problems for people on other
configurations, I'll back it out.

llvm-svn: 260930
2016-02-16 04:14:33 +00:00
Jim Ingham cbff63adb4 Fixed a couple of places where we were getting the module from a
section and using it w/o checking that it was valid.  This can
cause crashes - usually when tearing down a target.

llvm-svn: 259237
2016-01-29 20:21:33 +00:00
Bruce Mitchener 9ccb970f23 Make lldb::endian::InlHostByteOrder() private.
Summary:
Since this is within the lldb namespace, the compiler tries to
export a symbol for it. Unfortunately, since it is inlined, the
symbol is hidden and this results in a mess of warnings when
building on OS X with cmake.

Moving it to the lldb_private namespace eliminates that problem.

Reviewers: clayborg

Subscribers: emaste, lldb-commits

Differential Revision: http://reviews.llvm.org/D14417

llvm-svn: 252396
2015-11-07 04:40:13 +00:00
Jaydeep Patil 44d07fcc7c [LLDB][MIPS] microMIPS breakpoints, disassembly and compressed addresses
SUMMARY:
    This patch detects microMIPS symbols, sets breakpoints using un-compressed address and 
    display disassembly in mixed mode for microMIPS applications (running on bare-iron targets).

    Reviewers: clayborg
    Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
    Differential Revision: http://reviews.llvm.org/D12079

llvm-svn: 248248
2015-09-22 06:36:56 +00:00
Tamas Berghammer 25b9f7ebd3 Use eAddressClassCode for address lookup for opcodes for stack frames
It is required because of the following edge case on arm:

bx <addr>   Non-tail call in a no return function
[data-pool] Marked with $d mapping symbol

The return address of the function call will point to the data pool but
we have to treat it as code so the StackFrame can calculate the symbols
correctly.

Differential revision: http://reviews.llvm.org/D12556

llvm-svn: 246958
2015-09-07 09:58:09 +00:00
Greg Clayton 358cf1ea30 Resubmitting 240466 after fixing the linux test suite failures.
A few extras were fixed

- Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. 
- Since some places want to access the address as a reference, I added a few new functions to symbol:
    Address &Symbol::GetAddressRef();
    const Address &Symbol::GetAddressRef() const;

Linux test suite passes just fine now.

<rdar://problem/21494354>

llvm-svn: 240702
2015-06-25 21:46:34 +00:00
Ilia K 6e46512ec3 Don't print a type of variable in Address::Dump if it's unknown (i.e. nullptr)
Summary: This patch fixes dereferencing of nullptr in case when GetType() returns that.

Reviewers: jingham, granata.enrico, clayborg

Reviewed By: clayborg

Subscribers: lldb-commits, granata.enrico, clayborg, jingham

Differential Revision: http://reviews.llvm.org/D9274

llvm-svn: 235982
2015-04-28 12:45:57 +00:00
Jason Molenda c980fa92eb Change the default disassembly format again. First attempt at
changing it was in r219544 - after living on that for a few 
months, I wanted to take another crack at this.

The disassembly-format setting still exists and the old format
can be user specified with a setting like

${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}: 

This patch was discussed in http://reviews.llvm.org/D7578

<rdar://problem/19726421>

llvm-svn: 229186
2015-02-13 23:24:21 +00:00
Greg Clayton 2501e5e2ea Modified LLDB to be able to lookup global variables by address.
This is done by adding a "Variable *" to SymbolContext and allowing SymbolFile::ResolveSymbolContext() so if an address is resolved into a symbol context, we can include the global or static variable for that address.

This means you can now find global variables that are merged globals when doing a "image lookup --verbose --address 0x1230000". Previously we would resolve a symbol and show "_MergedGlobals123 + 1234". But now we can show the global variable name.

The eSymbolContextEverything purposely does not include the new eSymbolContextVariable in its lookup since stack frame code does many lookups and we don't want it triggering the global variable lookups.

<rdar://problem/18945678> 

llvm-svn: 226084
2015-01-15 02:59:20 +00:00
Jim Ingham 4af5961caa Audit uses of ConstString::AsCString() to make sure they weren't assuming
they would always get a non-NULL string back.

<rdar://problem/19298575>

llvm-svn: 224602
2014-12-19 19:20:44 +00:00
Jason Molenda aff1b357b0 Add a new disassembly-format specification so that the disassembler
output style can be customized.  Change the built-in default to be
more similar to gdb's disassembly formatting.

The disassembly-format for a gdb-like output is

${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>: 

The disassembly-format for the lldb style output is

{${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}: 

The two backticks in the lldb style formatter triggers the sub-expression evaluation in
CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to
use ' characters instead of ` would work around that.

<rdar://problem/9885398> 

llvm-svn: 219544
2014-10-10 23:07:36 +00:00
Saleem Abdulrasool 324a103619 sweep up -Wformat warnings from gcc
This is a purely mechanical change explicitly casting any parameters for printf
style conversion.  This cleans up the warnings emitted by gcc 4.8 on Linux.

llvm-svn: 205607
2014-04-04 04:06:10 +00:00
Jim Ingham 1460e4bf0e Get the breakpoint setting, and the Mac OS X DYLD trampolines and expression evaluator to handle Indirect
symbols correctly.  There were a couple of pieces to this.

1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created
   it needs to resolve the symbol and actually set the site at its target.
2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the
   specified address, so somem machinery was needed to specify that.
3) I added some info to the break list output for indirect symbols so you could see what was happening. 
   Also I made it clear when we re-route through re-exported symbols.
4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X
   and the other posix systems.  If we find a platform that doesn't do it this way, they can override the
   call in Process.
5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had
   been broadcast, the event coalescing would cause you to miss the ThreadPlan running event.  So I added
   a way to override the coalescing.
6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols.

<rdar://problem/15280639>

llvm-svn: 198976
2014-01-10 23:46:59 +00:00
Greg Clayton d5944cd118 For logical backtrace work, lldb needs to track Module unloads etc & symoblicate an address based on a point in time
<rdar://problem/15314403> 

This patch adds a new lldb_private::SectionLoadHistory class that tracks what shared libraries were loaded given a process stop ID. This allows us to keep a history of the sections that were loaded for a time T. Many items in history objects will rely upon the process stop ID in the future.

llvm-svn: 196557
2013-12-06 01:12:00 +00:00
Greg Clayton b35db6399d Fixed the the breakpoint test case failures.
There were 6 on darwin. All of these were related to the recent changes for exec.

llvm-svn: 194298
2013-11-09 00:03:31 +00:00
Greg Clayton cae5652838 Improve lldb_private::Address to detect when section was deleted and not return bogus values for GetLoadAddress() and GetFileAddress().
llvm-svn: 194120
2013-11-06 02:29:13 +00:00
Jim Ingham f0649a6c0e Include file cleanup.
llvm-svn: 190084
2013-09-05 18:57:48 +00:00
Michael Sartain a7499c9830 Split symbol support for ELF and Linux.
llvm-svn: 185366
2013-07-01 19:45:50 +00:00
Jim Ingham d3480f5851 Address::GetSection() turns a weak pointer to a shared pointer which is a little slow. So in Address::operator== & != do the
cheap GetOffset() comparison first and only compare the sections if that is true.

llvm-svn: 183452
2013-06-06 22:16:56 +00:00
Daniel Malea 4818460269 Fix data race in Address class by wrapping m_offset in std::atomic
llvm-svn: 180047
2013-04-22 20:59:13 +00:00
Greg Clayton 9422dd64f8 <rdar://problem/13338643>
DWARF with .o files now uses 40-60% less memory!

Big fixes include:
- Change line table internal representation to contain "file addresses". Since each line table is owned by a compile unit that is owned by a module, it makes address translation into lldb_private::Address easy to do when needed.
- Removed linked address members/methods from lldb_private::Section and lldb_private::Address
- lldb_private::LineTable can now relink itself using a FileRangeMap to make it easier to re-link line tables in the future
- Added ObjectFile::ClearSymtab() so that we can get rid of the object file symbol tables after we parse them once since they are not needed and kept memory allocated for no reason
- Moved the m_sections_ap (std::auto_ptr to section list) and m_symtab_ap (std::auto_ptr to the lldb_private::Symtab) out of each of the ObjectFile subclasses and put it into lldb_private::ObjectFile.
- Changed how the debug map is parsed and stored to be able to:
    - Lazily parse the debug map for each object file
    - not require the address map for a .o file until debug information is linked for a .o file

llvm-svn: 176454
2013-03-04 21:46:16 +00:00
Matt Kopec 00049b8b96 Add GNU indirect function support in expressions for Linux.
llvm-svn: 176206
2013-02-27 20:13:38 +00:00
Greg Clayton 72310355ff <rdar://problem/13265297>
StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.

llvm-svn: 175953
2013-02-23 04:12:47 +00:00
Greg Clayton c7bece56fa <rdar://problem/13069948>
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.

So I defined a new "lldb::offset_t" which should be used for all file offsets.

After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.

Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.

llvm-svn: 173463
2013-01-25 18:06:21 +00:00
Daniel Malea d01b2953fa Resolve printf formatting warnings on Linux:
- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!

llvm-svn: 168945
2012-11-29 21:49:15 +00:00
Greg Clayton 1f7460716b <rdar://problem/11757916>
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". 
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()

Cleaned up header includes a bit as well.

llvm-svn: 162860
2012-08-29 21:13:06 +00:00
Greg Clayton 23f59509a8 Ran the static analyzer on the codebase and found a few things.
llvm-svn: 160338
2012-07-17 03:23:13 +00:00
Greg Clayton c3a86bf9f0 Modifying the "address" format, which prints a pointer and a description of what it points to, to detect when the deref of that pointer points to something valid. So if you have:
% cat sp.cpp 
    #include <tr1/memory>

    class A
    {
    public:
        A (): m_i (12) {}
        virtual ~A() {}
    private:
        int m_i;
    };

    int main (int argc, char const *argv[], char const *envp[])
    {
        A *a_pointers[2] = { NULL, NULL };
        A a1;
        A a2;
        a_pointers[0] = &a1;
        a_pointers[1] = &a2;
        return 0;
    }


And you stop at the "return 0", you can now read memory using the "address" format and see:

(lldb) memory read --format address `&a_pointers`
0x7fff5fbff870: 0x00007fff5fbff860 -> 0x00000001000010b0 vtable for A + 16
0x7fff5fbff878: 0x00007fff5fbff850 -> 0x00000001000010b0 vtable for A + 16
0x7fff5fbff880: 0x00007fff5fbff8d0
0x7fff5fbff888: 0x00007fff5fbff8c0
0x7fff5fbff890: 0x0000000000000001
0x7fff5fbff898: 0x36d54c275add2294
0x7fff5fbff8a0: 0x00007fff5fbff8b0
0x7fff5fbff8a8: 0x0000000100000bb4 a.out`start + 52

Note the extra dereference that was applied to 0x00007fff5fbff860 and 0x00007fff5fbff850 so we can see that these are "A" classes.

llvm-svn: 160085
2012-07-11 22:18:24 +00:00
Greg Clayton c4a8a76048 <rdar://problem/11455398>
Add "--name" option to "image lookup" that will search both functions and symbols.

Also made all of the output from any of the "image lookup" commands be the same regardless of the lookup type (function name, symbol name, func or symbol, file and line, address, etc). The --verbose or -v option also will expand the results as needed and display things so they look the same.

llvm-svn: 156835
2012-05-15 18:43:44 +00:00