summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/DumpDataExtractor.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb][NFC] Move Address and AddressRange functions out of Stream and let ↵Raphael Isemann2019-12-051-3/+4
| | | | | | | | | | | | | | | | | | | | | | them take raw_ostream Summary: Yet another step on the long road towards getting rid of lldb's Stream class. We probably should just make this some kind of member of Address/AddressRange, but it seems quite often we just push in random integers in there and this is just about getting rid of Stream and not improving arbitrary APIs. I had to rename another `DumpAddress` function in FormatEntity that is dumping the content of an address to make Clang happy. Reviewers: labath Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71052
* [Core] Remove unused dependency on clangASTAlex Langford2019-09-281-3/+0
| | | | llvm-svn: 373134
* [Core] Remove use of ClangASTContext in DumpDataExtractorAlex Langford2019-09-061-52/+28
| | | | | | | | | | | | | Summary: DumpDataExtractor uses ClangASTContext in order to get the proper llvm fltSemantics for the type it needs so that it can dump floats in a more precise way. However, there's no reason that this behavior needs to be specific ClangASTContext. Instead, I think it makes sense to ask TypeSystems for the float semantics for a type of a given size. Differential Revision: https://reviews.llvm.org/D67239 llvm-svn: 371258
* [lldb] Limit the amount of zeroes we use for padding when printing small floatsRaphael Isemann2019-09-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We got a radar that printing small floats is not very user-friendly in LLDB as we print them with up to 100 leading zeroes before starting to use scientific notation. This patch changes this by already using scientific notation when we hit 6 padding zeroes by default and moves this value into a target setting so that users can just set this number back to 100 if they for some reason preferred the old behaviour. This new setting is influencing how we format data, so that's why we have to reset the data visualisation cache when it is changed. Note that we have always been using scientific notation for large numbers because it seems that the LLVM implementation doesn't support printing out the padding zeroes for them. I would have fixed that if it was trivial, but looking at the LLVM implementation for this it seems that this is not as trivial as it sounds. I would say we look into this if we ever get a bug report about someone wanting to have a large amount of trailing zeroes in their numbers instead of using scientific notation. Fixes rdar://39744137 Reviewers: #lldb, clayborg Reviewed By: clayborg Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67001 llvm-svn: 370880
* [Core] Use GetAPInt instead of constructing APInts in placeAlex Langford2019-08-281-9/+14
| | | | | | | GetAPInt should be able to handle all cases. I have plans to generalize the float dumping logic and this makes it easier to do later. llvm-svn: 370255
* [Core] GetAPInt should return an OptionalAlex Langford2019-08-261-16/+19
| | | | | | | | The current implementation returns a bool for indicating success and whether or not the APInt passed by reference was populated. Instead of doing that, I think it makes more sense to return an Optional<APInt>. llvm-svn: 369970
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-131-3/+3
| | | | | | | | | | | | | | | | | 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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* Remove comments after header includes.Jonas Devlieghere2018-11-111-17/+17
| | | | | | | | | | 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
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [lldb][PPC64] Fixed long double variables dumpPavel Labath2018-01-171-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: LLDB's DumpDataExtractor was not prepared to handle PowerPC's long double type: PPCDoubleDouble. As it is somewhat special, treating it as other regular float types resulted in getting wrong information about it. In this particular case, llvm::APFloat::getSizeInBits(PPCDoubleDouble) was returning 0. This caused the TestSetValues.py test to fail, because lldb would abort on an assertion failure on APInt(), because of the invalid size. Since in the PPC case the value of item_byte_size was correct and the getSizeInBits call was only added to support x87DoubleExtended semantics, this restricts the usage of getSizeInBits to the x87 semantics. Reviewers: labath, clayborg Reviewed By: labath Subscribers: llvm-commits, anajuliapc, alexandreyy, lbianc, lldb-commits Differential Revision: https://reviews.llvm.org/D42083 Author: Leandro Lupori <leandro.lupori@gmail.com> llvm-svn: 322666
* Fix dumping of characters with non-standard sizesPetr Pavlu2017-10-111-0/+7
| | | | | | | | | | | | | | | | * Prevent dumping of characters in DumpDataExtractor() with item_byte_size bigger than 8 bytes. This case is not supported by the code and results in a crash because the code calls DataExtractor::GetMaxU64Bitfield() -> GetMaxU64() that asserts for byte size > 8 bytes. * Teach DataExtractor::GetMaxU64(), GetMaxU32(), GetMaxS64() and GetMaxU64_unchecked() how to handle byte sizes that are not a multiple of 2. This allows DumpDataExtractor() to dump characters and booleans with item_byte_size in the interval of [1, 8] bytes. Values that are not a multiple of 2 would previously result in a crash because they were not handled by GetMaxU64(). llvm-svn: 315444
* Pass in the disassembler flavor when disassembling inJason Molenda2017-07-111-1/+2
| | | | | | | | DumpDataExtractor. Patch from Jeffrey Crowell, https://reviews.llvm.org/D34929 llvm-svn: 307618
* iwyu fixes for lldbCore.Zachary Turner2017-04-061-0/+22
| | | | | | | | | | | | | | 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
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-041-1/+1
| | | | llvm-svn: 296943
* Fix DataExtractor failures.Zachary Turner2017-03-031-0/+14
| | | | | | | Some code that doesn't get compiled on Windows had some references that needed updating, and I missed those. llvm-svn: 296930
* Isolate Target-specific functionality of DataExtractor.Zachary Turner2017-03-031-0/+788
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
OpenPOWER on IntegriCloud