[uml-devel] Using compiler.h from uml userspace code (was: Re: uml build error)

[uml-devel] Using compiler.h from uml userspace code (was: Re: uml build error)

[Blaisorblade]

On Wednesday 18 January 2006 12:31, Andrew Morton wrote:
> Blaisorblade <blaisorblade@yahoo.it> wrote:
> > On Wednesday 18 January 2006 09:22, Andrew Morton wrote:
> > > arch/um/os-Linux/umid.c:319: warning: `__uml_help_set_uml_dir' defined
> > > but not used arch/um/os-Linux/umid.c:319: warning:
> > > `__uml_setup_set_uml_dir' defined but not used
> > > arch/um/os-Linux/umid.c:335: warning:
> > > `__uml_exitcall_remove_umid_dir' defined but not used
> >
> > I never see those things (gcc 3.4), there should be a attribute((used))
> > for them, however it's replicated from compiler.h, as it can't be
> > included.

> gcc-3.2.1

Yep, it wants attribute((unused)) instead of all other ones. Damn right.

Possible solutions below - akpm doesn't need to read this. Sam, instead, 
please do read and give an opinion.

Found it: we're using __attribute_used__ from /usr/include/sys/cdefs.h rather 
than from compiler.h, because we can't include that... and <sys/cdefs.h> is 
buggy for this (see below).

But I've found a way to reuse compiler.h! Sam, could this go in?

Index: linux-2.6.git/include/linux/compiler.h
===================================================================
--- linux-2.6.git.orig/include/linux/compiler.h
+++ linux-2.6.git/include/linux/compiler.h
@@ -39,9 +39,9 @@ extern void __chk_io_ptr(void __iomem *)
 #if __GNUC__ > 4
 #error no compiler-gcc.h file for this gcc version
 #elif __GNUC__ == 4
-# include <linux/compiler-gcc4.h>
+# include "compiler-gcc4.h"
 #elif __GNUC__ == 3
-# include <linux/compiler-gcc3.h>
+# include "compiler-gcc3.h"
 #else
 # error Sorry, your compiler is too old/not recognized.
 #endif
@@ -50,7 +50,7 @@ extern void __chk_io_ptr(void __iomem *)
  * coming from above header files here
  */
 #ifdef __INTEL_COMPILER
-# include <linux/compiler-intel.h>
+# include "compiler-intel.h"
 #endif

 /*


With that in, just symlinking include/linux/compiler-*.h into arch/um/include 
would work well!

We prefer to avoid them included as <linux/compiler-*.h> because it could 
conflict with host headers, unless it's possible to have our headers searched 
before host ones.

==== <sys/cdefs.h>
I discovered that /usr/include/sys/cdefs.h has this define (which is likely 
the used definition!):

/* At some point during the gcc 3.1 development the `used' attribute
   for functions was introduced.  We don't want to use it unconditionally
   (although this would be possible) since it generates warnings.  */
#if __GNUC_PREREQ (3,1)
# define __attribute_used__ __attribute__ ((__used__))
# define __attribute_noinline__ __attribute__ ((__noinline__))
#else
# define __attribute_used__ __attribute__ ((__unused__))
# define __attribute_noinline__ /* Ignore */
#endif

while include/linux/compiler-gcc3.h tests for different minor (it requires 
>=3.3).
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Using compiler.h from uml userspace code (was: Re: uml build error)

[Sam Ravnborg]

On Wed, Jan 18, 2006 at 01:47:26PM +0100, Blaisorblade wrote:
> Possible solutions below - akpm doesn't need to read this. Sam, instead, 
> please do read and give an opinion.
> 
> Found it: we're using __attribute_used__ from /usr/include/sys/cdefs.h rather 
> than from compiler.h, because we can't include that... and <sys/cdefs.h> is 
> buggy for this (see below).
> 
> But I've found a way to reuse compiler.h! Sam, could this go in?
> 
> Index: linux-2.6.git/include/linux/compiler.h
> ===================================================================
> --- linux-2.6.git.orig/include/linux/compiler.h
> +++ linux-2.6.git/include/linux/compiler.h
> @@ -39,9 +39,9 @@ extern void __chk_io_ptr(void __iomem *)
>  #if __GNUC__ > 4
>  #error no compiler-gcc.h file for this gcc version
>  #elif __GNUC__ == 4
> -# include <linux/compiler-gcc4.h>
> +# include "compiler-gcc4.h"
>  #elif __GNUC__ == 3
> -# include <linux/compiler-gcc3.h>
> +# include "compiler-gcc3.h"
>  #else
>  # error Sorry, your compiler is too old/not recognized.
>  #endif
> @@ -50,7 +50,7 @@ extern void __chk_io_ptr(void __iomem *)
>   * coming from above header files here
>   */
>  #ifdef __INTEL_COMPILER
> -# include <linux/compiler-intel.h>
> +# include "compiler-intel.h"
>  #endif
> 
>  /*
First off. When I see #include 2foo.h" then this tell me that foo is
found in the same dir as the .c file we are compiling.
gcc though has a much more weak interpretation of the differences
between include <foo.h> and #include "foo.h".

The -I- flag to correct this stupidity is scheduled for removal and when
I asked on the gcc list no-one bothered to answer so I assume this is
all done now in 4.x.
-I- had to purposes, but I cannot recall the other one right now.

From a technical viewpoint nothing is wrong - the only thing being that
human mortals may be confused when suddenly file are included using a
different style than usual.

> With that in, just symlinking include/linux/compiler-*.h into arch/um/include 
> would work well!
> 
> We prefer to avoid them included as <linux/compiler-*.h> because it could 
> conflict with host headers, unless it's possible to have our headers searched 
> before host ones.
Thats perfectly doable if we talk kbuild.
You can just assing to NOSTDINC_FLAGS the directories to search first.

In general I wish all symlinks in the build to hell.
In many cases they are just repairing a badly thought directory
structure include/asm being the worst evil of all.
klibc does the same with no symlinks.

They are indeed needed sometimes - Al Viro poitned out a few cases for
UML where they were the best solution, but do not let it be the hammer
to repair everything.

	Sam


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Using compiler.h from uml userspace code (was: Re: uml build error)

[Blaisorblade]

On Wednesday 18 January 2006 22:35, Sam Ravnborg wrote:
> On Wed, Jan 18, 2006 at 01:47:26PM +0100, Blaisorblade wrote:
> > Possible solutions below - akpm doesn't need to read this. Sam, instead,
> > please do read and give an opinion.

> First off. When I see #include 2foo.h" then this tell me that foo is
> found in the same dir as the .c file we are compiling.

Oops... with that "foo.h" I meant the same folder as compiler.h... I'm correct 
or not, with gcc?

> gcc though has a much more weak interpretation of the differences
> between include <foo.h> and #include "foo.h".

> The -I- flag to correct this stupidity is scheduled for removal and when
> I asked on the gcc list no-one bothered to answer so I assume this is
> all done now in 4.x.
> -I- had to purposes, but I cannot recall the other one right now.

1) Stop searching in "."
2) End listing of include search dirs to use only with "" quotes.

(From info gcc -> searching -I-, at least with 3.4).

> From a technical viewpoint nothing is wrong - the only thing being that
> human mortals may be confused when suddenly file are included using a
> different style than usual.

> > With that in, just symlinking include/linux/compiler-*.h into
> > arch/um/include would work well!

> > We prefer to avoid them included as <linux/compiler-*.h> because it could
> > conflict with host headers, unless it's possible to have our headers
> > searched before host ones.

> Thats perfectly doable if we talk kbuild.
> You can just assing to NOSTDINC_FLAGS the directories to search first.

The problem is that those files are building without NOSTDINC_FLAGS, because 
they are the USER_OBJS. Weren't for this they'd simply include 
<linux/compiler.h> and be done. However, I just saw that user supplied 
include directories are searched before system headers.

So, a simpler solution could be involve symlinking just a directory, where to 
put all related files (like linux/byteorder).

> In general I wish all symlinks in the build to hell.
> In many cases they are just repairing a badly thought directory
> structure include/asm being the worst evil of all.
> klibc does the same with no symlinks.

Hmm, how? Btw, I thought that klibc could be very useful for UML (either 
linking to it or taking code to replace glibc one and alter it at will - 
glibc is fairly unreadable for me, hope klibc is clearer).

For instance, since fork() (or actually, clone) + execvp() calls malloc (and 
so kmalloc) from a wrong context, we want to split execvp() into 
search_exec() and execve().

Doing that with glibc code felt horrible...
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel