I see that some of the system header-file definitions have the internal
keyword.
For example,
define internal void @__cxx_global_var_init() section
"__TEXT,__StaticInit,regular,pure_instructions" {
entry:
call void @_ZNSt8ios_base4InitC1Ev(%"class.std::ios_base::Init"*
@_ZStL8__ioinit)
%0 = call i32 @__cxa_atexit(void (i8*)* bitcast (void
(%"class.std::ios_base::Init"*)* @_ZNSt8ios_base4InitD1Ev to void
(i8*)*),
i8* getelementptr
inbounds (%"class.std::ios_base::Init"* @_ZStL8__ioinit, i32 0, i32
0), i8*
bitcast (i8** @__dso_handle to i8*))
ret void
}
On Mon, May 23, 2011 at 2:24 PM, John Criswell <criswell at
illinois.edu>wrote:
> On 5/23/11 1:05 PM, George Baah wrote:
>
> Hi,
> I am writing a pass which is supposed to ignore library functions. Is
> there a way to
> distinguish functions declared and defined by a developer from non-local
> functions (library functions)?
> Thanks.
>
>
> There is no reliable way to do this, but there are several heuristics that
> will probably work well in practice.
>
> When analyzing a program, any function that is defined (i.e., has a
> function body) most likely came from the program's source code. The
> exception will be functions declared in system header files or C/C++
library
> header files.
>
> Any function that is declared but not defined (i.e., has no function body)
> is either a function that is defined in another translation unit (i.e.,
> another source file) or defined in a system or language library (e.g.,
> libc). It is, in general, not possible to distinguish between the two
> situations, although if you've linked your entire program into a single
> bitcode file, the only external functions are coming from library
functions.
>
> -- John T.
>
>
> George
>
>
> _______________________________________________
> LLVM Developers mailing listLLVMdev at cs.uiuc.edu
http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110523/c1c72270/attachment.html>