|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
| #
195a8b97 |
| 05-Apr-2022 |
Luboš Luňák <[email protected]> |
don't extra notify ModulesDidLoad() from LoadModuleAtAddress()
Places calling LoadModuleAtAddress() already call ModulesDidLoad() after a loop calling LoadModuleAtAddress(), so it's not necessary to
don't extra notify ModulesDidLoad() from LoadModuleAtAddress()
Places calling LoadModuleAtAddress() already call ModulesDidLoad() after a loop calling LoadModuleAtAddress(), so it's not necessary to call it from there, and the batched ModulesDidLoad() may be more efficient than this place calling it one after one.
This also makes the ModuleLoadedNotifys test pass on Linux now that the duplicates no longer bring down the average of modules notified per call.
Differential Revision: https://reviews.llvm.org/D123128
show more ...
|
| #
e67cee09 |
| 29-Mar-2022 |
Pavel Labath <[email protected]> |
[lldb] Avoid duplicate vdso modules when opening core files
When opening core files (and also in some other situations) we could end up with two vdso modules. This could happen because the vdso modu
[lldb] Avoid duplicate vdso modules when opening core files
When opening core files (and also in some other situations) we could end up with two vdso modules. This could happen because the vdso module is very special, and over the years, we have accumulated various ways to load it.
In D10800, we added one mechanism for loading it, which took the form of a generic load-from-memory capability. Unfortunately loading an elf file from memory is not possible (because the loader never loads the entire file), and our attempts to do so were causing crashes. So, in D34352, we partially reverted D10800 and implemented a custom mechanism specific to the vdso.
Unfortunately, enough of D10800 remained such that, under the right circumstances, it could end up loading a second (non-functional) copy of the vdso module. This happened when the process plugin did not support the extended MemoryRegionInfo query (added in D22219, to workaround a different bug), which meant that the loader plugin was not able to recognise that the linux-vdso.so.1 module (this is how the loader calls it) is in fact the same as the [vdso] module (the name used in /proc/$PID/maps) we loaded before. This typically happened in a core file, as they don't store this kind of information.
This patch fixes the issue by completing the revert of D10800 -- the memory loading code is removed completely. It also reduces the scope of the hackaround introduced in D22219 -- it isn't completely sound and is only relevant for fairly old (but still supported) versions of android.
I added the memory loading logic to the wasm dynamic loader, which has since appeared and is relying on this feature (it even has a test). As far as I can tell loading wasm modules from memory is possible and reliable. MachO memory loading is not affected by this patch, as it uses a completely different code path.
Since the scenarios/patches I described came without test cases, I have created two new gdb-client tests cases for them. They're not particularly readable, but right now, this is the best way we can simulate the behavior (bugs) of a particular dynamic linker.
Differential Revision: https://reviews.llvm.org/D122660
show more ...
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
6fa1b4ff |
| 21-Oct-2021 |
Pavel Labath <[email protected]> |
Remove ConstString from DynamicLoader, JITLoader and Instruction plugin names
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
| #
76e47d48 |
| 26-May-2021 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivale
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivalent.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D103084
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
| #
0610a25a |
| 09-Oct-2020 |
Pavel Labath <[email protected]> |
[lldb] Delete copy operations on PluginInterface class
This is a polymorphic class, copying it is a bad idea.
This was not a problem because most classes inheriting from it were deleting their copy
[lldb] Delete copy operations on PluginInterface class
This is a polymorphic class, copying it is a bad idea.
This was not a problem because most classes inheriting from it were deleting their copy operations themselves. However, this enables us to delete those explicit deletions, and ensure noone forgets to add them in the future.
show more ...
|
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2 |
|
| #
642bc15d |
| 11-Feb-2020 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Remove several inefficient ConstString -> const char * -> StringRef conversions
StringRef will call strlen on the C string which is inefficient (as ConstString already knows the string l
[lldb][NFC] Remove several inefficient ConstString -> const char * -> StringRef conversions
StringRef will call strlen on the C string which is inefficient (as ConstString already knows the string lenght and so does StringRef). This patch replaces all those calls with GetStringRef() which doesn't recompute the length.
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc1 |
|
| #
80814287 |
| 24-Jan-2020 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp ----------------------------------------
[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
show more ...
|
|
Revision tags: llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
| #
8b3af63b |
| 10-Apr-2019 |
Jonas Devlieghere <[email protected]> |
[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
[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
show more ...
|
| #
1724a179 |
| 08-Apr-2019 |
Jason Molenda <[email protected]> |
Rename Target::GetSharedModule to Target::GetOrCreateModule.
Add a flag to control whether the ModulesDidLoad notification is called when a module is added. If the notifications are disabled, the c
Rename Target::GetSharedModule to Target::GetOrCreateModule.
Add a flag to control whether the ModulesDidLoad notification is called when a module is added. If the notifications are disabled, the caller must call ModulesDidLoad after adding all the new modules, but postponing this notification until they're all batched up can allow for better efficiency than notifying one-by-one.
Change the name of the ModuleList notifier functions that a subclass can implement to start with 'Notify' to make it clear what they are. Add a NotifyModulesRemoved.
Add header documentation for the changed/updated methods.
Added defaulted-value 'notify' argument to ModuleList Append, AppendIfNeeded, and Remove because callers working with a local ModuleList don't have an obvious idea of what notify means in this context. When the ModuleList is a part of the Target class, the notify behavior matters.
DynamicLoaderDarwin has been updated so that libraries being added/removed are correctly batched up before notifications are sent. Added the TestModuleLoadedNotifys.py test to run on Darwin to test this.
<rdar://problem/48293064>
Differential Revision: https://reviews.llvm.org/D60172
llvm-svn: 357955
show more ...
|
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3 |
|
| #
d5b44036 |
| 13-Feb-2019 |
Jonas Devlieghere <[email protected]> |
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 ...
|
|
Revision tags: llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
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 ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
| #
672d2c12 |
| 11-Nov-2018 |
Jonas Devlieghere <[email protected]> |
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 of
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
show more ...
|
|
Revision tags: llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
| #
8f3be7a3 |
| 01-Nov-2018 |
Jonas Devlieghere <[email protected]> |
[FileSystem] Move path resolution logic out of FileSpec
This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead.
Differential
[FileSystem] Move path resolution logic out of FileSpec
This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead.
Differential revision: https://reviews.llvm.org/D53915
llvm-svn: 345890
show more ...
|
| #
dbd7faba |
| 01-Nov-2018 |
Jonas Devlieghere <[email protected]> |
[FileSystem] Remove Exists() from FileSpec
This patch removes the Exists method from FileSpec and updates its uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D538
[FileSystem] Remove Exists() from FileSpec
This patch removes the Exists method from FileSpec and updates its uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53845
llvm-svn: 345854
show more ...
|
| #
f9a07e9f |
| 20-Sep-2018 |
Jonas Devlieghere <[email protected]> |
[NFC] Turn "load dependent files" boolean into an enum
This is an NFC commit to refactor the "load dependent files" parameter from a boolean to an enum value. We want to be able to specify a default
[NFC] Turn "load dependent files" boolean into an enum
This is an NFC commit to refactor the "load dependent files" parameter from a boolean to an enum value. We want to be able to specify a default, in which case we decide whether or not to load the dependent files based on whether the target is an executable or not (i.e. a dylib).
This is a dependency for D51934.
Differential revision: https://reviews.llvm.org/D51859
llvm-svn: 342633
show more ...
|
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2 |
|
| #
05097246 |
| 30-Apr-2018 |
Adrian Prantl <[email protected]> |
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 r
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
show more ...
|
|
Revision tags: llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2 |
|
| #
97206d57 |
| 12-May-2017 |
Zachary Turner <[email protected]> |
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 h
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
show more ...
|
|
Revision tags: llvmorg-4.0.1-rc1 |
|
| #
2f3df613 |
| 06-Apr-2017 |
Zachary Turner <[email protected]> |
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 w
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
show more ...
|
| #
5ba3d85c |
| 31-Mar-2017 |
Nitesh Jain <[email protected]> |
[LLDB][MIPS] Check if memory_info.GetName() is empty before finding corresponding module.
Reviewers: labath, clayborg
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
Differential Revision: h
[LLDB][MIPS] Check if memory_info.GetName() is empty before finding corresponding module.
Reviewers: labath, clayborg
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
Differential Revision: https://reviews.llvm.org/D30454
llvm-svn: 299196
show more ...
|
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3 |
|
| #
519b0816 |
| 28-Feb-2017 |
Jim Ingham <[email protected]> |
Fix a bug in r294611 w.r.t. Darwin Kernel debugging.
<rdar://problem/30735021>
llvm-svn: 296504
|
|
Revision tags: llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
| #
b9c1b51e |
| 06-Sep-2016 |
Kate Stone <[email protected]> |
*** 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 t
*** 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
show more ...
|
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1 |
|
| #
d7d69f80 |
| 22-Jul-2016 |
Tamas Berghammer <[email protected]> |
Support loading files even when incorrect file name specified by the linker
"Incorrect" file name seen on Android whene the main executable is called "app_process32" (or 64) but the linker specifies
Support loading files even when incorrect file name specified by the linker
"Incorrect" file name seen on Android whene the main executable is called "app_process32" (or 64) but the linker specifies the package name (e.g. com.android.calculator2). Additionally it can be present in case of some linker bugs.
This CL adds logic to try to fetch the correct file name from the proc file system based on the base address sepcified by the linker in case we are failed to load the module by name.
Differential revision: http://reviews.llvm.org/D22219
llvm-svn: 276411
show more ...
|
| #
5d410241 |
| 17-Jul-2016 |
Jason Molenda <[email protected]> |
Initialize the "is_loaded" local in LoadModuleAtAddress in case Process::GetFileLoadAddress fails to set it to a real value. (fixing "conditional use of garbage value" clang warning)
llvm-svn: 2757
Initialize the "is_loaded" local in LoadModuleAtAddress in case Process::GetFileLoadAddress fails to set it to a real value. (fixing "conditional use of garbage value" clang warning)
llvm-svn: 275731
show more ...
|
|
Revision tags: llvmorg-3.8.1, llvmorg-3.8.1-rc1 |
|
| #
34ede34a |
| 03-Mar-2016 |
Eugene Zelenko <[email protected]> |
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes.
llvm-svn: 262570
|
|
Revision tags: llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1, llvmorg-3.7.0, llvmorg-3.7.0-rc4 |
|
| #
42ecef3b |
| 24-Aug-2015 |
Tamas Berghammer <[email protected]> |
Add absolute load address support for the DynamicLoader plugins
The POSIX linker generally reports the load bias for the loaded libraries but in some case it is useful to handle a library based on a
Add absolute load address support for the DynamicLoader plugins
The POSIX linker generally reports the load bias for the loaded libraries but in some case it is useful to handle a library based on absolute load address. Example usecases: * Windows linker uses absolute addresses * Library list came from different source (e.g. /proc/<pid>/maps)
Differential revision: http://reviews.llvm.org/D12233
llvm-svn: 245834
show more ...
|