On 4/11/15 05:51, Peter Maydell wrote: > On 10 April 2015 at 21:41, Chen Gang <xili_gchen_5...@hotmail.com> wrote: >> On 4/10/15 05:31, Peter Maydell wrote: >>> On 27 March 2015 at 10:49, Chen Gang <xili_gchen_5...@hotmail.com> wrote: >>>> +typedef struct target_sigaltstack { >>>> + abi_ulong ss_sp; >>>> + abi_ulong ss_size; >>>> + abi_long ss_flags; >>>> +} target_stack_t; >>> >>> Where does this come from? It doesn't match the kernel's >>> generic-headers struct layout. >>> >> >> Oh, sorry, originally, I guess, I only copied it from microblaze, did >> not check kernel. > > These structures are all user-guest-facing ABI, so they must > match the kernel's structures for your target architecture. > >> I shall use generic-headers which tilegx will use (the result will like >> alpha has done): >> >> typedef struct target_sigaltstack { >> abi_ulong ss_sp; >> int32_t ss_flags; >> int32_t dummy; >> abi_ulong ss_size; >> } target_stack_t; > > This doesn't match the kernel either. > > http://lxr.free-electrons.com/source/include/uapi/asm-generic/signal.h#L111 > > You have a pointer, an int and a size_t, so you want > abi_ulong ss_sp; > abi_int ss_flags; > abi_ulong ss_size; > > like aarch64. >
For me, for tilegx which is always 64-bit, add 'dummy' is more clearer (but need to use abi_int instead of original int32_t). And does it pragma packed ()? As far as I know, it doesn't. >> >> [...] >>>> + >>>> +struct target_ipc_perm { >>>> + abi_int __key; /* Key. */ >>>> + abi_uint uid; /* Owner's user ID. */ >>>> + abi_uint gid; /* Owner's group ID. */ >>>> + abi_uint cuid; /* Creator's user ID. */ >>>> + abi_uint cgid; /* Creator's group ID. */ >>>> + abi_uint mode; /* Read/write permission. */ >>>> + abi_ushort __seq; /* Sequence number. */ >>>> + abi_ushort __pad2; >>>> + abi_ulong __unused1; >>>> + abi_ulong __unused2; >>>> +}; >>> >>> Again, doesn't seem to match kernel? >>> >> >> For me, it matches kernel. mode is abi_uint (__kernel_mode_t is 32-bit). > > I'm looking at > http://lxr.free-electrons.com/source/include/uapi/linux/ipc.h#L9 > which doesn't have that padding and unused fields at the end. > However the ipc structs are pretty confusing so maybe that's > the wrong one -- which one are you looking at? > I check the linux-next tree next-20150401 in include/uapi/linux/ipc.h, the __kernel_mode_t is unsigned int for tile (and also most of 64-bit targets in qemu, mode is 32-bit), please check again. it really has no "__pad2" and "__unused?", but after check all the other targets within qemu, they all have "__pad2" and "__unused?". May qemu itself need them? I am not quite sure, but for me, appending them is OK. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed