how@milhow1.UU.NET (Mike Howard) (01/06/90)
This program (on my machine) when compiled 286 Large model creates a
variable which cannot be correctly updated.
The conditions are:
- SCO Xenix 386, 2.3.2 with 2.3.0 development system with Beta
version of SLS #LNG085 installed.
- 286 code. Large model.
- a 16 bit integer at an address ending in 0xc at the End of the data
segment.
- On my machines (Mylex mother boards - both MQ 386 and AT 386), the
value of the variable (__argc in this case) is returned as -1, (which
I interepret as a read error).
Dumps of relavant tables:
hdr -S tst yields:
Segment table:
type attr seg filpos psize vsize rbase align noff
text M P 003f 0001a0 000bb4 000bb4 000000 00 0000
data M B 0047 000d54 000488 0004b0 000000 00 0000
>data M B 004f 0011dc 000000 00a64e 000000 00 0000<<<<<
rel 0002 0000 0011e0 000164 000000 000000 00 0000
syms 0002 0000 001344 000418 000000 000000 00 0000
syms 0003 0000 00175c 000467 000000 000000 00 0000
syms 0004 0000 001bc3 00004b 000000 000000 00 0000
syms 0005 0000 001c0e 0000a9 000000 000000 00 0000
syms 0006 0000 001cb7 000030 000000 000000 00 0000
syms xseg 0000 001ce7 000734 000000 000000 00 0000
nm -n tst | tail -1 yeilds:
004f:0000a64c B ___argc
Note that __argc is the last 16 bit address in segment 004f, which
ends 1/2 way through a 32 bit word.
Please try on various other machines and let me know what gives.
Mike Howard
milhow1!how@uunet.uu.net or how@milhow1.uunet.uu.net
------------------------cut here for shar----------------------
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of archive 1 (of 1)."
# Contents: Makefile tst.c
# Wrapped by mike@milhow2 on Fri Jan 5 13:46:56 1990
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'Makefile' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'Makefile'\"
else
echo shar: Extracting \"'Makefile'\" \(66 characters\)
sed "s/^X//" >'Makefile' <<'END_OF_FILE'
XCFLAGS = -g -Ml2 -pack
X
Xtst : tst.c
X $(CC) $(CFLAGS) tst.c -o tst
END_OF_FILE
if test 66 -ne `wc -c <'Makefile'`; then
echo shar: \"'Makefile'\" unpacked with wrong size!
fi
# end of 'Makefile'
fi
if test -f 'tst.c' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'tst.c'\"
else
echo shar: Extracting \"'tst.c'\" \(393 characters\)
sed "s/^X//" >'tst.c' <<'END_OF_FILE'
Xextern int __argc;
Xchar *s1 = "this is a string";
Xchar *s2 = "this is a string";
Xchar *s3 = "this is a string";
Xchar *s4 = "this is a string";
Xchar *s5 = "this is a string";
X
Xint v1;
Xint v2;
Xint v3;
Xint v4;
Xint v5;
Xint v6;
Xint v7;
Xint v8;
Xint barfa[20000];
X
Xmain(argc, argv)
Xint argc;
Xchar **argv;
X{
X v1 = 301;
X v2 = 302;
X v3 = 303;
X v4 = 304;
X v5 = 305;
X v6 = 306;
X v7 = 307;
X __argc = v7;
X}
END_OF_FILE
if test 393 -ne `wc -c <'tst.c'`; then
echo shar: \"'tst.c'\" unpacked with wrong size!
fi
# end of 'tst.c'
fi
echo shar: End of archive 1 \(of 1\).
cp /dev/null ark1isdone
MISSING=""
for I in 1 ; do
if test ! -f ark${I}isdone ; then
MISSING="${MISSING} ${I}"
fi
done
if test "${MISSING}" = "" ; then
echo You have the archive.
rm -f ark[1-9]isdone
else
echo You still need to unpack the following archives:
echo " " ${MISSING}
fi
## End of shell archive.
exit 0
--------------------------end of shar---------------------------
--
Mike Howard
uunet!milhow1!how or milhow1!how@uunet.uu.nettanner@cdis-1.UUCP (Dr. T. Andrews) (01/11/90)
When you say that the variable "can't be accessed correctly", you
mean that it can not be displayed correctly by adb. You can work
around the problem by asking adb for a long-word display starting
two bytes before __argc and ignoring the low-order part of the
result.
Your program DOES correctly access the data. It is hard to verify
this with "adb" due to the bug. Problem appears to be that ptrace(2)
allows unaligned access -- and "adb" is simply hoping that there will
be sufficient bytes after the required ones that ptrace(2) won't fail.
Of course, as you have discovered, this is not always true.
This is a known bug in "adb"; my original report of it (with
a small demo) is dated 01-Jul-88 under the name "pfc217.c".
You don't need "large" model or the funny external if you just
sbrk() a block of memory.
--
{attctc gatech!uflorida}!ki4pv!cdis-1!tanner {bpa uunet}!cdin-1!cdis-1!tanner