I’ve been using RTP 6.0 (patches A, B and C) with a custom design using an
ElanSC400. My SC400 target is booted over a network and uses fs-nfs2 to
access files from a host machine. I’m using pdebug over the same network.
At start-up my application reads a modest amount of data from several small
configuration files before starting threads etc. Both the application and
the configuration files are served up from the host. This arrangement has
worked without problems through the several versions of RTP 6.0.
After installing RTP 6.1 on my host machine and rebuilding my target’s boot
image using the RTP 6.1 binaries, the fscanf() calls used to access data in
the configuration files now cause segmentation violations in libc.so.2. If
I relocate the configuration files to a RAM disk on the target, I still get
segmentation violations. The fscanf() calls are all of the form:
I’ve been using RTP 6.0 (patches A, B and C) with a custom design using an
ElanSC400. My SC400 target is booted over a network and uses fs-nfs2 to
access files from a host machine. I’m using pdebug over the same network.
At start-up my application reads a modest amount of data from several small
configuration files before starting threads etc. Both the application and
the configuration files are served up from the host. This arrangement has
worked without problems through the several versions of RTP 6.0.
After installing RTP 6.1 on my host machine and rebuilding my target’s boot
image using the RTP 6.1 binaries, the fscanf() calls used to access data in
the configuration files now cause segmentation violations in libc.so.2. If
I relocate the configuration files to a RAM disk on the target, I still get
segmentation violations. The fscanf() calls are all of the form:
causes a segmentation violation in libc.so.2 on the sscanf() call (i.e. the
fgets() call works).
The same code running on my host machine works fine. Any suggestions for
the resolution of this problem would be appreciated.
The SC400 doesn’t have a floating point unit, so you have to use
floating point emulation. You need to make sure that you are using
the right floating point emulation unit (namely fpemu.so.2) in
your image.
Yes, that was the problem. My build file was calling up fpemu.so. In my
installation (the straight-off-the-CD version) fpemu.so is actually
fpemu.so.1, not a link to the most recent fpemu.so. Using fpemu.so.2 solves
the issue.
Andrew Ward <> andrew@intellidesign.com.au> > wrote:
I’ve been using RTP 6.0 (patches A, B and C) with a custom design using
an
ElanSC400. My SC400 target is booted over a network and uses fs-nfs2 to
access files from a host machine. I’m using pdebug over the same
network.
At start-up my application reads a modest amount of data from several
small
configuration files before starting threads etc. Both the application
and
the configuration files are served up from the host. This arrangement
has
worked without problems through the several versions of RTP 6.0.
After installing RTP 6.1 on my host machine and rebuilding my target’s
boot
image using the RTP 6.1 binaries, the fscanf() calls used to access data
in
the configuration files now cause segmentation violations in libc.so.2.
If
I relocate the configuration files to a RAM disk on the target, I still
get
segmentation violations. The fscanf() calls are all of the form:
causes a segmentation violation in libc.so.2 on the sscanf() call (i.e.
the
fgets() call works).
The same code running on my host machine works fine. Any suggestions
for
the resolution of this problem would be appreciated.
The SC400 doesn’t have a floating point unit, so you have to use
floating point emulation. You need to make sure that you are using
the right floating point emulation unit (namely fpemu.so.2) in
your image.