I have this issue resolved. I want to thank Chris, Jiri, and Jim
(contacted me off-list) for their replies. The resources that you all
pointed me to helped me resolve this. For the benefit of the rest of
the list, here is the deal....
My setup is exactly per Chris's email below. Specifically, my kernel
code is built using the EABI compiler, my root fs is OABI, my userland
code (including shared library support) is built with OABI, and the
kernel (the stock 2.6.21-ts) has CONFIG_OABI_COMPAT=y in the .config.
The link that Chris sent: http://wiki.debian.org/ArmEabiPort has a
section, "Struct packing and alignment", that details the differences
in struct packing and alignment between OABI and EABI. Essentially the
OABI code required a minimum struct size and alignment on 4-byte
boundaries whereas the EABI has no minimum and alignment is determined
by the field types in the struct. So, originally, I had a structure
like this in my kernel driver:
struct fs_ruby412_state
{
uint8_t configuration_register_value;
uint8_t mode_a;
uint8_t mode_b;
uint8_t mode_c;
uint8_t direction_a;
uint8_t direction_b;
uint8_t direction_c_lo;
uint8_t direction_c_hi;
uint8_t port_a;
uint8_t port_b;
uint8_t port_c;
};
which if you count it, would be 11 bytes. sizeof(fs_ruby412_state)
returned 11 with the EABI compiler and returned 12 with the OABI
compiler. Recall, this structure was being passed between user space
and kernel space as an arg to an ioctl. This mismatch in structure
size is consistent with the explanation above from
http://wiki.debian.org/ArmEabiPort
. To fix the issue, I basically performed a "hack". I changed my
struct to:
struct fs_ruby412_state
{
uint8_t configuration_register_value;
uint8_t mode_a;
uint8_t mode_b;
uint8_t mode_c;
uint8_t direction_a;
uint8_t direction_b;
uint8_t direction_c_lo;
uint8_t direction_c_hi;
uint8_t port_a;
uint8_t port_b;
uint8_t port_c;
uint8_t __spare;
};
The new field `__spare' added a 12'th byte to the struct which keeps
it aligned on 4-byte boundaries and the size is consistent across
struct-packing-and-alignment semantics between the EABI and OABI.
After testing this code, it all works out fine.
So, my take-away is this... when building EABI kernel code that must
share structures with OABI userland code, make sure all structs are at
least 4 bytes and are aligned on 4-byte boundaries.
Hopefully this information will help someone in the future who will
certainly come up against this pathology when writing their own code.
Again, thanks for the help and pointers to the resources I needed to
solve this issue.
Tom.
On Mar 13, 2009, at 6:30 AM, Christian Gagneraud wrote:
> Tom Panzarella wrote:
>> I have written a kernel driver for a particular piece of hardware (a
>> pc104 board that I am connecting to the TS7800) that we are using.
>> The
>> driver code has been compiled with the GNU EABI compiler as this was
>> the compiler that was used to build the stock 2.6.21-ts kernel which
>> I'm using on my 7800. The driver works great and when tested with a
>> static user-land binary compiled with the EABI compiler, I can
>> exercise all the exposed functions to my hardware (via `ioctl').
>
> Hi Tom,
>
> What you need to do is:
> - use EABI toolchain to build kernel and module
> - activate the OABI compatibility in the kernel (menu kernel features,
> option "Allow old ABI to run with this kernel")
> - use an OABI root fs
> - build all your shared library and programs with the old ABI
> toolchain
>
> You can get more information here:
> ftp://ftp.embeddedarm.com/ts-arm-sbc/ts-7800-linux/cross-toolchains/README.EABIvsOABI
> and
> http://wiki.debian.org/ArmEabiPort
>
> Chris.
>
>>
>> Now, I need to write a user-land application that uses this driver
>> but
>> also needs to link to shared object files (.so libraries). My
>> understanding (verified through empirical testing) is that the EABI
>> compiler can only create static binaries, so I am using the OABI
>> compiler to build my user-land application. The problem I am
>> experiencing is that when I call into my driver from the user land
>> code that is compiled with the OABI compiler my driver is returning
>> an
>> error to the ioctl system call because the passed in command argument
>> is invalid, only for ioctl's that take an argument. The arguments to
>> the ioctl calls for my driver are pointers to structures that get
>> filled in by the driver code. Part of the encoding of an ioctl
>> command
>> takes into account the size of this buffer (you can verify this by
>> looking at linux/ioctl.h which ultimately points you to asm/ioctl.h).
>> Assuming my structure that I am passing by pointer to ioctl is called
>> `foo', it turns out that calling sizeof(foo) for the EABI compiler
>> returns 11 bytes (which is correct) but for the OABI compiler
>> sizeof(foo) returns 12 bytes.
>>
>> This `sizeof' discrepancy completely explains why my driver will not
>> accept the ioctl calls from the OABI compiled user-land code. But
>> now
>> I am stuck. Does anyone have any advice on what I can do here? My
>> kernel driver needs to be built with the EABI compiler as that is how
>> the kernel was built. My user-land code needs to link to shared
>> object
>> files which forces me into using the OABI compiler. But the OABI and
>> EABI compilers are inconsistent/incompatible with respect to (at
>> least) the `sizeof' on my struct. Is there a version of the EABI
>> compiler that can create dynamically linked binaries? As this would
>> be
>> my preferred choice because I have a little more flexibility in user-
>> land than I do in the kernel and for this production application I
>> would rather stick with the stock/supported TS kernel on the 7800.
>> Any
>> thoughts?
>>
>> Thanks in advance,
>> Tom.
>>
>> PS- Ronald, I am copying you as Grant, one of your tech support
>> engineers, mentioned that you would be best to help me with this but
>> that you were not available by phone today. Any help you can provide
>> via email is greatly appreciated.
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|