Re: Make error in sys_ipc_wrapper
Udo, Thanks.. I tried make clean followed by make... this stopped in the same place NB I'm using the CVS version, downloaded on Saturday or Sunday last, I'm not sure. Bearing in mind my previous problem with tempfile, I am wondering if there is a linux distro issue involved. I'm using SuSE8.0 which has a kernel level of 2.4.18. When looking at UML (IIRC), I remember seeing somewhere that the SuSE kernel is a bit customised. Maybe this is the problem and there are sources missing in my distro that Fiasco/L4 expects. Do I gather that tu-dresden relies on debian? Maybe I should consider installing a debian linux instead, on this machine. TIA David D "Udo A. Steinberg" <us15@os.inf.tu-dresden.de>@os.inf.tu-dresden.de Sent by: l4-hackers-bounces@os.inf.tu-dresden.de 15:05 ZE2 Today To: David Denny <david@yaravi.com> cc: "l4-hackers@os.inf.tu-dresden.de" <l4-hackers@os.inf.tu-dresden.de> Subject: Re: Make error in sys_ipc_wrapper On Wed, 30 Jul 2003 06:30:38 +0100 David Denny (DD) wrote: DD> I attach glpbalconfig.out & last piece of compile log & look forward to finding out what I have overlooked Hi, I've tried your configuration and I can build it just fine here. I'm using the current CVS version. What version are you using? CVS or the Fiasco-1.0 release + patches from our website? Also, have you tried a "make cleanall" and then a "make"? -Udo. -- Gleichgültigkeit ist die mildeste Form der Toleranz. [Karl Jaspers] _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
On Wed, 30 Jul 2003 21:54:19 +0100 daviddenny@chavin.net (DN) wrote: Hi, DN> Udo, Thanks.. I tried make clean followed by make... this stopped in the DN> same place DN> NB I'm using the CVS version, downloaded on Saturday or Sunday last, I'm DN> not sure. This is starting to get interesting... DN> Bearing in mind my previous problem with tempfile, I am wondering if there DN> is a linux distro issue involved. I'm using SuSE8.0 which has a kernel DN> level of 2.4.18. The Linux kernel is completely irrelevant for this particular problem. An old toolchain (compiler, assembler, linker etc.) could be a problem, because Suse 8.0 is a tad old. Can you send the output of: nm thread-ipc.o | c++filt That will hopefully narrow the problem down quite a bit. DN> When looking at UML (IIRC), I remember seeing somewhere that the SuSE DN> kernel is a bit customised. Maybe this is the problem and there are DN> sources missing in my distro that Fiasco/L4 expects. No, Fiasco doesn't use any source files other than its own. DN> Do I gather that tu-dresden relies on debian? Maybe I should consider DN> installing a debian linux instead, on this machine. I wouldn't switch distributions because of that. While it's true that OS development at TUD is done on machines that run Debian, I successfully use Slackware at home and it would be a real shame if it didn't run on Suse for some stupid reason :) [We at least want to know why] -Udo. -- Kein Mann ist ein Versager, bevor ihn seine Frau dafür hält.
daviddenny@chavin.net wrote:
Bearing in mind my previous problem with tempfile, I am wondering if there is a linux distro issue involved. I'm using SuSE8.0 which has a kernel level of 2.4.18.
When looking at UML (IIRC), I remember seeing somewhere that the SuSE kernel is a bit customised. Maybe this is the problem and there are sources missing in my distro that Fiasco/L4 expects.
I was able to reproduce the bug with on SUSE 7.3. For some reason functions that are declared 'inline NOEXPORT' won't get compiled at all. It might be a problem of the gcc 2.95.3 being SUSE-specific but I'm not sure yet. Meanwhile as a quick'n'dirty fix you can switch off 'Generate inline code' (make menuconfig -> 'Kernel Debugging' ) then it will at least compile although you get a slower kernel.
Do I gather that tu-dresden relies on debian? Maybe I should consider installing a debian linux instead, on this machine.
Upgrading SuSE would already help. I had no problems at all compiling Fiasco on a SUSE 8.1 system. Cheers Sarah
Sarah Hoffmann <sh18@os.inf.tu-dresden.de> writes:
I was able to reproduce the bug with on SUSE 7.3. For some reason functions that are declared 'inline NOEXPORT' won't get compiled at all. [...]
Strange... This could also be a problem with `preprocess' or the Perl interpreter it uses. Could you try the following: % cd l4/tool/preprocess % cvs update -d [ Only if you use a copy checked out from our CVS ] % make test Michael -- hohmuth@sax.de, hohmuth@inf.tu-dresden.de http://home.pages.de/~hohmuth/
On Fri, 1 Aug 2003, Michael Hohmuth wrote:
Sarah Hoffmann <sh18@os.inf.tu-dresden.de> writes:
I was able to reproduce the bug with on SUSE 7.3. For some reason functions that are declared 'inline NOEXPORT' won't get compiled at all. [...]
This could also be a problem with `preprocess' or the Perl interpreter it uses. Could you try the following:
Preprocess output is fine. The problem lies in how gcc 2.95.3 handles inlined member functions. Obviously they are automaticly 'inline extern' so if the function can't be inlined there is still no code generated. With the standard gcc 2.95.3 this was not a problem because it always respects the inline directive. SuSEs gcc is a bit more picky and refuses to inline some functions because they are too big. I might find a way to tweak SuSE to produce correct code but I'm afraid we will run again into this problem sooner or later with another distribution. David, I strongly recommend that you install a newer complier preferably gcc 3.2.x. (There are still some open issues with gcc 3.3 in L4 userland.) The kernel without inlined code is not really tested and you soon might run into problems with kernel stack overflows. Cheers Sarah
[Sarah Hoffmann]
On Fri, 1 Aug 2003, Michael Hohmuth wrote:
Sarah Hoffmann <sh18@os.inf.tu-dresden.de> writes:
I was able to reproduce the bug with on SUSE 7.3. For some reason functions that are declared 'inline NOEXPORT' won't get compiled at all. [...]
This could also be a problem with `preprocess' or the Perl interpreter it uses. Could you try the following:
Preprocess output is fine. The problem lies in how gcc 2.95.3 handles inlined member functions. Obviously they are automaticly 'inline extern' so if the function can't be inlined there is still no code generated. With the standard gcc 2.95.3 this was not a problem because it always respects the inline directive. SuSEs gcc is a bit more picky and refuses to inline some functions because they are too big.
Actually, the old gcc version is behaving correctly in this sense. If you specify 'extern inline' the function will *only* be used for inlining, even if you make an explicit address reference to it. Such address references become external references. If the compiler handles such usage the way you "expect it" it is only by accident (the gcc documentation clearly says that it shouldn't work this way), and the corresponding code should be fixed. BTW, it might happen that gcc-3 generates code which does not respect the 'extern inline' directive. It will then generate separate functions located in '.gnu.linkonce.t.*' sections. One can avoid this behaviour by playing around with the '--inline-limit' option, though. eSk
[Sarah Hoffmann]
On Fri, 1 Aug 2003, Michael Hohmuth wrote:
Sarah Hoffmann <sh18@os.inf.tu-dresden.de> writes: Preprocess output is fine. The problem lies in how gcc 2.95.3 handles inlined member functions. Obviously they are automaticly 'inline extern' so if the function can't be inlined there is still no code generated. With the standard gcc 2.95.3 this was not a problem because it always respects the inline directive. SuSEs gcc is a bit more picky and refuses to inline some functions because they are too big.
Actually, the old gcc version is behaving correctly in this sense. If you specify 'extern inline' the function will *only* be used for inlining, even if you make an explicit address reference to it. Such address references become external references. If the compiler handles such usage the way you "expect it" it is only by accident (the gcc documentation clearly says that it shouldn't work this way), and the corresponding code should be fixed.
The functions are marked just 'inline' but _behave_ like they had been declared 'extern inline'. For 'inline' only functions I would expect that the compiler builds functions if it refuses to inline them. Sarah
participants (6)
-
daviddenny＠chavin.net -
Espen Skoglund -
Michael Hohmuth -
Sarah Hoffmann -
Sarah Hoffmann -
Udo A. Steinberg