how to find symbols that should be exported
up vote
0
down vote
favorite
If you compile with -fvisibility=hidden
or with msvc you have to export your shared library symbols manually. As an experiment, how could you find them automatically with AST matchers (clang-query)?
It's not that easy as a minimal set of export declarations is desired and things quickly get complicated with inline functions, templates, out-of-line template definitions, static data members, etc.
A general answer in LLVM IR or C++ standard parlance is also welcome.
c++ shared-libraries llvm visibility clang-query
add a comment |
up vote
0
down vote
favorite
If you compile with -fvisibility=hidden
or with msvc you have to export your shared library symbols manually. As an experiment, how could you find them automatically with AST matchers (clang-query)?
It's not that easy as a minimal set of export declarations is desired and things quickly get complicated with inline functions, templates, out-of-line template definitions, static data members, etc.
A general answer in LLVM IR or C++ standard parlance is also welcome.
c++ shared-libraries llvm visibility clang-query
1
automatically? exports should be properly designed and documented
– VTT
Nov 11 at 7:48
Yeah but that's a different story.
– Trass3r
Nov 11 at 8:31
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
If you compile with -fvisibility=hidden
or with msvc you have to export your shared library symbols manually. As an experiment, how could you find them automatically with AST matchers (clang-query)?
It's not that easy as a minimal set of export declarations is desired and things quickly get complicated with inline functions, templates, out-of-line template definitions, static data members, etc.
A general answer in LLVM IR or C++ standard parlance is also welcome.
c++ shared-libraries llvm visibility clang-query
If you compile with -fvisibility=hidden
or with msvc you have to export your shared library symbols manually. As an experiment, how could you find them automatically with AST matchers (clang-query)?
It's not that easy as a minimal set of export declarations is desired and things quickly get complicated with inline functions, templates, out-of-line template definitions, static data members, etc.
A general answer in LLVM IR or C++ standard parlance is also welcome.
c++ shared-libraries llvm visibility clang-query
c++ shared-libraries llvm visibility clang-query
edited Nov 11 at 12:17
asked Nov 11 at 7:00
Trass3r
2,8001530
2,8001530
1
automatically? exports should be properly designed and documented
– VTT
Nov 11 at 7:48
Yeah but that's a different story.
– Trass3r
Nov 11 at 8:31
add a comment |
1
automatically? exports should be properly designed and documented
– VTT
Nov 11 at 7:48
Yeah but that's a different story.
– Trass3r
Nov 11 at 8:31
1
1
automatically? exports should be properly designed and documented
– VTT
Nov 11 at 7:48
automatically? exports should be properly designed and documented
– VTT
Nov 11 at 7:48
Yeah but that's a different story.
– Trass3r
Nov 11 at 8:31
Yeah but that's a different story.
– Trass3r
Nov 11 at 8:31
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
Not sure about clang-query
but if clients of your library use existing public headers you can collect declarations by expecting them via libclang
. A simple example of this is given in ShlibVisibilityChecker project (it identifies spurious exports from shared libs).
Thanks for the link. The tool simply gets a list of all symbols in the headers though and compares that to readelf output.
– Trass3r
Nov 11 at 12:06
I guess what I'm looking for is a discriminating attribute such as llvm.org/docs/LangRef.html#linkage-types.
– Trass3r
Nov 11 at 12:18
add a comment |
up vote
0
down vote
You should be able to get this information through an AST MatchFinder. A simple matcher like
namedDecl().bind("named_decl")
will match all NamedDecl
nodes. Then in the callback, you can get the node's Linkage attribute, and process the node accordingly. A callback that printed out which symbols have external linkage might look something like this:
struct LinkagePrinter : public MatchFinder::Callback {
void run(MatchResult const & result) override {
using namespace clang;
NamedDecl const * n_decl =
result.Nodes.getNodeAs<NamedDecl("named_decl");
if(n_decl){
Linkage l = n_decl->getLinkage();
switch(l){
case ExternalLinkage:
std::cout << "symbol " << n_decl->getNameAsString()
<< " has external linkagen";
// ... etc
}
}
return;
}
}; // LinkagePrinter
This is roughly right--I haven't checked that this compiles. Register the matcher and callback with a MatchFinder, load the MatchFinder into a Tool, and you should be in business. There are lots of examples in https://github.com/lanl/CoARCT .
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
Not sure about clang-query
but if clients of your library use existing public headers you can collect declarations by expecting them via libclang
. A simple example of this is given in ShlibVisibilityChecker project (it identifies spurious exports from shared libs).
Thanks for the link. The tool simply gets a list of all symbols in the headers though and compares that to readelf output.
– Trass3r
Nov 11 at 12:06
I guess what I'm looking for is a discriminating attribute such as llvm.org/docs/LangRef.html#linkage-types.
– Trass3r
Nov 11 at 12:18
add a comment |
up vote
0
down vote
Not sure about clang-query
but if clients of your library use existing public headers you can collect declarations by expecting them via libclang
. A simple example of this is given in ShlibVisibilityChecker project (it identifies spurious exports from shared libs).
Thanks for the link. The tool simply gets a list of all symbols in the headers though and compares that to readelf output.
– Trass3r
Nov 11 at 12:06
I guess what I'm looking for is a discriminating attribute such as llvm.org/docs/LangRef.html#linkage-types.
– Trass3r
Nov 11 at 12:18
add a comment |
up vote
0
down vote
up vote
0
down vote
Not sure about clang-query
but if clients of your library use existing public headers you can collect declarations by expecting them via libclang
. A simple example of this is given in ShlibVisibilityChecker project (it identifies spurious exports from shared libs).
Not sure about clang-query
but if clients of your library use existing public headers you can collect declarations by expecting them via libclang
. A simple example of this is given in ShlibVisibilityChecker project (it identifies spurious exports from shared libs).
answered Nov 11 at 10:27
yugr
6,77221340
6,77221340
Thanks for the link. The tool simply gets a list of all symbols in the headers though and compares that to readelf output.
– Trass3r
Nov 11 at 12:06
I guess what I'm looking for is a discriminating attribute such as llvm.org/docs/LangRef.html#linkage-types.
– Trass3r
Nov 11 at 12:18
add a comment |
Thanks for the link. The tool simply gets a list of all symbols in the headers though and compares that to readelf output.
– Trass3r
Nov 11 at 12:06
I guess what I'm looking for is a discriminating attribute such as llvm.org/docs/LangRef.html#linkage-types.
– Trass3r
Nov 11 at 12:18
Thanks for the link. The tool simply gets a list of all symbols in the headers though and compares that to readelf output.
– Trass3r
Nov 11 at 12:06
Thanks for the link. The tool simply gets a list of all symbols in the headers though and compares that to readelf output.
– Trass3r
Nov 11 at 12:06
I guess what I'm looking for is a discriminating attribute such as llvm.org/docs/LangRef.html#linkage-types.
– Trass3r
Nov 11 at 12:18
I guess what I'm looking for is a discriminating attribute such as llvm.org/docs/LangRef.html#linkage-types.
– Trass3r
Nov 11 at 12:18
add a comment |
up vote
0
down vote
You should be able to get this information through an AST MatchFinder. A simple matcher like
namedDecl().bind("named_decl")
will match all NamedDecl
nodes. Then in the callback, you can get the node's Linkage attribute, and process the node accordingly. A callback that printed out which symbols have external linkage might look something like this:
struct LinkagePrinter : public MatchFinder::Callback {
void run(MatchResult const & result) override {
using namespace clang;
NamedDecl const * n_decl =
result.Nodes.getNodeAs<NamedDecl("named_decl");
if(n_decl){
Linkage l = n_decl->getLinkage();
switch(l){
case ExternalLinkage:
std::cout << "symbol " << n_decl->getNameAsString()
<< " has external linkagen";
// ... etc
}
}
return;
}
}; // LinkagePrinter
This is roughly right--I haven't checked that this compiles. Register the matcher and callback with a MatchFinder, load the MatchFinder into a Tool, and you should be in business. There are lots of examples in https://github.com/lanl/CoARCT .
add a comment |
up vote
0
down vote
You should be able to get this information through an AST MatchFinder. A simple matcher like
namedDecl().bind("named_decl")
will match all NamedDecl
nodes. Then in the callback, you can get the node's Linkage attribute, and process the node accordingly. A callback that printed out which symbols have external linkage might look something like this:
struct LinkagePrinter : public MatchFinder::Callback {
void run(MatchResult const & result) override {
using namespace clang;
NamedDecl const * n_decl =
result.Nodes.getNodeAs<NamedDecl("named_decl");
if(n_decl){
Linkage l = n_decl->getLinkage();
switch(l){
case ExternalLinkage:
std::cout << "symbol " << n_decl->getNameAsString()
<< " has external linkagen";
// ... etc
}
}
return;
}
}; // LinkagePrinter
This is roughly right--I haven't checked that this compiles. Register the matcher and callback with a MatchFinder, load the MatchFinder into a Tool, and you should be in business. There are lots of examples in https://github.com/lanl/CoARCT .
add a comment |
up vote
0
down vote
up vote
0
down vote
You should be able to get this information through an AST MatchFinder. A simple matcher like
namedDecl().bind("named_decl")
will match all NamedDecl
nodes. Then in the callback, you can get the node's Linkage attribute, and process the node accordingly. A callback that printed out which symbols have external linkage might look something like this:
struct LinkagePrinter : public MatchFinder::Callback {
void run(MatchResult const & result) override {
using namespace clang;
NamedDecl const * n_decl =
result.Nodes.getNodeAs<NamedDecl("named_decl");
if(n_decl){
Linkage l = n_decl->getLinkage();
switch(l){
case ExternalLinkage:
std::cout << "symbol " << n_decl->getNameAsString()
<< " has external linkagen";
// ... etc
}
}
return;
}
}; // LinkagePrinter
This is roughly right--I haven't checked that this compiles. Register the matcher and callback with a MatchFinder, load the MatchFinder into a Tool, and you should be in business. There are lots of examples in https://github.com/lanl/CoARCT .
You should be able to get this information through an AST MatchFinder. A simple matcher like
namedDecl().bind("named_decl")
will match all NamedDecl
nodes. Then in the callback, you can get the node's Linkage attribute, and process the node accordingly. A callback that printed out which symbols have external linkage might look something like this:
struct LinkagePrinter : public MatchFinder::Callback {
void run(MatchResult const & result) override {
using namespace clang;
NamedDecl const * n_decl =
result.Nodes.getNodeAs<NamedDecl("named_decl");
if(n_decl){
Linkage l = n_decl->getLinkage();
switch(l){
case ExternalLinkage:
std::cout << "symbol " << n_decl->getNameAsString()
<< " has external linkagen";
// ... etc
}
}
return;
}
}; // LinkagePrinter
This is roughly right--I haven't checked that this compiles. Register the matcher and callback with a MatchFinder, load the MatchFinder into a Tool, and you should be in business. There are lots of examples in https://github.com/lanl/CoARCT .
answered Nov 17 at 15:48
Some Who Call Me Tim
75616
75616
add a comment |
add a comment |
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%2f53246543%2fhow-to-find-symbols-that-should-be-exported%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
1
automatically? exports should be properly designed and documented
– VTT
Nov 11 at 7:48
Yeah but that's a different story.
– Trass3r
Nov 11 at 8:31