[PATCH] D13244: [ELF2] - implemented --allow-shlib-undefined/--no-allow-shlib-undefined
George Rimar via llvm-commits
llvm-commits at lists.llvm.org
Tue Sep 29 09:11:29 PDT 2015
grimar added inline comments.
================
Comment at: ELF/Config.h:28
@@ -27,2 +27,3 @@
bool NoInhibitExec = false;
+ bool AllowShlibUndefines = false;
};
----------------
denis-protivensky wrote:
> denis-protivensky wrote:
> > `AllowShlibUndefined`
> As I can read from the description provided, this flag has different meanings depending on whether executable or DSO is being linked. If so, it's initial value is neither `false` nor `true`, because it depends on other flags. Hence you should use `Optional` for such a value.
Honestly I dont see advantage of using it here. In continue of that logic - all flags depends on command line arguments :)
We are going to set AllowShlibUndefined flag once at start and only read it later. Optional seems to be too heavy solution for this.
So I would like to hear more opinions about change to Optional here.
================
Comment at: ELF/Driver.cpp:102
@@ -99,1 +101,3 @@
+ if (auto *arg = Args.getLastArg(OPT_allow_shlib_undefined,
+ OPT_no_allow_shlib_undefined)) {
----------------
denis-protivensky wrote:
> Better to have two checks of the form:
>
> ```auto *Arg = Args.getLastArg(OPT_allow_shlib_undefined);
> if (Arg || Config->Shared)
> Config->AllowShlibUndefines = true;```
>
> The same is for the contrary option. And remove the code above in `OPT_shared` check.
> Also, watch local variables to start from the capital letter.
What if both flags --allow_shlib_undefined and --no-allow_shlib_undefined be declared at the same time ? My solution will choose the latest in command line I think. Your one will choose one depending of what condition is latest in code.
Not sure what is better and if we should report an error in this case.
================
Comment at: ELF/Options.td:44
@@ +43,3 @@
+ HelpText<"Do not allow undefined symbols from dynamic"
+ " library when creating executables">;
+
----------------
denis-protivensky wrote:
> Why executables? It affects DSOs as well.
Will be fixed.
================
Comment at: ELF/Writer.cpp:298
@@ -284,9 +297,3 @@
- std::string Message = "undefined symbol: " + Sym.getName().str();
- if (SymFile)
- Message += " in " + SymFile->getName().str();
- if (Config->NoInhibitExec)
- warning(Message);
- else
- error(Message);
+ undefError(Sym.getName(), SymFile ? SymFile->getName() : "");
}
----------------
denis-protivensky wrote:
> Don't you need to check that this symbol is from DSO, not from object file, for example?
Not here.
All checks are performed in single undefError function:
void undefError(const Twine &Symbol, const Twine &SymFile)
DSOs calls it directly in SharedFile<ELFT>::parse()
================
Comment at: ELF/Writer.h:25
@@ -20,1 +24,3 @@
+void undefError(const llvm::Twine &Symbol, const llvm::Twine &SymFile);
+
----------------
denis-protivensky wrote:
> Use `StringRef` to pass string arguments.
Could you please explain why ? It looks like Twine arguments used much more often in llvm code.
================
Comment at: test/elf2/allow-shlib-undefined.s:13
@@ +12,3 @@
+# --allow-shlib-undefined but does not link with --no-allow-shlib-undefined
+# RUN: lld -shared --allow-shlib-undefined -flavor gnu2 %t -o %t.so
+# RUN: not lld -shared --no-allow-shlib-undefined -flavor gnu2 %t -o %t.so
----------------
denis-protivensky wrote:
> Didn't check linking of DSO without --[no]-allow-shlib-undefined flags.
Actually I did. The second line:
# RUN: lld -shared -flavor gnu2 %t -o %t.so
http://reviews.llvm.org/D13244
More information about the llvm-commits
mailing list