[LLVMdev] malloc, magic, and embedded compilation

[Jonathan S. Shapiro]

On Wed, 2008-05-14 at 10:20 -0700, Chris Lattner wrote:
> On Wed, 14 May 2008, Jonathan S. Shapiro wrote:
> > On Wed, 2008-05-14 at 16:15 +0200, Duncan Sands wrote:
> >> I don't think the logic is based on "main", but on whether functions
> >> are marked "internal" or not.  That said, GlobalOpt.cpp seems to reason
> >> based on the name "main" (most likely bogus, because of constructors/
> >> destructors running before main).
> >
> > Umm. That sounds like a test case that really wants to get written.
> 
> huh?

Duncan asserted that there is a behavior in GlobalOpt.cpp that relies on
main being the single entry point. If he is mistaken, great. If he is
correct, a regression test case for this seems like a useful thing to
build. I'm not saying that somebody else should do it. In fact, it seems
like a fine way to start getting my hands dirty.

> > Does the LLVM C front-end support the "init" attribute for C functions
> > (which has similar effect)?
> 
> Yes, we fully support it.  I'm not sure why you think there is a bug here. 
> As several people have told you, LLVM is doing the right thing, and if you 
> want to build a kernel or something without libc, use -ffree-standing. 
> There are serveral existence cases of kernels built with LLVM.

I did not say that I thought there was a bug here. That was Duncan. I
*asked* if LLVM assumes that main is the only entry point because of the
earlier malloc() discussion, which seemed to rely on knowing the control
flow from all possible entry points.

Since you seem to find my participation in the list excessive, and since
I would actually like to comply with the intended list policy, perhaps
you would be good enough to publicly answer the following question:

  Are questions that are intended to help users develop an understanding
  of the LLVM internals and assumptions considered "within bounds" on
  this list or not?

If not, I will be happy to stop asking them.

shap