Re: [ECOS] Native file access under eCos synthetic (stat)

[Bart Veer <bartv at redhat dot com>]

(Catching up on some old email)

>>>>> "Dominique" == Dominique Henry de Villeneuve <d.devilleneuve@ri.silicomp.fr> writes:

    Dominique> using the native syscall cyg_hal_sys_prev_stat().

First, which version of eCos are you using? I suspect 1.3.1 since the
current sources do not export any stat-related system calls. The
synthetic target code underwent a major reorganization and clean up a
while back.

    Dominique> Apparently some register(s) get corrupted on return. Pb
    Dominique> also on the gpr[] arguments that are not restored on
    Dominique> return. When called from main(), it works ok.

    Dominique> int status(const char * name)
    Dominique> {  int rc;
    Dominique>    struct stat stabBuf;
 
    Dominique>    rc = cyg_hal_sys_stat(name, &statBuf);
    Dominique>    return rc;
    Dominique> }

    Dominique> Breakpoint 1, status (name=0x103d484 "/usr/include/sys/stat.h") at
    Dominique> stat.c:32
    Dominique> 32	  return rc;
    Dominique> (gdb) x/5i $pc
    Dominique> 0x100004e <my_status+70 at stat.c:32>:	mov    0xfffffff4(%ebp),%eax
    Dominique> 0x1000051 <my_status+73 at stat.c:32>:	mov    %eax,%eax
    Dominique> 0x1000053 <my_status+75 at stat.c:33>:	leave  
    Dominique> 0x1000054 <my_status+76 at stat.c:33>:	ret    
    Dominique> 0x1000055 <my_status+77 at stat.c:33>:	lea    0x0(%esi),%esi
    Dominique> (gdb) stepi
    Dominique> 0x01000051	32	  return rc;
    Dominique> (gdb) stepi
    Dominique> 33	}
    Dominique> (gdb) stepi
    Dominique> 0x01000054 in my_status (name=???) at stat.c:33
    Dominique> 33	}
    Dominique> (gdb) stepi
    Dominique> 0x00000000 in ?? ()

    Dominique> I've added STATCALL2(stat) in syscall-i386-linux-1.0.S.
    Dominique> Same behaviour with cyg_hal_sys_prev_stat() + SYSCALL2(stat).

Some system calls are easier to support than others, and stat is not
one of the easier ones. There have been a number of different
implementation over time, with old ones preserved to ensure binary
compatibility. For example, if I remember correctly there is a stat64
variant where the st_size field is 64 bits rather than 32. Then there
are oldstat and newstat, where the st_uid and st_gid fields may be
either 16 bit or 32 bits. Hence you need to be very careful about
the exact data structure layout. I suspect that the best approach will
be to assume the most recent version, i.e. stat64, although newstat()
should be fine as well.

The gdb output you supply mentions /usr/include/sys/stat.h. Typically
#include'ing Linux headers directly in the synthetic target code or
applications is a bad idea. Those headers may make assumptions about
certain #define's being set up correctly to determine data type sizes,
endianness, etc. There may also be conflicts between Linux and eCos
headers.

Instead the correct thing to do is to figure out the actual data
structure that the kernel will return, e.g. by looking at the Linux
header <bits/stat.h>, and define a cyg_hal_sys_stat structure in
hal/synth/arch/current/include/hal_io.h, alongside the definitions of
cyg_hal_sys_timeval etc. This also helps to avoid confusion between
conflicting definitions of the Linux system call and the eCos
structure provided by the isoinfra package's headers. If the data
structure is not defined correctly then memory corruption is likely to
occur within the application.

Next, how should the Linux system call be performed? This information
can be obtained from two separate sources. The first is the Linux
sources: an rgrep for sys_stat would give you fs/stat.c as a good
place to look. The second place is the glibc sources, obtainable by
e.g. installing the relevant SRPM, because glibc is where the system
calls are normally made.

I suspect that a SYSCALL2(stat64) will give you a functional
cyg_hal_sys_stat64(). The existing STATCALL2() macro appears to be an
attempt to have a function cyg_hal_sys_stat() which will end up doing
an oldstat system call, and that macro should probably be eliminated.

Bart