llvm dev - May 2008 - [LLVMdev] malloc, magic, and embedded compilation

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.

Does the LLVM C front-end support the "init" attribute for C functions
(which has similar effect)?

shap

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

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?
> 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.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/