Aristid Breitkreuz
2006-Apr-30 12:01 UTC
[LLVMdev] Regarding exceptions (new to this list)
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.
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/
Aristid Breitkreuz
2006-May-01 11:26 UTC
[LLVMdev] Regarding exceptions (new to this list)
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