linux-kernel - Re: scripts/mod/file2alias.c cross compile problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 2 Aug 2007 20:09:03 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	Andreas Schwab <schwab@...e.de>, trenn@...e.de,
	Adrian Bunk <bunk@...sta.de>, Jan Dittmer <jdi@....org>,
	Len Brown <lenb@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-ia64@...r.kernel.org
Subject: Re: scripts/mod/file2alias.c cross compile problem

On Thu, Aug 02, 2007 at 10:40:14AM -0700, Luck, Tony wrote:
> >>>  struct acpi_device_id {
> >>>  	__u8 id[ACPI_ID_LEN];
> >>> +	__u8 dummy[FILLUP_LEN];
> >>>  	kernel_ulong_t driver_data;
> >>>  };
> >>
> >> What's so special about this structure that we get an error?
> >
> > It's special because it's a device_id structure, and those structures
> > must come out identical using either the host or the target compiler.
> 
> That didn't help me understand.  Are device_id structures visible
> in some user-level API?  If so, then I can see why they'd need to
> be the same (but then I'd be confused why this structure uses a
> "kernel_ulong_t" type).

I second this. For anything visible in userspace from
include/* we require usage of the kernel specific
__u8, __u16, __u32, __u64 typedefs but for device_id we accept
kernel_ulong_t which result in the following crap in
file2alias.c:

/* We use the ELF typedefs for kernel_ulong_t but bite the bullet and
 * use either stdint.h or inttypes.h for the rest. */
#if KERNEL_ELFCLASS == ELFCLASS32
typedef Elf32_Addr      kernel_ulong_t;
#define BITS_PER_LONG 32
#else
typedef Elf64_Addr      kernel_ulong_t;
#define BITS_PER_LONG 64
#endif

And we ought to have __u64 available.
See for example types.h from asm-i386:
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#endif

	Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/