How to differentiate stack/heap addresses in llvm IR code?
I'd like to find a way to determine if a load/store operand in LLVM IR is a stack address or a heap address in an LLVM pass (the pass coded in C++), i.e.
if (inst is a store) {
if (inst->getOperand(1) is a heap address) {
// do something with the heap address
}
}
And operate similarly for loads. Looking in the IR code, they are referenced the same:
store i32 5, i32* %c, align 4 // storing value to a local variable
store i32 1, i32* %4, align 4 // storing value to something on the heap, do something with the heap address
Any ideas?
c++ llvm llvm-ir llvm-c++-api
add a comment |
I'd like to find a way to determine if a load/store operand in LLVM IR is a stack address or a heap address in an LLVM pass (the pass coded in C++), i.e.
if (inst is a store) {
if (inst->getOperand(1) is a heap address) {
// do something with the heap address
}
}
And operate similarly for loads. Looking in the IR code, they are referenced the same:
store i32 5, i32* %c, align 4 // storing value to a local variable
store i32 1, i32* %4, align 4 // storing value to something on the heap, do something with the heap address
Any ideas?
c++ llvm llvm-ir llvm-c++-api
add a comment |
I'd like to find a way to determine if a load/store operand in LLVM IR is a stack address or a heap address in an LLVM pass (the pass coded in C++), i.e.
if (inst is a store) {
if (inst->getOperand(1) is a heap address) {
// do something with the heap address
}
}
And operate similarly for loads. Looking in the IR code, they are referenced the same:
store i32 5, i32* %c, align 4 // storing value to a local variable
store i32 1, i32* %4, align 4 // storing value to something on the heap, do something with the heap address
Any ideas?
c++ llvm llvm-ir llvm-c++-api
I'd like to find a way to determine if a load/store operand in LLVM IR is a stack address or a heap address in an LLVM pass (the pass coded in C++), i.e.
if (inst is a store) {
if (inst->getOperand(1) is a heap address) {
// do something with the heap address
}
}
And operate similarly for loads. Looking in the IR code, they are referenced the same:
store i32 5, i32* %c, align 4 // storing value to a local variable
store i32 1, i32* %4, align 4 // storing value to something on the heap, do something with the heap address
Any ideas?
c++ llvm llvm-ir llvm-c++-api
c++ llvm llvm-ir llvm-c++-api
asked Nov 19 '18 at 17:48
user3043904user3043904
112
112
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
My frontend does this (well, something a little like it). You may not be able to do it well enough to reach your goals, but if you do, this is one approach:
Regard each return result of malloc()
(or whatever your allocator is called) as a heap variable and each result of alloca()
as a stack variable. For each of those, classify more values by looking at for(auto x : y->users())
; a getelementptr or cast of a malloc()
is also a heap variable.
However, this doesn't classify every value. Loading a pointer from a struct/array on the heap may return something on the stack and vice versa. Function arguments may be either. But perhaps you don't need to classify every value.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53380105%2fhow-to-differentiate-stack-heap-addresses-in-llvm-ir-code%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
My frontend does this (well, something a little like it). You may not be able to do it well enough to reach your goals, but if you do, this is one approach:
Regard each return result of malloc()
(or whatever your allocator is called) as a heap variable and each result of alloca()
as a stack variable. For each of those, classify more values by looking at for(auto x : y->users())
; a getelementptr or cast of a malloc()
is also a heap variable.
However, this doesn't classify every value. Loading a pointer from a struct/array on the heap may return something on the stack and vice versa. Function arguments may be either. But perhaps you don't need to classify every value.
add a comment |
My frontend does this (well, something a little like it). You may not be able to do it well enough to reach your goals, but if you do, this is one approach:
Regard each return result of malloc()
(or whatever your allocator is called) as a heap variable and each result of alloca()
as a stack variable. For each of those, classify more values by looking at for(auto x : y->users())
; a getelementptr or cast of a malloc()
is also a heap variable.
However, this doesn't classify every value. Loading a pointer from a struct/array on the heap may return something on the stack and vice versa. Function arguments may be either. But perhaps you don't need to classify every value.
add a comment |
My frontend does this (well, something a little like it). You may not be able to do it well enough to reach your goals, but if you do, this is one approach:
Regard each return result of malloc()
(or whatever your allocator is called) as a heap variable and each result of alloca()
as a stack variable. For each of those, classify more values by looking at for(auto x : y->users())
; a getelementptr or cast of a malloc()
is also a heap variable.
However, this doesn't classify every value. Loading a pointer from a struct/array on the heap may return something on the stack and vice versa. Function arguments may be either. But perhaps you don't need to classify every value.
My frontend does this (well, something a little like it). You may not be able to do it well enough to reach your goals, but if you do, this is one approach:
Regard each return result of malloc()
(or whatever your allocator is called) as a heap variable and each result of alloca()
as a stack variable. For each of those, classify more values by looking at for(auto x : y->users())
; a getelementptr or cast of a malloc()
is also a heap variable.
However, this doesn't classify every value. Loading a pointer from a struct/array on the heap may return something on the stack and vice versa. Function arguments may be either. But perhaps you don't need to classify every value.
edited Nov 20 '18 at 7:31
answered Nov 20 '18 at 6:51
arntarnt
5,06431728
5,06431728
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53380105%2fhow-to-differentiate-stack-heap-addresses-in-llvm-ir-code%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown