Regarding exceptions (new to this list)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Regarding exceptions (new to this list)

Aristid Breitkreuz
Hello,

I am, as said in the subject, new to this list. I have not actually used
LLVM, I tried with an older version but failed. Recently I noticed that
1.7 came out and looked at the release notes. And there was something
that stroke me: llvm-g++ adheres to the IA64 ABI but _not for
exceptions_. I was not able to find information why this is so and why
it is necessary, so I hope you don't mind me asking here. Why? It would
make me a whole lot more interested in LLVM.

I have another question: You said (I read in the archive) all your
libraries are static because of start-up time becoming too high. Have
you thought about using -fvisibility=hidden +
__attribute__((visibility(default))) (GCC 4.0 had this wonderful change
making C++ a better language to use)? Or is this currently impossible
with the LLVM infrastructure? Just curious.

Thank you and cheers (as they say),
Aristid

PS: May LLVM have a bright future.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Regarding exceptions (new to this list)

Chris Lattner
On Sun, 30 Apr 2006, Aristid Breitkreuz wrote:
> I am, as said in the subject, new to this list. I have not actually used
> LLVM, I tried with an older version but failed. Recently I noticed that
> 1.7 came out and looked at the release notes. And there was something
> that stroke me: llvm-g++ adheres to the IA64 ABI but _not for
> exceptions_. I was not able to find information why this is so and why
> it is necessary, so I hope you don't mind me asking here. Why? It would
> make me a whole lot more interested in LLVM.

Primarily because it hasn't been implemented in the native code generators
yet.  I hope to get to this in the next month or two.

> I have another question: You said (I read in the archive) all your
> libraries are static because of start-up time becoming too high. Have
> you thought about using -fvisibility=hidden +
> __attribute__((visibility(default))) (GCC 4.0 had this wonderful change
> making C++ a better language to use)? Or is this currently impossible
> with the LLVM infrastructure? Just curious.

Noone has looked into it.  If it were a relatively unobtrusive change to
the LLVM codebase, we would welcome it.  On the other hand, GCC has a
number of significant bugs that impact us: for example LLVM has many
classes declared in anonymous namespaces.  GCC does not give the methods
internal linkage, it just "mangles" them.  This is bad for static
and dynamic link times, but can only really be resolved in the GCC C++
front-end.

-Chris

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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Regarding exceptions (new to this list)

Aristid Breitkreuz
Am Sonntag, den 30.04.2006, 22:24 -0500 schrieb Chris Lattner:

> On Sun, 30 Apr 2006, Aristid Breitkreuz wrote:
> > I am, as said in the subject, new to this list. I have not actually used
> > LLVM, I tried with an older version but failed. Recently I noticed that
> > 1.7 came out and looked at the release notes. And there was something
> > that stroke me: llvm-g++ adheres to the IA64 ABI but _not for
> > exceptions_. I was not able to find information why this is so and why
> > it is necessary, so I hope you don't mind me asking here. Why? It would
> > make me a whole lot more interested in LLVM.
>
> Primarily because it hasn't been implemented in the native code generators
> yet.  I hope to get to this in the next month or two.

Cool. I'm relieved it's not primarily because of "considerations" :).

>
> > I have another question: You said (I read in the archive) all your
> > libraries are static because of start-up time becoming too high. Have
> > you thought about using -fvisibility=hidden +
> > __attribute__((visibility(default))) (GCC 4.0 had this wonderful change
> > making C++ a better language to use)? Or is this currently impossible
> > with the LLVM infrastructure? Just curious.
>
> Noone has looked into it.  If it were a relatively unobtrusive change to
> the LLVM codebase, we would welcome it.  On the other hand, GCC has a
> number of significant bugs that impact us: for example LLVM has many
> classes declared in anonymous namespaces.  GCC does not give the methods
> internal linkage, it just "mangles" them.  This is bad for static
> and dynamic link times, but can only really be resolved in the GCC C++
> front-end.

The -fvisibility=hidden fixes the very problem for dynamic linktimes at
least. Still, it's certainly a partial solution only. I know that
supporting -fvisibility=hidden requires intrusive changes in library
code but for the implementation, I plain don't know. I'm just a curious
developer... I do know that using -fvisibility=hidden is worth it, let's
take a look at an example from my current project which uses this flag
(Linux x86-64, GCC 4.0.3):

libevents.so 216KB (unstripped)

readelf -s says:
Symbol table '.dynsym' contains 269 entries
Symbol table '.symtab' contains 702 entries

=> 156K events/libevents.so (stripped)
(the stripped version has no .symtab any more, the .dynsym is left in,
of course)

For another library, the .dynsym/.symtab ratio is 397/2032 and it's
592KB unstripped and 400KB stripped.

Hope to have got you interested.

>
> -Chris
>

Aristid

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev