f



ANNOUNCE: DJGPP 2.05 beta 1

This is announcement of DJGPP 2.05 beta 1

It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
(http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
Unfortunately DJGPP v2.04 was never released and old beta version slowly
became almost unusable together with other newer DJGPP packages.

More information about changes in DJGPP 2.05 beta 1 is available at

     http://www.delorie.com/djgpp/doc/kb/

both in sections about changes in 2.04 and 2.05. The same information is also
available in file info/kb.inf in djdev205.zip

It needs a lot of testing. Please test it if you have time and/or are
interested in any of the above features. Any level of testing would be
appreciated.

The beta is not available via the Zip Picker interface. You can download it
from here:

     ftp://ftp.delorie.com/pub/djgpp/beta/v2

Additionally RPM packages (source and binary packages for i686 and x86_64) are
available from

     ftp://ftp.delorie.com/pub/djgpp/rpms

Please see the README file for instructions on how to install the beta:

     ftp://ftp.delorie.com/pub/djgpp/beta/v2/readme.1st

You can also download DJGPP 2.05 beta 1 packages from DJGPP mirror sites:

     http://www.delorie.com/djgpp/getting.html

Thanks for all who have contributed to development of DJGPP

Andris Pavenis

0
Andris
5/4/2015 8:03:17 PM
comp.os.msdos.djgpp 3308 articles. 2 followers. tigrepotrazosalvaje (34) is leader. Post Follow

105 Replies
1002 Views

Similar Articles

[PageSpeed] 11

On 5/4/15, Andris Pavenis (andris.pavenis@iki.fi)
<djgpp-announce@delorie.com> wrote:
> This is announcement of DJGPP 2.05 beta 1
>
> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
> Unfortunately DJGPP v2.04 was never released and old beta version slowly
> became almost unusable together with other newer DJGPP packages.
>
> More information about changes in DJGPP 2.05 beta 1 is available at
>
>      http://www.delorie.com/djgpp/doc/kb/
>
> both in sections about changes in 2.04 and 2.05. The same information is
> also
> available in file info/kb.inf in djdev205.zip
>
> It needs a lot of testing. Please test it if you have time and/or are
> interested in any of the above features. Any level of testing would be
> appreciated.
>

Looking at the commit log of src/makefile.cfg r1.2, we should add the
following to current makefile.cfg, at least for sake of completeness.

Index: makefile.cfg
===================================================================
RCS file: /cvs/djgpp/djgpp/src/makefile.cfg,v
retrieving revision 1.5
diff -u -r1.5 makefile.cfg
--- makefile.cfg	3 May 2015 12:23:14 -0000	1.5
+++ makefile.cfg	5 May 2015 08:25:14 -0000
@@ -8,6 +8,12 @@
 MTUNE := -mcpu=i586
 IQUOTE := -I. -I-

+ifeq ($(GCC_MAJOR),)
+# very old gcc, e.g. gcc-2.95, fails the above, so we invent a default.
+GCC_MAJOR := 2
+GCC_MINOR := 7
+endif
+
 ifeq ($(filter 2 3,$(GCC_MAJOR)),)
 # we have gcc >= 4.x
 MTUNE := -mtune=i586



> The beta is not available via the Zip Picker interface. You can download it
> from here:
>
>      ftp://ftp.delorie.com/pub/djgpp/beta/v2
>
> Additionally RPM packages (source and binary packages for i686 and x86_64)
> are
> available from
>
>      ftp://ftp.delorie.com/pub/djgpp/rpms
>
> Please see the README file for instructions on how to install the beta:
>
>      ftp://ftp.delorie.com/pub/djgpp/beta/v2/readme.1st
>
> You can also download DJGPP 2.05 beta 1 packages from DJGPP mirror sites:
>
>      http://www.delorie.com/djgpp/getting.html
>
> Thanks for all who have contributed to development of DJGPP
>
> Andris Pavenis
>

--
O.S.
0
Ozkan
5/5/2015 8:32:46 AM
Hi,
thank you for your effort to make final release of djdev 2.05!
Please could you just add log2f macro to INCLUDE/MATH.H that I need for compiling FFMPEG package?
#ifndef log2f
#define log2f(x) (logf(x)/(float)M_LN2)
#endif
I can see that it's placed in INCLUDE/LIBM/MATH.H but this file seems to not be included in my case (or macro not defined) so I added it directly to INCLUDE/MATH.H myself. After this minor fix FFMPEG was compiled without problem and works fine.
0
RayeR
5/6/2015 1:01:01 AM
On 5/4/15, Andris Pavenis (andris.pavenis@iki.fi)
<djgpp-announce@delorie.com> wrote:
> This is announcement of DJGPP 2.05 beta 1
>
> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
> Unfortunately DJGPP v2.04 was never released and old beta version slowly
> became almost unusable together with other newer DJGPP packages.
>
> More information about changes in DJGPP 2.05 beta 1 is available at
>
>      http://www.delorie.com/djgpp/doc/kb/
>
> both in sections about changes in 2.04 and 2.05. The same information is
> also
> available in file info/kb.inf in djdev205.zip
>
> It needs a lot of testing. Please test it if you have time and/or are
> interested in any of the above features. Any level of testing would be
> appreciated.

include/stdbool.h seems to have some confusion in it,
like defining its stuff, (to wrong things), when __cplusplus
is defined for one.  I suggest that  we match it to what gcc
itself provides.

--
O.S.
0
Ozkan
5/6/2015 12:56:10 PM
On 5/4/15, Andris Pavenis (andris.pavenis@iki.fi)
<djgpp-announce@delorie.com> wrote:
> This is announcement of DJGPP 2.05 beta 1
>
> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
> Unfortunately DJGPP v2.04 was never released and old beta version slowly
> became almost unusable together with other newer DJGPP packages.
>
> More information about changes in DJGPP 2.05 beta 1 is available at
>
>      http://www.delorie.com/djgpp/doc/kb/
>
> both in sections about changes in 2.04 and 2.05. The same information is
> also
> available in file info/kb.inf in djdev205.zip
>
> It needs a lot of testing. Please test it if you have time and/or are
> interested in any of the above features. Any level of testing would be
> appreciated.

Andris's r1.14 change to src/makefile.ic (to add gcc's own include
directory to CFLAGS) defeats djgpp's float.h DBL_MIN and DBL_MAX
macros:  with djgpp's folat.h, they are defined to __dj_double_min
and __dj_double_max symbols, however gcc's float.h undefines them
and redefines them as floatiing point constants.  Therefore, with
and without the r1.14 change to src/makefile.inc being in effect,
the binary output of several sources, such as strtod.c, differ.
Not noticed before, or not cared about?

(BTW, why are we defining DBL_MIN/_MAX as __dj_double_min/_max and
not as constants?)
0
Ozkan
5/7/2015 7:41:13 AM
> (BTW, why are we defining DBL_MIN/_MAX as __dj_double_min/_max and
> not as constants?)

This way we get the exact bit pattern we want without worrying if
the compiler will parse a constant correctly.
0
DJ
5/7/2015 5:41:24 PM
--001a113f284e5b23560515944a16
Content-Type: text/plain; charset=UTF-8

On 5/4/15, Andris Pavenis (andris.pavenis@iki.fi)
<djgpp-announce@delorie.com> wrote:
> This is announcement of DJGPP 2.05 beta 1
>
> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
> Unfortunately DJGPP v2.04 was never released and old beta version slowly
> became almost unusable together with other newer DJGPP packages.
>
> More information about changes in DJGPP 2.05 beta 1 is available at
>
>      http://www.delorie.com/djgpp/doc/kb/
>
> both in sections about changes in 2.04 and 2.05. The same information is
> also
> available in file info/kb.inf in djdev205.zip
>
> It needs a lot of testing. Please test it if you have time and/or are
> interested in any of the above features. Any level of testing would be
> appreciated.

Attached are two tiny patches:

- ioctl-va_end.patch:  adds missing va_end to unix ioctl case.

- no-Wno-error.patch:  removes -Wno-error special cases from
ioctl.c and fcntl.c build rules. Warnings seem to have been cured
since ioctl.c r1.8 and fcntl.c r1.10.

--
O.S.

--001a113f284e5b23560515944a16
Content-Type: application/octet-stream; name="ioctl-va_end.patch"
Content-Disposition: attachment; filename="ioctl-va_end.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: file0

SW5kZXg6IHNyYy9saWJjL2NvbXBhdC9pb2N0bC9pb2N0bC5jCj09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6
IC9jdnMvZGpncHAvZGpncHAvc3JjL2xpYmMvY29tcGF0L2lvY3RsL2lvY3RsLmMsdgpyZXRyaWV2
aW5nIHJldmlzaW9uIDEuOQpkaWZmIC11IC1wIC1yMS45IGlvY3RsLmMKLS0tIHNyYy9saWJjL2Nv
bXBhdC9pb2N0bC9pb2N0bC5jCTIgTWF5IDIwMTUgMDc6MzI6MTUgLTAwMDAJMS45CisrKyBzcmMv
bGliYy9jb21wYXQvaW9jdGwvaW9jdGwuYwk4IE1heSAyMDE1IDE2OjAwOjQ3IC0wMDAwCkBAIC0z
NTYsNyArMzU2LDkgQEAgaW50IGlvY3RsKGludCBmZCwgaW50IGNtZCwgLi4uKQogICAgICAgICAg
ICBpbmZsZyxvdXRmbGcsdm9pZGZsZyxzaXplKTsKICAgICB9CiAjZW5kaWYKLSAgICAgcmV0dXJu
IF91bml4X2lvY3RsKGZkLCBjbWQsIGFyZ3MpOworICAgICBydiA9IF91bml4X2lvY3RsKGZkLCBj
bWQsIGFyZ3MpOworICAgICB2YV9lbmQoYXJncyk7CisgICAgIHJldHVybiBydjsKICAgfQogICAv
KiBIYW5kbGUgYSBET1MgcmVxdWVzdCAqLwogICAvKiBleHRyYWN0IGFyZ3VtZW50cyAqLwo=
--001a113f284e5b23560515944a16
Content-Type: application/octet-stream; name="no-Wno-error.patch"
Content-Disposition: attachment; filename="no-Wno-error.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: file2

SW5kZXg6IHNyYy9saWJjL2NvbXBhdC9pb2N0bC9tYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxl
OiAvY3ZzL2RqZ3BwL2RqZ3BwL3NyYy9saWJjL2NvbXBhdC9pb2N0bC9tYWtlZmlsZSx2CnJldHJp
ZXZpbmcgcmV2aXNpb24gMS42CmRpZmYgLXUgLXIxLjYgbWFrZWZpbGUKLS0tIHNyYy9saWJjL2Nv
bXBhdC9pb2N0bC9tYWtlZmlsZQkyIE1heSAyMDE1IDA3OjMyOjE1IC0wMDAwCTEuNgorKysgc3Jj
L2xpYmMvY29tcGF0L2lvY3RsL21ha2VmaWxlCTggTWF5IDIwMTUgMTY6MDQ6NTUgLTAwMDAKQEAg
LTUsNiArNSw0IEBACiAKIFNSQyArPSBpb2N0bC5jCiAKLWlvY3RsLm86CUVYVFJBX0NGTEFHUyA6
PSAtV25vLWVycm9yCi0KIGluY2x1ZGUgJChUT1ApLy4uL21ha2VmaWxlLmluYwpJbmRleDogc3Jj
L2xpYmMvcG9zaXgvZmNudGwvbWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9kamdw
cC9kamdwcC9zcmMvbGliYy9wb3NpeC9mY250bC9tYWtlZmlsZSx2CnJldHJpZXZpbmcgcmV2aXNp
b24gMS41CmRpZmYgLXUgLXIxLjUgbWFrZWZpbGUKLS0tIHNyYy9saWJjL3Bvc2l4L2ZjbnRsL21h
a2VmaWxlCTIgTWF5IDIwMTUgMDc6MzI6MjcgLTAwMDAJMS41CisrKyBzcmMvbGliYy9wb3NpeC9m
Y250bC9tYWtlZmlsZQk4IE1heSAyMDE1IDE2OjA0OjU1IC0wMDAwCkBAIC03LDYgKzcsNCBAQAog
U1JDICs9IGZjbnRsLmMKIFNSQyArPSBvcGVuLmMKIAotZmNudGwubzoJRVhUUkFfQ0ZMQUdTICs9
IC1Xbm8tZXJyb3IKLQogaW5jbHVkZSAkKFRPUCkvLi4vbWFrZWZpbGUuaW5jCg==
--001a113f284e5b23560515944a16--
0
Ozkan
5/8/2015 4:12:09 PM
On 05/08/2015 07:12 PM, Ozkan Sezer (sezeroz@gmail.com) wrote:
> On 5/4/15, Andris Pavenis (andris.pavenis@iki.fi)
> <djgpp-announce@delorie.com> wrote:
>> This is announcement of DJGPP 2.05 beta 1
>>
>> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
>> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
>> Unfortunately DJGPP v2.04 was never released and old beta version slowly
>> became almost unusable together with other newer DJGPP packages.
>>
>> More information about changes in DJGPP 2.05 beta 1 is available at
>>
>>       http://www.delorie.com/djgpp/doc/kb/
>>
>> both in sections about changes in 2.04 and 2.05. The same information is
>> also
>> available in file info/kb.inf in djdev205.zip
>>
>> It needs a lot of testing. Please test it if you have time and/or are
>> interested in any of the above features. Any level of testing would be
>> appreciated.
> Attached are two tiny patches:
>
> - ioctl-va_end.patch:  adds missing va_end to unix ioctl case.
>
> - no-Wno-error.patch:  removes -Wno-error special cases from
> ioctl.c and fcntl.c build rules. Warnings seem to have been cured
> since ioctl.c r1.8 and fcntl.c r1.10.
Thanks. I applied them.

Andris

0
Andris
5/8/2015 4:51:53 PM
--90e6ba614ed2a3d1640515a49626
Content-Type: text/plain; charset=UTF-8

On 5/4/15, Andris Pavenis (andris.pavenis@iki.fi)
<djgpp-announce@delorie.com> wrote:
> This is announcement of DJGPP 2.05 beta 1
>
> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
> Unfortunately DJGPP v2.04 was never released and old beta version slowly
> became almost unusable together with other newer DJGPP packages.
>
> More information about changes in DJGPP 2.05 beta 1 is available at
>
>      http://www.delorie.com/djgpp/doc/kb/
>
> both in sections about changes in 2.04 and 2.05. The same information is
> also
> available in file info/kb.inf in djdev205.zip
>
> It needs a lot of testing. Please test it if you have time and/or are
> interested in any of the above features. Any level of testing would be
> appreciated.

Here are some more janitorial work: see the attached six patches:

001-makefile.patch :
* src/makefile:
- add -Wall to compiler flags where 'gcc' is used directly to build
  the build utils.
- add -xc to rmake.exe build rule, because older compilers fail in
  linking it, and the source is pure-C anyway.

002-makemake-parens.patch :
* src/makemake.c (find): fix -Wparentheses warning

003-rmake.cc-unused.patch :
* src/rmake.cc: remove unused local variable 'pathp'

004-djasm-mess.patch :
* djasm.y: remove the dependency on local cdefs.h, and fix the
  unused variables mess properly.

005-chew.c-mess.patch :
* src/libm/math/chew.c: remove dependency on ansidecl.h and fix the
  huge mess of conflicting declarations, unused vars and functions,
  and shadowed variables, so that it builds without any warnings at
  all.
* src/libm/math/makefile: remove the ansidecl.h dependency and also
  the -D_HAVE_STDC flag from chew.exe build rule.

006-bin2h.c-no-basename.patch
* src/utils/bin2h.c: remove basename() dependency and report the exe
name simply as 'bin2h', so that it cross-builds without warnings.

Regards.

--
O.S.

--90e6ba614ed2a3d1640515a49626
Content-Type: application/octet-stream; name="001-makefile.patch"
Content-Disposition: attachment; filename="001-makefile.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: file1

KiBzcmMvbWFrZWZpbGU6Ci0gYWRkIC1XYWxsIHRvIGNvbXBpbGVyIGZsYWdzIHdoZXJlICdnY2Mn
IGlzIHVzZWQgZGlyZWN0bHkgdG8gYnVpbGQKICB0aGUgYnVpbGQgdXRpbHMuCi0gYWRkIC14YyB0
byBybWFrZS5leGUgYnVpbGQgcnVsZSwgYmVjYXVzZSBvbGRlciBjb21waWxlcnMgZmFpbCBpbgog
IGxpbmtpbmcgaXQsIGFuZCB0aGUgc291cmNlIGlzIHB1cmUtQyBhbnl3YXkuCgpJbmRleDogc3Jj
L21ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvZGpncHAvZGpncHAvc3JjL21ha2Vm
aWxlLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjE0CmRpZmYgLXUgLXAgLXIxLjE0IG1ha2VmaWxl
Ci0tLSBzcmMvbWFrZWZpbGUJMiBNYXkgMjAxNSAwNzozMTo1OSAtMDAwMAkxLjE0CisrKyBzcmMv
bWFrZWZpbGUJOSBNYXkgMjAxNSAxMDozMDoxNCAtMDAwMApAQCAtMjQsMTYgKzI0LDE2IEBAIERJ
UlMgPSBcCiBhbGwgOiBtaXNjLmV4ZSBjb25maWcgJChESVJTKSBtYWtlbWFrZS5leGUgc3VicyAu
Li9saWIvbGliZy5hIC4uL2xpYi9saWJwYy5hCiAKIG1pc2MuZXhlIDogbWlzYy5jCi0JZ2NjIC1P
MiBtaXNjLmMgLW8gbWlzYy5leGUKKwlnY2MgLU8yIC1XYWxsIG1pc2MuYyAtbyBtaXNjLmV4ZQog
CiAkKERJUlMpIDoKIAkuL21pc2MuZXhlIG1rZGlyICRACiAKIG1ha2VtYWtlLmV4ZSA6IG1ha2Vt
YWtlLmMKLQlnY2MgLU8yIG1ha2VtYWtlLmMgLW8gbWFrZW1ha2UuZXhlCisJZ2NjIC1PMiAtV2Fs
bCBtYWtlbWFrZS5jIC1vIG1ha2VtYWtlLmV4ZQogCiBjb3B5cml0ZS5leGUgOiBjb3B5cml0ZS5j
YwotCWdjYyAtTzIgY29weXJpdGUuY2MgLW8gY29weXJpdGUuZXhlCisJZ2NjIC1PMiAtV2FsbCBj
b3B5cml0ZS5jYyAtbyBjb3B5cml0ZS5leGUKIAogc3ViczoKIAkkKE1BS0UpIC1DIGRqYXNtIG5h
dGl2ZQpAQCAtNzUsNCArNzUsNCBAQCBjb25maWc6CiAJJChNQUtFKSAtZiBtYWtlZmlsZS5jZmcK
IAogcm1ha2UuZXhlOiBybWFrZS5jYwotCWdjYyAtTzIgcm1ha2UuY2MgLW8gcm1ha2UuZXhlCisJ
Z2NjIC1PMiAtV2FsbCAteGMgcm1ha2UuY2MgLW8gcm1ha2UuZXhlCg==
--90e6ba614ed2a3d1640515a49626
Content-Type: application/octet-stream; name="002-makemake-parens.patch"
Content-Disposition: attachment; filename="002-makemake-parens.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: file2

KiBzcmMvbWFrZW1ha2UuYyAoZmluZCk6IGZpeCAtV3BhcmVudGhlc2VzIHdhcm5pbmcKCkluZGV4
OiBzcmMvbWFrZW1ha2UuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvY3ZzL2RqZ3BwL2RqZ3BwL3Ny
Yy9tYWtlbWFrZS5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjEKZGlmZiAtdSAtcCAtcjEuMSBt
YWtlbWFrZS5jCi0tLSBzcmMvbWFrZW1ha2UuYwkxIEphbiAxOTk4IDE4OjE1OjM0IC0wMDAwCTEu
MQorKysgc3JjL21ha2VtYWtlLmMJOSBNYXkgMjAxNSAxMDozMDoxNSAtMDAwMApAQCAtODcsNyAr
ODcsNyBAQCBmaW5kKHZvaWQpCiAgIH0KICAgKnBhdGhfZW5kID0gJy8nOwogICBzdWJzID0gKGNo
YXIgKiopbWFsbG9jKG1zdWJzKnNpemVvZihjaGFyICopKTsKLSAgd2hpbGUgKGRlID0gcmVhZGRp
cihkKSkgeworICB3aGlsZSAoKGRlID0gcmVhZGRpcihkKSkgIT0gTlVMTCkgewogCiAgICAgLyog
U2tpcCAuIGFuZCAuLiAqLwogICAgIGlmIChkZS0+ZF9uYW1lWzBdID09ICcuJykK
--90e6ba614ed2a3d1640515a49626
Content-Type: application/octet-stream; name="003-rmake.cc-unused.patch"
Content-Disposition: attachment; filename="003-rmake.cc-unused.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: file3

c3JjL3JtYWtlLmNjOiByZW1vdmUgdW51c2VkIGxvY2FsIHZhcmlhYmxlICdwYXRocCcKCkluZGV4
OiBzcmMvcm1ha2UuY2MKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9kamdwcC9kamdwcC9zcmMv
cm1ha2UuY2MsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNApkaWZmIC11IC1wIC1yMS40IHJtYWtl
LmNjCi0tLSBzcmMvcm1ha2UuY2MJMiBNYXkgMjAxNSAwNzozMjowMCAtMDAwMAkxLjQKKysrIHNy
Yy9ybWFrZS5jYwk5IE1heSAyMDE1IDEwOjMwOjE1IC0wMDAwCkBAIC0xMiw3ICsxMiw3IEBAIG1h
aW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogewogICBpbnQgaTsKICAgY2hhciBjd2RbMjAwXTsK
LSAgY2hhciBwYXRoWzIwMF0sICpwYXRocDsKKyAgY2hhciBwYXRoWzIwMF07CiAgIGNoYXIgZmls
ZVsyMDBdOwogICBGSUxFICpvaSA9IGZvcGVuKCJtYWtlZmlsZS5vaSIsICJ3Iik7CiAgIEZJTEUg
KnJmID0gZm9wZW4oIm1ha2VmaWxlLnJmMiIsICJ3Iik7Cg==
--90e6ba614ed2a3d1640515a49626
Content-Type: application/octet-stream; name="004-djasm-mess.patch"
Content-Disposition: attachment; filename="004-djasm-mess.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: file4

KiBkamFzbS55OiByZW1vdmUgdGhlIGRlcGVuZGVuY3kgb24gbG9jYWwgY2RlZnMuaCwgYW5kIGZp
eCB0aGUKICB1bnVzZWQgdmFyaWFibGVzIG1lc3MgcHJvcGVybHkuCgpJbmRleDogc3JjL2RqYXNt
L2RqYXNtLnkKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9kamdwcC9kamdwcC9zcmMvZGphc20v
ZGphc20ueSx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xNApkaWZmIC11IC1wIC1yMS4xNCBkamFz
bS55Ci0tLSBzcmMvZGphc20vZGphc20ueQkyIE1heSAyMDE1IDA3OjMyOjAzIC0wMDAwCTEuMTQK
KysrIHNyYy9kamFzbS9kamFzbS55CTkgTWF5IDIwMTUgMTA6MzA6MTYgLTAwMDAKQEAgLTE4LDcg
KzE4LDYgQEAKICNpbmNsdWRlIDx0aW1lLmg+CiAjaW5jbHVkZSA8Y3R5cGUuaD4KICNpbmNsdWRl
IDx1bmlzdGQuaD4KLSNpbmNsdWRlICIuLi8uLi9pbmNsdWRlL3N5cy9jZGVmcy5oIgogI2lmbmRl
ZiBPX0JJTkFSWQogI2RlZmluZSBPX0JJTkFSWSAwCiAjZW5kaWYKQEAgLTE0NjYsMTggKzE0NjUs
MTUgQEAgaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogICAgIHN0cm5jYXQocGV4ZSAr
IElORk9fVEVYVF9TVEFSVCwgY29weXJpZ2h0LCAoNTEyLTMtSU5GT19URVhUX1NUQVJUKSAtIHN0
cmxlbihwZXhlICsgSU5GT19URVhUX1NUQVJUKSk7IC8qIC0zIGZvciB0aGUgZm9sbG93aW5nIGxp
bmU6ICovCiAgIHN0cmNhdChwZXhlICsgSU5GT19URVhUX1NUQVJULCAiXHJcblwwMzIiKTsKIAot
ICBpZiAoYXJndlsyXSA9PSAwKQorICBpZiAoISBhcmd2WzJdKQogICB7Ci0gICAgY2hhciAqY3As
ICAqZG90ID0gTlVMTCwgKnNsIF9BVFRSSUJVVEUoX191bnVzZWRfXykgPSBOVUxMOworICAgIGNo
YXIgKmNwLCAqZG90ID0gTlVMTDsKICAgICBvdXRmaWxlbmFtZSA9IChjaGFyICopYWxsb2NhKHN0
cmxlbihhcmd2WzFdKSs1KTsKICAgICBzdHJjcHkob3V0ZmlsZW5hbWUsIGFyZ3ZbMV0pOwogICAg
IGZvciAoY3A9b3V0ZmlsZW5hbWU7ICpjcDsgY3ArKykKICAgICB7CiAgICAgICBpZiAoKmNwID09
ICc6JyB8fCAqY3AgPT0gJ1xcJyB8fCAqY3AgPT0gJy8nKQotICAgICAgewotICAgICAgICBzbCA9
IGNwKzE7Ci0gICAgICAgIGRvdCA9IDA7Ci0gICAgICB9CisgICAgICAgIGRvdCA9IE5VTEw7CiAg
ICAgICBpZiAoKmNwID09ICcuJykKICAgICAgICAgZG90ID0gY3A7CiAgICAgfQpAQCAtMTQ5MCwy
NCArMTQ4NiwyMSBAQCBpbnQgbWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAgIH0KICAgZWxz
ZQogICB7Ci0gICAgY2hhciAqZG90PTAsICpzbD0wLCAqY3A7CisgICAgY2hhciAqY3AsICpkb3Qg
PSBOVUxMOworICAgIHNpemVfdCBzeiA9IHN0cmxlbihhcmd2WzJdKTsKICAgICBvdXRmaWxlbmFt
ZSA9IGFyZ3ZbMl07CiAgICAgZm9yIChjcD1vdXRmaWxlbmFtZTsgKmNwOyBjcCsrKQogICAgIHsK
ICAgICAgIGlmICgqY3AgPT0gJzonIHx8ICpjcCA9PSAnXFwnIHx8ICpjcCA9PSAnLycpCi0gICAg
ICB7Ci0gICAgICAgIHNsID0gY3ArMTsKLSAgICAgICAgZG90ID0gMDsKLSAgICAgIH0KKyAgICAg
ICAgZG90ID0gTlVMTDsKICAgICAgIGlmICgqY3AgPT0gJy4nKQogICAgICAgICBkb3QgPSBjcDsK
ICAgICB9CiAgICAgaWYgKCFkb3QpCiAgICAgewotICAgICAgc2wgPSAoY2hhciAqKWFsbG9jYShz
dHJsZW4ob3V0ZmlsZW5hbWUpKzUpOwotICAgICAgc3RyY3B5KHNsLCBvdXRmaWxlbmFtZSk7Ci0g
ICAgICBvdXRmaWxlbmFtZSA9IHNsOwotICAgICAgZG90ID0gb3V0ZmlsZW5hbWUgKyBzdHJsZW4o
b3V0ZmlsZW5hbWUpOworICAgICAgb3V0ZmlsZW5hbWUgPSAoY2hhciAqKWFsbG9jYShzeis1KTsK
KyAgICAgIHN0cmNweShvdXRmaWxlbmFtZSwgYXJndlsyXSk7CisgICAgICBkb3QgPSBvdXRmaWxl
bmFtZSArIHN6OwogICAgICAgKmRvdCA9ICcuJzsKICAgICAgIHN0cmNweShkb3QrMSwgZXh0X3R5
cGVzW291dF90eXBlXSk7CiAgICAgfQpAQCAtMjY2Myw3ICsyNjU2LDcgQEAgdm9pZCBhZGRfY29w
eXJpZ2h0KGNoYXIgKmJ1ZikKICAgY29weXJpZ2h0ID0gdG1wOwogfQogCi12b2lkIGFkZF9yY3Nf
aWRlbnQoKQordm9pZCBhZGRfcmNzX2lkZW50KHZvaWQpCiB7CiAgIGNoYXIgdG1wWzUwMF07CiAg
IHRpbWVfdCBub3c7CkBAIC0yNzY1LDE1ICsyNzU4LDE4IEBAIHZvaWQgZG9fbGlua2NvZmYgKGNo
YXIgKmZpbGVuYW1lKQogICBTQ05IRFIgKmZfdGhkcjsJCS8qIFRleHQgc2VjdGlvbiBoZWFkZXIg
Ki8KICAgU0NOSERSICpmX2RoZHI7CQkvKiBEYXRhIHNlY3Rpb24gaGVhZGVyICovCiAgIFNDTkhE
UiAqZl9iaGRyOwkJLyogQnNzIHNlY3Rpb24gaGVhZGVyICovCi0vKiAgQU9VVEhEUiBmX29oZHI7
Ki8JCS8qIE9wdGlvbmFsIGZpbGUgaGVhZGVyIChhLm91dCkgKi8KKy8qQU9VVEhEUiBmX29oZHI7
Ki8JCS8qIE9wdGlvbmFsIGZpbGUgaGVhZGVyIChhLm91dCkgKi8KICAgU1lNRU5UICpzeW1ib2w7
CiAgIFJFTE9DICpycDsKICAgaW50IGNudDsKICAgc2l6ZV90IGk7CiAgIHZvaWQgKmJhc2U7Ci0g
IGludCB0ZXh0YmFzZSwgZGF0YWJhc2UgX0FUVFJJQlVURShfX3VudXNlZF9fKSwgYnNzYmFzZSBf
QVRUUklCVVRFKF9fdW51c2VkX18pIC8qLCBkZWx0YSovOworICBpbnQgdGV4dGJhc2UgLyosIGRl
bHRhKi87CisjaWZkZWYgREVCVUdfUkVMT0MKKyAgaW50IGRhdGFiYXNlLCBic3NiYXNlOworI2Vu
ZGlmCiAgIGNoYXIgc21hbGxuYW1lWzldOwotICB1bnNpZ25lZCBjaGFyICpjcCBfQVRUUklCVVRF
KF9fdW51c2VkX18pOworLyp1bnNpZ25lZCBjaGFyICpjcDsqLwogCiAgIGYgPSBvcGVuIChmaWxl
bmFtZSwgT19SRE9OTFkgfCBPX0JJTkFSWSk7CiAgIGlmIChmIDwgMCkKQEAgLTI4MDQsOSArMjgw
MCwxMyBAQCB2b2lkIGRvX2xpbmtjb2ZmIChjaGFyICpmaWxlbmFtZSkKIAogICB0ZXh0YmFzZSA9
IHBjOwogICBlbWl0KGRhdGEgKyBmX3RoZHItPnNfc2NucHRyLCBmX3RoZHItPnNfc2l6ZSk7Cisj
aWZkZWYgREVCVUdfUkVMT0MKICAgZGF0YWJhc2UgPSBwYzsKKyNlbmRpZgogICBlbWl0KGRhdGEg
KyBmX2RoZHItPnNfc2NucHRyLCBmX2RoZHItPnNfc2l6ZSk7CisjaWZkZWYgREVCVUdfUkVMT0MK
ICAgYnNzYmFzZSA9IHBjOworI2VuZGlmCiAgIGZvciAoaSA9IDA7IGkgPCBmX2JoZHItPnNfc2l6
ZTsgaSsrKQogICAgIGVtaXRiICgwKTsKIApAQCAtMjk0OCw3ICsyOTQ4LDcgQEAgdm9pZCBkb19s
aW5rY29mZiAoY2hhciAqZmlsZW5hbWUpCiAJCSAgICAgICBpbm5hbWUsIGxpbmVubywgZmlsZW5h
bWUsIHJwLT5yX3R5cGUpOwogCSAgICAgIGRlbHRhID0gMDsKIAkgICAgfQotCSAgY3AgPSAodW5z
aWduZWQgY2hhciAqKShvdXRiaW4gKyB0ZXh0YmFzZSArIHJwLT5yX3ZhZGRyKTsKKwkgIC8qY3Ag
PSAodW5zaWduZWQgY2hhciAqKShvdXRiaW4gKyB0ZXh0YmFzZSArIHJwLT5yX3ZhZGRyKTsqLwog
CSAgdmFkZHIgKz0gZGVsdGE7CiAJICB2YWRkcl9wdHJbMF09dmFkZHI7CiAJICB2YWRkcl9wdHJb
MV09dmFkZHI+Pjg7Cg==
--90e6ba614ed2a3d1640515a49626
Content-Type: application/octet-stream; name="005-chew.c-mess.patch"
Content-Disposition: attachment; filename="005-chew.c-mess.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: file5

KiBzcmMvbGlibS9tYXRoL2NoZXcuYzogcmVtb3ZlIGRlcGVuZGVuY3kgb24gYW5zaWRlY2wuaCBh
bmQgZml4IHRoZQogIGh1Z2UgbWVzcyBvZiBjb25mbGljdGluZyBkZWNsYXJhdGlvbnMsIHVudXNl
ZCB2YXJzIGFuZCBmdW5jdGlvbnMsCiAgYW5kIHNoYWRvd2VkIHZhcmlhYmxlcywgc28gdGhhdCBp
dCBidWlsZHMgd2l0aG91dCBhbnkgd2FybmluZ3MgYXQKICBhbGwuCiogc3JjL2xpYm0vbWF0aC9t
YWtlZmlsZTogcmVtb3ZlIHRoZSBhbnNpZGVjbC5oIGRlcGVuZGVuY3kgYW5kIGFsc28KICB0aGUg
LURfSEFWRV9TVERDIGZsYWcgZnJvbSBjaGV3LmV4ZSBidWlsZCBydWxlLgoKSW5kZXg6IHNyYy9s
aWJtL21hdGgvbWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9kamdwcC9kamdwcC9z
cmMvbGlibS9tYXRoL21ha2VmaWxlLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjExCmRpZmYgLXUg
LXAgLXIxLjExIG1ha2VmaWxlCi0tLSBzcmMvbGlibS9tYXRoL21ha2VmaWxlCTE3IE5vdiAyMDEz
IDE0OjI3OjU3IC0wMDAwCTEuMTEKKysrIHNyYy9saWJtL21hdGgvbWFrZWZpbGUJOSBNYXkgMjAx
NSAxMDozMDoxNyAtMDAwMApAQCAtMjE3LDggKzIxNyw4IEBAIHRhcmdldGRlcC50ZXhpOiAkKGNo
b2JqKSBtYXRoLnRleGkKICUuZGVmOiAlLmMgY2hldy5leGUKIAkkKENIRVcpIDwgJDwgPiAkQAog
Ci1jaGV3LmV4ZTogY2hldy5jIGFuc2lkZWNsLmgKLQkkKEdDQykgLURfSEFWRV9TVERDIC1PMiAt
byAkQCAkPAorY2hldy5leGU6IGNoZXcuYworCSQoR0NDKSAtTzIgLW8gJEAgJDwKIAogY2xlYW4g
OjoKIAktJChNSVNDKSBybSAqLmRlZiAqLmQgY2hldy5leGUgdGFyZ2V0ZGVwLnRleGkKSW5kZXg6
IHNyYy9saWJtL21hdGgvY2hldy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvZGpncHAvZGpn
cHAvc3JjL2xpYm0vbWF0aC9jaGV3LmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMwpkaWZmIC11
IC1wIC1yMS4zIGNoZXcuYwotLS0gc3JjL2xpYm0vbWF0aC9jaGV3LmMJMzAgSnVsIDIwMTEgMTM6
MDU6NDkgLTAwMDAJMS4zCisrKyBzcmMvbGlibS9tYXRoL2NoZXcuYwk5IE1heSAyMDE1IDEwOjMw
OjE3IC0wMDAwCkBAIC0yLDcgKzIsNiBAQAogICAgQ29weXJpZ2h0IChDKSAxOTkwLTE5OTIgRnJl
ZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCiAgICBDb250cmlidXRlZCBieSBzdGV2ZSBjaGFt
YmVybGFpbiBAY3lnbnVzCiAKLQogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBj
YW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CiB0aGUgRnJlZSBT
b2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgpA
QCAtMjEsNyArMjAsNyBAQCBGb3VuZGF0aW9uLCBJbmMuLCA2NzUgTWFzcyBBdmUsIENhbWJyaWRn
CiAgWWV0IGFub3RoZXIgd2F5IG9mIGV4dHJhY3RpbmcgZG9jdW1lbnRhdGlvbiBmcm9tIHNvdXJj
ZS4KICBObywgSSBoYXZlbid0IGZpbmlzaGVkIGl0IHlldCwgYnV0IEkgaG9wZSB5b3UgcGVvcGxl
IGxpa2UgaXQgYmV0dGVyCiAgdGhhdCB0aGUgb2xkIHdheQotICAKKwogIHNhYwogCiBCYXNpY2Fs
bHksIHRoaXMgaXMgYSBzb3J0IG9mIHN0cmluZyBmb3J0aCwgbWF5YmUgd2Ugc2hvdWxkIGNhbGwg
aXQKQEAgLTI5LDIyICsyOCwxNyBAQCBzdHJ1dGg/CiAKIFlvdSBkZWZpbmUgbmV3IHdvcmRzIHRo
dXM6CiA6IDxuZXd3b3JkPiA8b2xkd29yZHM+IDsKLVRoZXJlIGlzICBubwogCiAqLwogCiAKLQot
I2luY2x1ZGUgImFuc2lkZWNsLmgiCiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNsdWRlIDxzdGRs
aWIuaD4KKyNpbmNsdWRlIDxzdHJpbmcuaD4KICNpbmNsdWRlIDxjdHlwZS5oPgogI2luY2x1ZGUg
PGZjbnRsLmg+CiAjaW5jbHVkZSA8dW5pc3RkLmg+CiAKLWV4dGVybiBQVFIgbWFsbG9jKCk7Ci1l
eHRlcm4gUFRSIHJlYWxsb2MoKTsKLQogI2RlZmluZSBERUZfU0laRSA1MDAwCiAjZGVmaW5lIFNU
QUNLIDUwCiAKQEAgLTUyLDEwICs0Niw4IEBAIGludCBpbnRlcm5hbF93YW50ZWQ7CiBpbnQgaW50
ZXJuYWxfbW9kZTsKIAogCi0KIC8qIEhlcmUgaXMgYSBzdHJpbmcgdHlwZSAuLi4gKi8KLQotdHlw
ZWRlZiBzdHJ1Y3QgYnVmZmVyIAordHlwZWRlZiBzdHJ1Y3QgYnVmZmVyCiB7CiAgICAgY2hhciAq
cHRyOwogICAgIHVuc2lnbmVkIGludCB3cml0ZV9pZHg7CkBAIC02MywzNSArNTUsMjQgQEAgdHlw
ZWRlZiBzdHJ1Y3QgYnVmZmVyIAogfSBzdHJpbmdfdHlwZTsKIAogCi0KLQotCi0KLQotc3RhdGlj
IHZvaWQgREVGVU4oaW5pdF9zdHJpbmdfd2l0aF9zaXplLChidWZmZXIsIHNpemUpLAotCSAgIHN0
cmluZ190eXBlICpidWZmZXIgQU5ECi0JICAgdW5zaWduZWQgaW50IHNpemUgKQorc3RhdGljIHZv
aWQgaW5pdF9zdHJpbmdfd2l0aF9zaXplKHN0cmluZ190eXBlICpidWZmZXIsIHVuc2lnbmVkIGlu
dCBzaXplKQogewogICBidWZmZXItPndyaXRlX2lkeCA9IDA7CiAgIGJ1ZmZlci0+c2l6ZSA9IHNp
emU7CiAgIGJ1ZmZlci0+cHRyID0gbWFsbG9jKHNpemUpOwogfQogCi1zdGF0aWMgdm9pZCBERUZV
Tihpbml0X3N0cmluZywoYnVmZmVyKSwKLQkgICBzdHJpbmdfdHlwZSAqYnVmZmVyKQorc3RhdGlj
IHZvaWQgaW5pdF9zdHJpbmcoc3RyaW5nX3R5cGUgKmJ1ZmZlcikKIHsKICAgICBpbml0X3N0cmlu
Z193aXRoX3NpemUoYnVmZmVyLCBERUZfU0laRSk7Ci0KIH0KIAotc3RhdGljIGludCBERUZVTihm
aW5kLCAoc3RyLCB3aGF0KSwKLQkgIHN0cmluZ190eXBlICpzdHIgQU5ECi0JICBjaGFyICp3aGF0
KQorc3RhdGljIGludCBmaW5kKHN0cmluZ190eXBlICpzdHIsIGNvbnN0IGNoYXIgKndoYXQpCiB7
CiAgICAgdW5zaWduZWQgaW50IGk7Ci0gICAgY2hhciAqcDsKKyAgICBjb25zdCBjaGFyICpwOwog
ICAgIHAgPSB3aGF0OwotICAgIGZvciAoaSA9IDA7IGkgPCBzdHItPndyaXRlX2lkeCAmJiAqcDsg
aSsrKSAKKyAgICBmb3IgKGkgPSAwOyBpIDwgc3RyLT53cml0ZV9pZHggJiYgKnA7IGkrKykKICAg
ICB7CiAJaWYgKCpwID09IHN0ci0+cHRyW2ldKQogCSBwKys7CkBAIC05OSw1OCArODAsNDIgQEAg
c3RhdGljIGludCBERUZVTihmaW5kLCAoc3RyLCB3aGF0KSwKIAkgcCA9IHdoYXQ7CiAgICAgfQog
ICAgIHJldHVybiAoKnAgPT0gMCk7Ci0gICAgCiB9CiAKLXN0YXRpYyB2b2lkIERFRlVOKHdyaXRl
X2J1ZmZlciwoYnVmZmVyKSwKLQkgICBzdHJpbmdfdHlwZSAqYnVmZmVyKQorc3RhdGljIHZvaWQg
d3JpdGVfYnVmZmVyKHN0cmluZ190eXBlICpidWZmZXIpCiB7CiAgICAgZndyaXRlKGJ1ZmZlci0+
cHRyLCBidWZmZXItPndyaXRlX2lkeCwgMSwgc3Rkb3V0KTsKIH0KIAotCi1zdGF0aWMgdm9pZCBE
RUZVTihkZWxldGVfc3RyaW5nLChidWZmZXIpLAotCSAgIHN0cmluZ190eXBlICpidWZmZXIpCitz
dGF0aWMgdm9pZCBkZWxldGVfc3RyaW5nKHN0cmluZ190eXBlICpidWZmZXIpCiB7CiAgICAgZnJl
ZShidWZmZXItPnB0cik7CiB9CiAKLQotc3RhdGljIGNoYXIgKkRFRlVOKGFkZHIsIChidWZmZXIs
IGlkeCksCi0JICAgIHN0cmluZ190eXBlICpidWZmZXIgQU5ECi0JICAgIHVuc2lnbmVkIGludCBp
ZHgpCitzdGF0aWMgY2hhciAqYWRkcihzdHJpbmdfdHlwZSAqYnVmZmVyLCB1bnNpZ25lZCBpbnQg
aWR4KQogewogICAgIHJldHVybiBidWZmZXItPnB0ciArIGlkeDsKIH0KIAotc3RhdGljIGNoYXIg
REVGVU4oYXQsKGJ1ZmZlciwgcG9zKSwKLQkgICBzdHJpbmdfdHlwZSAqYnVmZmVyIEFORAotCSAg
IHVuc2lnbmVkIGludCBwb3MpIAorc3RhdGljIGNoYXIgYXQoc3RyaW5nX3R5cGUgKmJ1ZmZlciwg
dW5zaWduZWQgaW50IHBvcykKIHsKLSAgICBpZiAoIHBvcyA+PSBidWZmZXItPndyaXRlX2lkeCkg
Ci0gICAgeworICAgIGlmIChwb3MgPj0gYnVmZmVyLT53cml0ZV9pZHgpCiAJcmV0dXJuIDA7Ci0g
ICAgfQogICAgIHJldHVybiBidWZmZXItPnB0cltwb3NdOwogfQogCi1zdGF0aWMgdm9pZCBERUZV
TihjYXRjaGFyLChidWZmZXIsIGNoKSwgCi0JICAgc3RyaW5nX3R5cGUgKmJ1ZmZlciBBTkQKLQkg
ICBjaGFyIGNoKQorc3RhdGljIHZvaWQgY2F0Y2hhcihzdHJpbmdfdHlwZSAqYnVmZmVyLCBjaGFy
IGNoKQogewotICBpZiAoYnVmZmVyLT53cml0ZV9pZHggPT0gYnVmZmVyLT5zaXplKSAKKyAgaWYg
KGJ1ZmZlci0+d3JpdGVfaWR4ID09IGJ1ZmZlci0+c2l6ZSkKICAgewotICAgIGJ1ZmZlci0+c2l6
ZSAqPTI7CisgICAgYnVmZmVyLT5zaXplICo9IDI7CiAgICAgYnVmZmVyLT5wdHIgPSByZWFsbG9j
KGJ1ZmZlci0+cHRyLCBidWZmZXItPnNpemUpOwogICB9CiAKLSAgYnVmZmVyLT5wdHJbYnVmZmVy
LT53cml0ZV9pZHggKysgXSA9IGNoOworICBidWZmZXItPnB0cltidWZmZXItPndyaXRlX2lkeCsr
XSA9IGNoOwogfQogCi0KLXN0YXRpYyB2b2lkIERFRlVOKG92ZXJ3cml0ZV9zdHJpbmcsKGRzdCwg
ICBzcmMpLAotCSAgIHN0cmluZ190eXBlICpkc3QgQU5ECi0JICAgc3RyaW5nX3R5cGUgKnNyYykK
K3N0YXRpYyB2b2lkIG92ZXJ3cml0ZV9zdHJpbmcoc3RyaW5nX3R5cGUgKmRzdCwgc3RyaW5nX3R5
cGUgKnNyYykKIHsKICAgICBmcmVlKGRzdC0+cHRyKTsKICAgICBkc3QtPnNpemUgPSBzcmMtPnNp
emU7CkBAIC0xNTgsMTk2ICsxMjMsMTU5IEBAIHN0YXRpYyB2b2lkIERFRlVOKG92ZXJ3cml0ZV9z
dHJpbmcsKGRzdCwKICAgICBkc3QtPnB0ciA9IHNyYy0+cHRyOwogfQogCi1zdGF0aWMgdm9pZCBE
RUZVTihjYXRzdHIsKGRzdCwgc3JjKSwKLQkgICBzdHJpbmdfdHlwZSAqZHN0IEFORAotCSAgIHN0
cmluZ190eXBlICpzcmMpCitzdGF0aWMgdm9pZCBjYXRzdHIoc3RyaW5nX3R5cGUgKmRzdCwgc3Ry
aW5nX3R5cGUgKnNyYykKIHsKICAgICB1bnNpZ25lZCBpbnQgaTsKLSAgICBmb3IgKGkgPSAwOyBp
IDwgc3JjLT53cml0ZV9pZHg7IGkrKykgCi0gICAgeworICAgIGZvciAoaSA9IDA7IGkgPCBzcmMt
PndyaXRlX2lkeDsgaSsrKSB7CiAJY2F0Y2hhcihkc3QsIHNyYy0+cHRyW2ldKTsKICAgICB9CiB9
CiAKIAotc3RhdGljIHZvaWQgREVGVU4oY2F0dGV4dCwoYnVmZmVyLCBzdHJpbmcpLAotCSAgIHN0
cmluZ190eXBlICpidWZmZXIgQU5ECi0JICAgY2hhciAqc3RyaW5nKQorc3RhdGljIHZvaWQgY2F0
dGV4dChzdHJpbmdfdHlwZSAqYnVmZmVyLCBjb25zdCBjaGFyICpzdHJpbmcpCiB7Ci0gICAgCi0g
ICAgd2hpbGUgKCpzdHJpbmcpIAorICAgIHdoaWxlICgqc3RyaW5nKQogICAgIHsKIAljYXRjaGFy
KGJ1ZmZlciwgKnN0cmluZyk7CiAJc3RyaW5nKys7CiAgICAgfQogfQogCi1zdGF0aWMgdm9pZCBE
RUZVTihjYXRidWYsKGJ1ZmZlciwgYnVmLCBsZW4pLAotCSAgIHN0cmluZ190eXBlICpidWZmZXIg
QU5ECi0JICAgY2hhciAqYnVmIEFORAotCSAgIHVuc2lnbmVkIGludCBsZW4pCitzdGF0aWMgdm9p
ZCBjYXRidWYoc3RyaW5nX3R5cGUgKmJ1ZmZlciwgY29uc3QgY2hhciAqYnVmLCB1bnNpZ25lZCBp
bnQgbGVuKQogewotICAgIAotICAgIHdoaWxlIChsZW4tLSkgCisgICAgd2hpbGUgKGxlbi0tKQog
ICAgIHsKIAljYXRjaGFyKGJ1ZmZlciwgKmJ1Zik7CiAJYnVmKys7CiAgICAgfQogfQogCi0KLQot
c3RhdGljIHVuc2lnbmVkIGludCAKLURFRlVOKHNraXBfd2hpdGVfYW5kX3N0YXJzLChzcmMsIGlk
eCksCi0gICAgICBzdHJpbmdfdHlwZSAqc3JjIEFORAotICAgICAgdW5zaWduZWQgaW50IGlkeCkK
K3N0YXRpYyB1bnNpZ25lZCBpbnQgc2tpcF93aGl0ZV9hbmRfc3RhcnMoc3RyaW5nX3R5cGUgKnNy
YywgdW5zaWduZWQgaW50IGlkeCkKIHsKLSAgICB3aGlsZSAoaXNzcGFjZShhdChzcmMsaWR4KSkg
Ci0JICAgfHwgKGF0KHNyYyxpZHgpID09ICcqJyAmJiBhdChzcmMsaWR4ICsxKSAhPScvJykpIAor
ICAgIHdoaWxlIChpc3NwYWNlKGF0KHNyYyxpZHgpKQorCSAgIHx8IChhdChzcmMsaWR4KSA9PSAn
KicgJiYgYXQoc3JjLGlkeCArMSkgIT0nLycpKQogICAgICBpZHgrKzsKICAgICByZXR1cm4gaWR4
OwotICAgIAotCiB9CisKIC8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KIAogCi1zdHJpbmdfdHlwZSBzdGFja1tT
VEFDS107Ci1zdHJpbmdfdHlwZSAqdG9zOworc3RhdGljIHN0cmluZ190eXBlIHN0YWNrW1NUQUNL
XTsKK3N0YXRpYyBzdHJpbmdfdHlwZSAqdG9zOwogCi11bnNpZ25lZCBpbnQgaWR4ID0gMDsgLyog
UG9zIGluIGlucHV0IGJ1ZmZlciAqLwotc3RyaW5nX3R5cGUgKnB0cjsgLyogYW5kIHRoZSBidWZm
ZXIgKi8KK3N0YXRpYyB1bnNpZ25lZCBpbnQgcG9zID0gMDsgLyogUG9zIGluIGlucHV0IGJ1ZmZl
ciAqLworc3RhdGljIHN0cmluZ190eXBlICpwdHI7IC8qIGFuZCB0aGUgYnVmZmVyICovCiB0eXBl
ZGVmIHZvaWQgKCpzdGluc3RfdHlwZSkoKTsKLXN0aW5zdF90eXBlICpwYzsKLXN0aW5zdF90eXBl
IHNzdGFja1tTVEFDS107Ci1zdGluc3RfdHlwZSAqc3NwID0gJnNzdGFja1swXTsKLSNpZmRlZiBf
V0lONjQKLXR5cGVkZWYgbG9uZyBsb25nCWludHA7CitzdGF0aWMgc3RpbnN0X3R5cGUgKnBjOwor
I2lmZGVmIF9XSU42NAkJCS8qIF9XSU42NCBpcyBfTExQNjQgKi8KK3R5cGVkZWYgbG9uZyBsb25n
IGludAlpbnRwOwogI2Vsc2UKLXR5cGVkZWYgbG9uZwkJaW50cDsKK3R5cGVkZWYgbG9uZyBpbnQJ
aW50cDsKICNlbmRpZgotaW50cCBpc3RhY2tbU1RBQ0tdOwotaW50cCAqaXNwID0gJmlzdGFja1sw
XTsKK3N0YXRpYyBpbnRwIGlzdGFja1tTVEFDS107CitzdGF0aWMgaW50cCAqaXNwID0gJmlzdGFj
a1swXTsKIAogdHlwZWRlZiBpbnQgKndvcmRfdHlwZTsKIAotCi0KIHN0cnVjdCBkaWN0X3N0cnVj
dAogewogICAgIGNoYXIgKndvcmQ7CiAgICAgc3RydWN0IGRpY3Rfc3RydWN0ICpuZXh0OwotICAg
c3RpbnN0X3R5cGUgKmNvZGU7CisgICAgc3RpbnN0X3R5cGUgKmNvZGU7CiAgICAgaW50IGNvZGVf
bGVuZ3RoOwogICAgIGludCBjb2RlX2VuZDsKICAgICBpbnQgdmFyOwotICAgIAogfTsKIHR5cGVk
ZWYgc3RydWN0IGRpY3Rfc3RydWN0IGRpY3RfdHlwZTsKLSNkZWZpbmUgV09SRCh4KSBzdGF0aWMg
dm9pZCB4KCkKIAotc3RhdGljIHZvaWQgREVGVU4oZXhlYywod29yZCksCi0JCSAgZGljdF90eXBl
ICp3b3JkKQorCitzdGF0aWMgdm9pZCBleGVjKGRpY3RfdHlwZSAqd29yZCkKIHsKICAgICBwYyA9
IHdvcmQtPmNvZGU7Ci0gICAgd2hpbGUgKCpwYykgCi0gICAgeworICAgIHdoaWxlICgqcGMpIHsK
IAkoKnBjKSgpOwogICAgIH0KLSAgICAKIH0KLVdPUkQoY2FsbCkKKworc3RhdGljIHZvaWQgY2Fs
bCh2b2lkKQogewotc3RpbnN0X3R5cGUgKm9sZHBjID0gcGM7CisgICAgc3RpbnN0X3R5cGUgKm9s
ZHBjID0gcGM7CiAgICAgZGljdF90eXBlICplOwogICAgIGUgPSAgKGRpY3RfdHlwZSAqKShwYyBb
MV0pOwogICAgIGV4ZWMoZSk7CiAgICAgcGMgPSBvbGRwYyArIDI7Ci0gICAgCiB9CiAKLVdPUkQo
cmVtY2hhcikKK3N0YXRpYyB2b2lkIHJlbWNoYXIodm9pZCkKIHsKLSAgICB0b3MtPndyaXRlX2lk
eC0tOyAgICAKKyAgICB0b3MtPndyaXRlX2lkeC0tOwogICAgIHBjKys7Ci0gICAgCiB9CiAKLVdP
UkQocHVzaF9udW1iZXIpCitzdGF0aWMgdm9pZCBwdXNoX251bWJlcih2b2lkKQogewogICAgIGlz
cCsrOwogICAgIHBjKys7CiAgICAgKmlzcCA9IChpbnRwKSgqcGMpOwogICAgIHBjKys7Ci0gICAg
CiB9CiAKLQotCi0KLVdPUkQocHVzaF90ZXh0KQorc3RhdGljIHZvaWQgcHVzaF90ZXh0KHZvaWQp
CiB7Ci0gICAgCiAgICAgdG9zKys7CiAgICAgaW5pdF9zdHJpbmcodG9zKTsKICAgICBwYysrOwog
ICAgIGNhdHRleHQodG9zLCooKGNoYXIgKiopcGMpKTsKICAgICBwYysrOwotICAgIAogfQogCiAK
LSAgIAogLyogVGhpcyBmdW5jdGlvbiByZW1vdmVzIGV2ZXJ5dGhpbmcgbm90IGluc2lkZSBjb21t
ZW50cyBzdGFydGluZyBvbgogICAgdGhlIGZpcnN0IGNoYXIgb2YgdGhlIGxpbmUgZnJvbSB0aGUg
IHN0cmluZywgYWxzbyB3aGVuIGNvcHlpbmcKLSAgIGNvbW1lbnRzLCByZW1vdmVzIGJsYW5rIHNw
YWNlIGFuZCBsZWFkaW5nIConcyAKKyAgIGNvbW1lbnRzLCByZW1vdmVzIGJsYW5rIHNwYWNlIGFu
ZCBsZWFkaW5nIConcwogICAgQmxhbmsgbGluZXMgYXJlIHR1cm5lZCBpbnRvIG9uZSBibGFuayBs
aW5lCiAgKi8KLQotc3RhdGljIHZvaWQgCi1ERUZVTihyZW1vdmVfbm9uY29tbWVudHMsKHNyYyxk
c3QpLAotCSAgIHN0cmluZ190eXBlICpzcmMgQU5ECi0JICAgc3RyaW5nX3R5cGUgKmRzdCkKK3N0
YXRpYyB2b2lkIHJlbW92ZV9ub25jb21tZW50cyhzdHJpbmdfdHlwZSAqc3JjLCBzdHJpbmdfdHlw
ZSAqZHN0KQogewogICAgIHVuc2lnbmVkIGludCBpZHggPSAwOwotICAgIAotICAgIHdoaWxlIChh
dChzcmMsaWR4KSkgCisKKyAgICB3aGlsZSAoYXQoc3JjLGlkeCkpCiAgICAgewogCS8qIE5vdyBz
ZWUgaWYgd2UgaGF2ZSBhIGNvbW1lbnQgYXQgdGhlIHN0YXJ0IG9mIHRoZSBsaW5lICovCi0JaWYg
KGF0KHNyYyxpZHgpID09ICdcbicgCi0JICAgICYmIGF0KHNyYyxpZHgrMSkgPT0gICcvJyAKLQkg
ICAgJiYgYXQoc3JjLGlkeCsyKSA9PSAnKicpIAorCWlmIChhdChzcmMsaWR4KSAgID09ICdcbicg
JiYKKwkgICAgYXQoc3JjLGlkeCsxKSA9PSAgJy8nICYmCisJICAgIGF0KHNyYyxpZHgrMikgPT0g
JyonKQogCXsKLQkgICAgaWR4Kz0zOwotCSAgICAKKwkgICAgaWR4ICs9IDM7CiAJICAgIGlkeCA9
IHNraXBfd2hpdGVfYW5kX3N0YXJzKHNyYyxpZHgpOwogCiAJICAgIC8qIFJlbW92ZSBsZWFkaW5n
IGRvdCAqLwotCSAgICBpZiAoYXQoc3JjLCBpZHgpID09ICcuJykKLQkgICAgIGlkeCsrOwotCSAg
ICAKKwkgICAgaWYgKGF0KHNyYyxpZHgpID09ICcuJykKKwkJaWR4Kys7CisKIAkgICAgLyogQ29w
eSB0byB0aGUgZW5kIG9mIHRoZSBsaW5lLCBvciB0aWxsIHRoZSBlbmQgb2YgdGhlCiAJICAgICAg
IGNvbW1lbnQgKi8KLQkgICAgd2hpbGUgKGF0KHNyYywgaWR4KSkKKwkgICAgd2hpbGUgKGF0KHNy
YyxpZHgpKQogCSAgICB7Ci0JCWlmIChhdChzcmMsIGlkeCkgPT0gJ1xuJykgCisJCWlmIChhdChz
cmMsaWR4KSA9PSAnXG4nKQogCQl7CiAJCSAgICAvKiBlbmQgb2YgbGluZSwgZWNobyBhbmQgc2Ny
YXBlIG9mIGxlYWRpbmcgYmxhbmtzICAqLwogCQkgICAgaWYgKGF0KHNyYyxpZHggKzEpID09ICdc
bicpCi0JCSAgICAgY2F0Y2hhcihkc3QsJ1xuJyk7CisJCQljYXRjaGFyKGRzdCwnXG4nKTsKIAkJ
ICAgIGNhdGNoYXIoZHN0LCdcbicpOwogCQkgICAgaWR4Kys7Ci0JCSAgICBpZHggPSAgIHNraXBf
d2hpdGVfYW5kX3N0YXJzKHNyYywgaWR4KTsKKwkJICAgIGlkeCA9IHNraXBfd2hpdGVfYW5kX3N0
YXJzKHNyYywgaWR4KTsKIAkJfQotCQllbHNlIGlmIChhdChzcmMsIGlkeCkgPT0gJyonICYmIGF0
KHNyYyxpZHgrMSkgPT0gJy8nKSAKKwkJZWxzZSBpZiAoYXQoc3JjLGlkeCkgPT0gJyonICYmIGF0
KHNyYyxpZHgrMSkgPT0gJy8nKQogCQl7Ci0JCSAgICBpZHggKz0yIDsKKwkJICAgIGlkeCArPSAy
OwogCQkgICAgY2F0dGV4dChkc3QsIlxuRU5ERERcbiIpOwogCQkgICAgYnJlYWs7CiAJCX0KLQkJ
ZWxzZSAKKwkJZWxzZQogCQl7Ci0JCSAgICBjYXRjaGFyKGRzdCwgYXQoc3JjLCBpZHgpKTsKKwkJ
ICAgIGNhdGNoYXIoZHN0LCBhdChzcmMsaWR4KSk7CiAJCSAgICBpZHgrKzsKIAkJfQogCSAgICB9
CkBAIC0zNTUsOTkgKzI4Myw5MCBAQCBERUZVTihyZW1vdmVfbm9uY29tbWVudHMsKHNyYyxkc3Qp
LAogCWVsc2UgaWR4Kys7CiAgICAgfQogfQotLyogdHVybiBmb29iYXIgbmFtZShzdHVmZik7IGlu
dG8gZm9vYmFyIEVYRlVOKG5hbWUsKHN0dWZmKSk7CiAKKy8qIHR1cm4gZm9vYmFyIG5hbWUoc3R1
ZmYpOyBpbnRvIGZvb2JhciBFWEZVTihuYW1lLChzdHVmZikpOwogICovCi0KLXN0YXRpYyB2b2lk
Ci1ERUZVTl9WT0lEKGV4ZnVuc3R1ZmYpCitzdGF0aWMgdm9pZCBleGZ1bnN0dWZmKHZvaWQpCiB7
CiAgICAgdW5zaWduZWQgaW50IG9wZW5wOwogICAgIHVuc2lnbmVkIGludCBmbmFtZTsKICAgICB1
bnNpZ25lZCBpbnQgaWR4OwogICAgIHN0cmluZ190eXBlIG91dDsKICAgICBpbml0X3N0cmluZygm
b3V0KTsKLSAgICAKIAogICAgIC8qIG1ha2Ugc3VyZSB0aGF0IGl0J3Mgbm90IGFscmVhZHkgZXhm
dW5lZCAqLwotICAgIGlmKGZpbmQodG9zLCJFWEZVTiIpIHx8IGZpbmQodG9zLCJQUk9UTyIpIHx8
ICFmaW5kKHRvcywiKCIpKSB7Ci0JICAgIGNhdHN0cigmb3V0LHRvcyk7Ci0JfQotICAgIGVsc2Ug
CisgICAgaWYgKGZpbmQodG9zLCJFWEZVTiIpIHx8IGZpbmQodG9zLCJQUk9UTyIpIHx8ICFmaW5k
KHRvcywiKCIpKSB7CisJY2F0c3RyKCZvdXQsdG9zKTsKKyAgICB9CisgICAgZWxzZQogICAgIHsK
LQkKIAkvKkZpbmQgdGhlIG9wZW4gcGFyZW4qLwotCWZvciAob3BlbnAgPSAwOyBhdCh0b3MsIG9w
ZW5wKSAhPSAnKCcgICYmIGF0KHRvcyxvcGVucCk7IG9wZW5wKyspCi0JIDsKKwlmb3IgKG9wZW5w
ID0gMDsgYXQodG9zLG9wZW5wKSAhPSAnKCcgJiYgYXQodG9zLG9wZW5wKTsgb3BlbnArKykKKwkg
ICA7CiAKIAlmbmFtZSA9IG9wZW5wOwogCS8qIFN0ZXAgYmFjayB0byB0aGUgZm5hbWUgKi8KIAlm
bmFtZS0tOwotCXdoaWxlIChmbmFtZSAmJiBpc3NwYWNlKGF0KHRvcywgZm5hbWUpKSkKLQkgZm5h
bWUgLS07CisJd2hpbGUgKGZuYW1lICYmIGlzc3BhY2UoYXQodG9zLGZuYW1lKSkpCisJICAgIGZu
YW1lIC0tOwogCXdoaWxlIChmbmFtZSAmJiAhaXNzcGFjZShhdCh0b3MsZm5hbWUpKSAmJiBhdCh0
b3MsZm5hbWUpICE9ICcqJykKLQkgZm5hbWUtLTsKKwkgICAgZm5hbWUtLTsKIAogCWZuYW1lKys7
Ci0JCi0JZm9yIChpZHggPSAwOyBpZHggPCBmbmFtZTsgaWR4KyspIAorCisJZm9yIChpZHggPSAw
OyBpZHggPCBmbmFtZTsgaWR4KyspCiAJewogCSAgICBjYXRjaGFyKCZvdXQsIGF0KHRvcyxpZHgp
KTsKIAl9Ci0gICAgCisKIAljYXR0ZXh0KCZvdXQsIkVYRlVOKCIpOwotCWZvciAoaWR4ID0gZm5h
bWU7IGlkeCA8IG9wZW5wOyBpZHgrKykgCisJZm9yIChpZHggPSBmbmFtZTsgaWR4IDwgb3BlbnA7
IGlkeCsrKQogCXsKIAkgICAgY2F0Y2hhcigmb3V0LCBhdCh0b3MsaWR4KSk7CiAJfQogCWNhdHRl
eHQoJm91dCwiLCAiKTsKLQl3aGlsZSAoYXQodG9zLGlkeCkgJiYgYXQodG9zLGlkeCkgIT0nOycp
IAorCXdoaWxlIChhdCh0b3MsaWR4KSAmJiBhdCh0b3MsaWR4KSAhPSc7JykKIAl7Ci0JICAgIGNh
dGNoYXIoJm91dCwgYXQodG9zLCBpZHgpKTsKKwkgICAgY2F0Y2hhcigmb3V0LCBhdCh0b3MsaWR4
KSk7CiAJICAgIGlkeCsrOwogCX0KIAljYXR0ZXh0KCZvdXQsIik7XG4iKTsKICAgICB9Ci0gICAg
b3ZlcndyaXRlX3N0cmluZyh0b3MsICZvdXQpOyAgICAKKyAgICBvdmVyd3JpdGVfc3RyaW5nKHRv
cywgJm91dCk7CiAgICAgcGMrKzsKLSAgICAKIH0KIAogCi0KIC8qIHR1cm4geyoKICAgIGFuZCAq
fSBpbnRvIGNvbW1lbnRzICovCiAKLVdPUkQodHJhbnNsYXRlY29tbWVudHMpCitzdGF0aWMgdm9p
ZCB0cmFuc2xhdGVjb21tZW50cyh2b2lkKQogewogICAgIHVuc2lnbmVkIGludCBpZHggPSAwOwog
ICAgIHN0cmluZ190eXBlIG91dDsKICAgICBpbml0X3N0cmluZygmb3V0KTsKLSAgICAKLSAgICB3
aGlsZSAoYXQodG9zLCBpZHgpKSAKKworICAgIHdoaWxlIChhdCh0b3MsaWR4KSkKICAgICB7Ci0J
aWYgKGF0KHRvcyxpZHgpID09ICd7JyAmJiBhdCh0b3MsaWR4KzEpID09JyonKSAKKwlpZiAoYXQo
dG9zLGlkeCkgPT0gJ3snICYmIGF0KHRvcyxpZHgrMSkgPT0nKicpCiAJewogCSAgICBjYXR0ZXh0
KCZvdXQsIgkvKiIpOwotCSAgICBpZHgrPTI7CisJICAgIGlkeCArPSAyOwogCX0KLQllbHNlIGlm
IChhdCh0b3MsaWR4KSA9PSAnKicgJiYgYXQodG9zLGlkeCsxKSA9PSd9JykgCisJZWxzZSBpZiAo
YXQodG9zLGlkeCkgPT0gJyonICYmIGF0KHRvcyxpZHgrMSkgPT0nfScpCiAJewogCSAgICBjYXR0
ZXh0KCZvdXQsIiovIik7Ci0JICAgIGlkeCs9MjsKKwkgICAgaWR4ICs9IDI7CiAJfQotCWVsc2Ug
IAorCWVsc2UKIAl7Ci0JICAgIGNhdGNoYXIoJm91dCwgYXQodG9zLCBpZHgpKTsKKwkgICAgY2F0
Y2hhcigmb3V0LCBhdCh0b3MsaWR4KSk7CiAJICAgIGlkeCsrOwogCX0KICAgICB9CiAKLQogICAg
IG92ZXJ3cml0ZV9zdHJpbmcodG9zLCAmb3V0KTsKLSAgICAKICAgICBwYysrOwotICAgIAogfQog
CiAvKiBmaW5kIHNvbWV0aGluZyBsaWtlCkBAIC00NTYsMzYgKzM3NSwzMiBAQCBXT1JEKHRyYW5z
bGF0ZWNvbW1lbnRzKQogCiAgICAgIGludG8KICAgICAgbWVyZ2Ugd2l0aCB3b3JkcyBvbiB0b3Mg
YW5kIG91dHB1dCB0aGVtIHRvIHN0ZGVycm9yCi0KICovCi1XT1JEKHF1aWNrcmVmKQorc3RhdGlj
IHZvaWQgcXVpY2tyZWYodm9pZCkKIHsKICAgc3RyaW5nX3R5cGUgKm5vcyA9IHRvcy0xOwotICB1
bnNpZ25lZCBpbnQgc2Nhbj0wOwogICB1bnNpZ25lZCBpbnQgbm9zc2NhbiA9IDA7CiAgIHVuc2ln
bmVkIGludCBpZHggPSAwOwotICAKLSAgd2hpbGUgKGF0KHRvcywgaWR4KSkgCisKKyAgd2hpbGUg
KGF0KHRvcyxpZHgpKQogICB7CiAgICAgaWYgKGF0KHRvcyxpZHgpID09ICd+JykKICAgICB7CiAg
ICAgICAvKiBTa2lwIHRoZSB3aGl0ZXNwYWNlICovCi0gICAgICB3aGlsZSAoYXQobm9zLCBub3Nz
Y2FuKSA9PSAnICcpCi0gICAgICAgbm9zc2NhbisrOwotICAgIAorICAgICAgd2hpbGUgKGF0KG5v
cyxub3NzY2FuKSA9PSAnICcpCisJbm9zc2NhbisrOworCiAgICAgICAvKiBTdWIgdGhlIG5leHQg
d29yZCBmcm9tIHRoZSBub3MqLwotICAgICAgd2hpbGUgKGF0KG5vcywgbm9zc2NhbikgIT0gJyAn
ICYmCi0JICAgICBhdChub3MsIG5vc3NjYW4pICE9IDApCisgICAgICB3aGlsZSAoYXQobm9zLG5v
c3NjYW4pICE9ICcgJyAmJgorCSAgICAgYXQobm9zLG5vc3NjYW4pICE9IDApCiAgICAgICB7Ci0J
ZnByaW50ZihzdGRlcnIsICIlYyIsIGF0KG5vcywgbm9zc2NhbikpOworCWZwcmludGYoc3RkZXJy
LCAiJWMiLCBhdChub3Msbm9zc2NhbikpOwogCW5vc3NjYW4rKzsKICAgICAgIH0KICAgICB9Ci0g
IAotICAgIGVsc2UgCisgICAgZWxzZQogICAgIHsKLSAgICAgIGZwcmludGYoc3RkZXJyLCIlYyIs
IGF0KHRvcywgaWR4KSk7Ci0gICAgCisgICAgICBmcHJpbnRmKHN0ZGVyciwiJWMiLCBhdCh0b3Ms
aWR4KSk7CiAgICAgfQogICAgIGlkeCsrOwogICB9CkBAIC00OTQsMTIzICs0MDksODIgQEAgV09S
RChxdWlja3JlZikKICAgZGVsZXRlX3N0cmluZyhub3MpOwogICB0b3MtPTI7CiAgIHBjKys7Ci0g
IAotfQotCi0vKiB0dXJuIGV2ZXJ5dGhpbmcgbm90IHN0YXJ0aW5nIHdpdGggYSAuIGludG8gYSBj
b21tZW50ICovCi0KLVdPUkQobWFuZ2xlY29tbWVudHMpCi17Ci0gICAgdW5zaWduZWQgaW50IGlk
eCA9IDA7Ci0gICAgc3RyaW5nX3R5cGUgb3V0OwotICAgIGluaXRfc3RyaW5nKCZvdXQpOwotICAg
IAotICAgIHdoaWxlIChhdCh0b3MsIGlkeCkpIAotICAgIHsKLQlpZiAoYXQodG9zLGlkeCkgPT0g
J1xuJyAmJiBhdCh0b3MsaWR4KzEpID09JyonKSAKLQl7Ci0JICAgIGNhdHRleHQoJm91dCwiCS8q
Iik7Ci0JICAgIGlkeCs9MjsKLQl9Ci0JZWxzZSBpZiAoYXQodG9zLGlkeCkgPT0gJyonICYmIGF0
KHRvcyxpZHgrMSkgPT0nfScpIAotCXsKLQkgICAgY2F0dGV4dCgmb3V0LCIqLyIpOwotCSAgICBp
ZHgrPTI7Ci0JfQotCWVsc2UgIAotCXsKLQkgICAgY2F0Y2hhcigmb3V0LCBhdCh0b3MsIGlkeCkp
OwotCSAgICBpZHgrKzsKLQl9Ci0gICAgfQotCi0KLSAgICBvdmVyd3JpdGVfc3RyaW5nKHRvcywg
Jm91dCk7Ci0gICAgCi0gICAgcGMrKzsKLSAgICAKIH0KIAogLyogTW9kIHRvcyBzbyB0aGF0IG9u
bHkgbGluZXMgd2l0aCBsZWFkaW5nIGRvdHMgcmVtYWluICovCi1zdGF0aWMgdm9pZAotREVGVU5f
Vk9JRChvdXRwdXRkb3RzKQorc3RhdGljIHZvaWQgb3V0cHV0ZG90cyh2b2lkKQogewogICAgIHVu
c2lnbmVkIGludCBpZHggPSAwOwogICAgIHN0cmluZ190eXBlIG91dDsKICAgICBpbml0X3N0cmlu
Zygmb3V0KTsKLSAgICAKLSAgICB3aGlsZSAoYXQodG9zLCBpZHgpKSAKKworICAgIHdoaWxlIChh
dCh0b3MsaWR4KSkKICAgICB7Ci0JaWYgKGF0KHRvcywgaWR4KSA9PSAnXG4nICYmIGF0KHRvcywg
aWR4KzEpID09ICcuJykgCisJaWYgKGF0KHRvcyxpZHgpID09ICdcbicgJiYgYXQodG9zLGlkeCsx
KSA9PSAnLicpCiAJewogCSAgICBpZHggKz0gMjsKLQkgICAgCi0JICAgIHdoaWxlIChhdCh0b3Ms
IGlkeCkgJiYgYXQodG9zLCBpZHgpIT0nXG4nKQorCSAgICB3aGlsZSAoYXQodG9zLGlkeCkgJiYg
YXQodG9zLGlkeCkgIT0nXG4nKQogCSAgICB7Ci0JCWlmIChhdCh0b3MsaWR4KSA9PSAneycgJiYg
YXQodG9zLGlkeCsxKSA9PScqJykgCisJCWlmIChhdCh0b3MsaWR4KSA9PSAneycgJiYgYXQodG9z
LGlkeCsxKSA9PScqJykKIAkJewogCQkgICAgY2F0dGV4dCgmb3V0LCIgLyoiKTsKLQkJICAgIGlk
eCs9MjsKKwkJICAgIGlkeCArPSAyOwogCQl9Ci0JCWVsc2UgaWYgKGF0KHRvcyxpZHgpID09ICcq
JyAmJiBhdCh0b3MsaWR4KzEpID09J30nKSAKKwkJZWxzZSBpZiAoYXQodG9zLGlkeCkgPT0gJyon
ICYmIGF0KHRvcyxpZHgrMSkgPT0nfScpCiAJCXsKIAkJICAgIGNhdHRleHQoJm91dCwiKi8iKTsK
LQkJICAgIGlkeCs9MjsKKwkJICAgIGlkeCArPSAyOwogCQl9Ci0JCWVsc2UgIAorCQllbHNlCiAJ
CXsKLQkJICAgIGNhdGNoYXIoJm91dCwgYXQodG9zLCBpZHgpKTsKKwkJICAgIGNhdGNoYXIoJm91
dCwgYXQodG9zLGlkeCkpOwogCQkgICAgaWR4Kys7CiAJCX0KIAkgICAgfQogCSAgICBjYXRjaGFy
KCZvdXQsJ1xuJyk7CiAJfQotCWVsc2UgCisJZWxzZQogCXsKIAkgICAgaWR4Kys7CiAJfQotICAg
IH0JCisgICAgfQogCiAgICAgb3ZlcndyaXRlX3N0cmluZyh0b3MsICZvdXQpOwogICAgIHBjKys7
Ci0gICAgCiB9CiAKIC8qIEZpbmQgbGluZXMgc3RhcnRpbmcgd2l0aCAuIGFuZCB8IGFuZCBwdXQg
ZXhhbXBsZSBhcm91bmQgdGhlbSBvbiB0b3MKLSAgIHR1cm4gCisgICB0dXJuCiAgICB7KiAgaW50
byBvcGVuIGNvbW1lbnQgYW5kICp9IGludG8gY2xvc2UgY29tbWVudAogICAgZXNjYXBlIGN1cmxp
ZXMKLSAgIAogKi8KLVdPUkQoY291cmllcml6ZSkKK3N0YXRpYyB2b2lkIGNvdXJpZXJpemUodm9p
ZCkKIHsKICAgICBzdHJpbmdfdHlwZSBvdXQ7CiAgICAgdW5zaWduZWQgaW50IGlkeCA9IDA7Ci0g
ICAgCisKICAgICBpbml0X3N0cmluZygmb3V0KTsKLSAgICAKLSAgICB3aGlsZSAoYXQodG9zLCBp
ZHgpKSAKKworICAgIHdoaWxlIChhdCh0b3MsaWR4KSkKICAgICB7Ci0JaWYgKGF0KHRvcywgaWR4
KSA9PSAnXG4nIAotCSAgICAmJiAoYXQodG9zLCBpZHggKzEgKSA9PSAnLicKLQkJfHwgYXQodG9z
LGlkeCsxKSA9PSAnfCcpKSAKKwlpZiAoYXQodG9zLGlkeCkgPT0gJ1xuJyAmJgorCSAgICAoYXQo
dG9zLGlkeCsxKSA9PSAnLicgfHwgYXQodG9zLGlkeCsxKSA9PSAnfCcpKQogCXsKIAkgICAgY2F0
dGV4dCgmb3V0LCJcbkBzbWFsbGV4YW1wbGVcbiIpOwotCSAgICBkbyAKKwkgICAgZG8KIAkgICAg
ewogCQlpZHggKz0gMjsKLQkJCi0JCXdoaWxlIChhdCh0b3MsIGlkeCkgJiYgYXQodG9zLCBpZHgp
IT0nXG4nKQorCQl3aGlsZSAoYXQodG9zLGlkeCkgJiYgYXQodG9zLGlkeCkhPSdcbicpCiAJCXsK
LQkJICAgIGlmIChhdCh0b3MsaWR4KT09J3snICYmIGF0KHRvcyxpZHgrMSkgPT0nKicpIAorCQkg
ICAgaWYgKGF0KHRvcyxpZHgpPT0neycgJiYgYXQodG9zLGlkeCsxKSA9PScqJykKIAkJICAgIHsK
IAkJCWNhdHRleHQoJm91dCwiIC8qIik7Ci0JCQlpZHgrPTI7CisJCQlpZHggKz0gMjsKIAkJICAg
IH0KLQkJICAgIGVsc2UgaWYgKGF0KHRvcyxpZHgpPT0nKicgJiYgYXQodG9zLGlkeCsxKSA9PSd9
JykgCisJCSAgICBlbHNlIGlmIChhdCh0b3MsaWR4KT09JyonICYmIGF0KHRvcyxpZHgrMSkgPT0n
fScpCiAJCSAgICB7CiAJCQljYXR0ZXh0KCZvdXQsIiovIik7Ci0JCQlpZHgrPTI7CisJCQlpZHgg
Kz0gMjsKIAkJICAgIH0KIAkgICAgICAgICAgICBlbHNlIGlmIChhdCh0b3MsaWR4KSA9PSAneycp
CiAJCSAgICB7CkBAIC02MjIsMzQgKzQ5NiwzMSBAQCBXT1JEKGNvdXJpZXJpemUpCiAJCQljYXR0
ZXh0KCZvdXQsIkB9Iik7CiAJCQlpZHgrKzsKIAkJICAgIH0KLQkJICAgIGVsc2UgCisJCSAgICBl
bHNlCiAJCSAgICB7Ci0JCQljYXRjaGFyKCZvdXQsIGF0KHRvcywgaWR4KSk7CisJCQljYXRjaGFy
KCZvdXQsIGF0KHRvcyxpZHgpKTsKIAkJCWlkeCsrOwogCQkgICAgfQotCQkgICAgCiAJCX0KIAkJ
Y2F0Y2hhcigmb3V0LCdcbicpOwotCSAgICB9ICAKLQkgICAgd2hpbGUgKGF0KHRvcywgaWR4KSA9
PSAnXG4nIAotCQkgICAmJiAoYXQodG9zLCBpZHgrMSkgPT0gJy4nKQotCQkgICB8fCAoYXQodG9z
LGlkeCsxKSA9PSAnfCcpKTsKKwkgICAgfQorCSAgICB3aGlsZSAoYXQodG9zLGlkeCkgPT0gJ1xu
JworCQkgICAmJiAoKGF0KHRvcyxpZHgrMSkgPT0gJy4nKSB8fCAoYXQodG9zLGlkeCsxKSA9PSAn
fCcpKSk7CisKIAkgICAgY2F0dGV4dCgmb3V0LCJAZW5kIHNtYWxsZXhhbXBsZSIpOwogCX0KLQll
bHNlIAotCXsgICAgCi0JICAgIGNhdGNoYXIoJm91dCwgYXQodG9zLCBpZHgpKTsKKwllbHNlCisJ
eworCSAgICBjYXRjaGFyKCZvdXQsIGF0KHRvcyxpZHgpKTsKIAkgICAgaWR4Kys7CiAJfQotICAg
IH0gICAgCisgICAgfQogCiAgICAgb3ZlcndyaXRlX3N0cmluZyh0b3MsICZvdXQpOwogICAgIHBj
Kys7Ci0KLSAgICAKIH0KIAotLyogCisvKgogICAgTysgIGVtaXQgQGl0ZW1pemUgQGJ1bGxldAog
ICAgT08gIGVtaXQgQGl0ZW0KICAgIE8tICBlbWl0IEBlbmQgaXRlbWl6ZQpAQCAtNjU4LDY0ICs1
MjksNTggQEAgV09SRChjb3VyaWVyaXplKQogICAgb28gIEBpdGVtCiAgICBvLSAgZW1pdCBAZW5k
IHRhYmxlCiAqLwotCi0KLVdPUkQoYnVsbGV0aXplKQorc3RhdGljIHZvaWQgYnVsbGV0aXplKHZv
aWQpCiB7CiAgIHVuc2lnbmVkIGludCBpZHggPSAwOwotICBpbnQgb24gPSAwOwogICBzdHJpbmdf
dHlwZSBvdXQ7CiAgIGluaXRfc3RyaW5nKCZvdXQpOwotICAgIAotICB3aGlsZSAoYXQodG9zLCBp
ZHgpKSB7Ci0gICAgICBpZiAoYXQodG9zLCBpZHgpID09ICdAJyAmJgotCSAgYXQodG9zLCBpZHgr
MSkgPT0gJyonKSAKKworICB3aGlsZSAoYXQodG9zLGlkeCkpIHsKKyAgICAgIGlmIChhdCh0b3Ms
aWR4KSAgID09ICdAJyAmJgorCSAgYXQodG9zLGlkeCsxKSA9PSAnKicpCiAgICAgICB7CiAJY2F0
dGV4dCgmb3V0LCIqIik7Ci0JaWR4Kz0yOworCWlkeCArPSAyOwogICAgICAgfQotCQogICAgICAg
ZWxzZQotICAgICAgIGlmIChhdCh0b3MsIGlkeCkgPT0gJ1xuJyAmJiAgYXQodG9zLCBpZHgrMSkg
PT0gJ28nKQorICAgICAgIGlmIChhdCh0b3MsaWR4KSA9PSAnXG4nICYmICBhdCh0b3MsaWR4KzEp
ID09ICdvJykKICAgICAgICB7CiAJIGlmIChhdCh0b3MsaWR4KzIpID09ICcrJykgewogCSAgICAg
Y2F0dGV4dCgmb3V0LCJcbkB0YWJsZSBAY29kZVxuIik7Ci0JICAgICBpZHgrPTM7CisJICAgICBp
ZHggKz0gMzsKIAkgICB9CiAJIGVsc2UgaWYgKGF0KHRvcyxpZHgrMikgPT0gJy0nKSB7CiAJICAg
ICBjYXR0ZXh0KCZvdXQsIlxuQGVuZCB0YWJsZVxuIik7Ci0JICAgICBpZHgrPTM7CisJICAgICBp
ZHggKz0gMzsKIAkgICB9CiAJIGVsc2UgaWYgKGlzc3BhY2UoYXQodG9zLGlkeCsyKSkpIHsKIAkg
ICAgIGNhdHRleHQoJm91dCwiXG5AaXRlbSAiKTsKLQkgICAgIGlkeCs9MzsKKwkgICAgIGlkeCAr
PSAzOwogCSAgIH0KIAkgZWxzZSB7Ci0JICAgICBjYXRjaGFyKCZvdXQsIGF0KHRvcywgaWR4KSk7
CisJICAgICBjYXRjaGFyKCZvdXQsIGF0KHRvcyxpZHgpKTsKIAkgICAgIGlkeCsrOwogCSAgIH0K
ICAgICAgICB9Ci0gICAgICAKICAgICAgICBlbHNlCi0JaWYgKGF0KHRvcywgaWR4KSA9PSAnXG4n
ICYmICBhdCh0b3MsIGlkeCsxKSA9PSAnTycpCisJaWYgKGF0KHRvcyxpZHgpID09ICdcbicgJiYg
IGF0KHRvcyxpZHgrMSkgPT0gJ08nKQogCXsKIAkgIGlmIChhdCh0b3MsaWR4KzIpID09ICcrJykg
ewogCSAgICAgIGNhdHRleHQoJm91dCwiXG5AaXRlbWl6ZSBAYnVsbGV0XG4iKTsKLQkgICAgICBp
ZHgrPTM7Ci0JICAgIH0KLQorCSAgICAgIGlkeCArPSAzOworCSAgfQogCSAgZWxzZSBpZiAoYXQo
dG9zLGlkeCsyKSA9PSAnLScpIHsKIAkgICAgICBjYXR0ZXh0KCZvdXQsIlxuQGVuZCBpdGVtaXpl
XG4iKTsKLQkgICAgICBpZHgrPTM7Ci0JICAgIH0KKwkgICAgICBpZHggKz0gMzsKKwkgIH0KIAkg
IGVsc2UgewotCSAgICAgIGNhdGNoYXIoJm91dCwgYXQodG9zLCBpZHgpKTsKKwkgICAgICBjYXRj
aGFyKCZvdXQsIGF0KHRvcyxpZHgpKTsKIAkgICAgICBpZHgrKzsKLQkgICAgfQotCX0JICAgICAg
CisJICB9CisJfQogCWVsc2UKIAl7Ci0JICBjYXRjaGFyKCZvdXQsIGF0KHRvcywgaWR4KSk7CisJ
ICBjYXRjaGFyKCZvdXQsIGF0KHRvcyxpZHgpKTsKIAkgIGlkeCsrOwogCX0KICAgICB9CkBAIC03
MjMsMTYyICs1ODgsMTM2IEBAIFdPUkQoYnVsbGV0aXplKQogICBkZWxldGVfc3RyaW5nKHRvcyk7
CiAgICp0b3MgPSBvdXQ7CiAgIHBjKys7Ci0gICAgCiB9CiAKLS8qIFR1cm4gPDxmb28+PiBpbnRv
IEBjb2Rle2Zvb30gaW4gcGxhY2UgYXQgVE9TIAorLyogVHVybiA8PGZvbz4+IGludG8gQGNvZGV7
Zm9vfSBpbiBwbGFjZSBhdCBUT1MKICAgIFR1cm4gPFtmb29dPiBpbnRvIEB2YXJ7Zm9vfSBpbiBw
bGFjZSBhdCBUT1MKICAgIG5lc3QgdGhlbSB0b28gIQotCiAqLwotICAgCi0KLVdPUkQoZG9fZmFu
Y3lfc3R1ZmYpCi0geworc3RhdGljIHZvaWQgZG9fZmFuY3lfc3R1ZmYodm9pZCkKK3sKICAgICB1
bnNpZ25lZCBpbnQgaWR4ID0gMDsKICAgICBzdHJpbmdfdHlwZSBvdXQ7CisKICAgICBpbml0X3N0
cmluZygmb3V0KTsKLSAgICB3aGlsZSAoYXQodG9zLCBpZHgpKSAKKyAgICB3aGlsZSAoYXQodG9z
LGlkeCkpCiAgICAgewotCWlmIChhdCh0b3MsIGlkeCkgPT0gJzwnIAotCSAgICAmJiBhdCh0b3Ms
IGlkeCsxKSA9PSAnPCcKLQkgICAgJiYgKCFpc3NwYWNlKGF0KHRvcyxpZHggKyAyKSkgfHwgYXQo
dG9zLGlkeCszKSA9PSAnPicpKSAKKwlpZiAoYXQodG9zLGlkeCkgPT0gJzwnICYmIGF0KHRvcyxp
ZHgrMSkgPT0gJzwnICYmCisJICAgICghaXNzcGFjZShhdCh0b3MsaWR4KzIpKSB8fCBhdCh0b3Ms
aWR4KzMpID09ICc+JykpCiAJewogCSAgICAvKiBUaGlzIHF1YWxpZmllcyBhcyBhIDw8IHN0YXJ0
dXAgKi8KLQkgICAgaWR4ICs9MjsKKwkgICAgaWR4ICs9IDI7CiAJICAgIGNhdHRleHQoJm91dCwi
QGNvZGV7Iik7Ci0JICB9Ci0JCi0JZWxzZSAJaWYgKGF0KHRvcywgaWR4KSA9PSAnPCcgCi0JICAg
ICYmIGF0KHRvcywgaWR4KzEpID09ICdbJwotCSAgICAmJiAhaXNzcGFjZShhdCh0b3MsaWR4ICsg
MikpKSAKKwl9CisJZWxzZSBpZiAoYXQodG9zLGlkeCkgICA9PSAnPCcgJiYKKwkJIGF0KHRvcyxp
ZHgrMSkgPT0gJ1snICYmCisJCSAhaXNzcGFjZShhdCh0b3MsaWR4KzIpKSkKIAl7CiAJICAgIC8q
IFRoaXMgcXVhbGlmaWVzIGFzIGEgPFsgc3RhcnR1cCAqLwotCSAgICBpZHggKz0yOworCSAgICBp
ZHggKz0gMjsKIAkgICAgY2F0dGV4dCgmb3V0LCJAdmFyeyIpOwotCSAgfQotCWVsc2UgaWYgKGF0
KHRvcywgaWR4KSA9PSAnPicgCi0JCSAmJiBhdCh0b3MsaWR4KzEpID09Jz4nKSAKKwl9CisJZWxz
ZSBpZiAoYXQodG9zLGlkeCkgPT0gJz4nICYmIGF0KHRvcyxpZHgrMSkgPT0nPicpCiAJewotCSAg
CiAJICAgIGNhdHRleHQoJm91dCwifSIpOwotCSAgICBpZHgrPTI7CisJICAgIGlkeCArPSAyOwog
CX0KLQllbHNlIGlmIChhdCh0b3MsIGlkeCkgPT0gJ10nIAotCQkgJiYgYXQodG9zLGlkeCsxKSA9
PSc+JykgCisJZWxzZSBpZiAoYXQodG9zLGlkeCkgPT0gJ10nICYmIGF0KHRvcyxpZHgrMSkgPT0n
PicpCiAJewogCSAgICBjYXR0ZXh0KCZvdXQsIn0iKTsKLQkgICAgaWR4Kz0yOworCSAgICBpZHgg
Kz0gMjsKIAl9Ci0JZWxzZSAKKwllbHNlCiAJewotCSAgICBjYXRjaGFyKCZvdXQsIGF0KHRvcywg
aWR4KSk7CisJICAgIGNhdGNoYXIoJm91dCwgYXQodG9zLGlkeCkpOwogCSAgICBpZHgrKzsKIAl9
CiAgICAgfQogICAgIGRlbGV0ZV9zdHJpbmcodG9zKTsKICAgICAqdG9zID0gb3V0OwogICAgIHBj
Kys7Ci0gICAgCiB9CisKIC8qIEEgY29tbWFuZCBpcyBhbGwgdXBwZXIgY2FzZSxhbmQgYWxvbmUg
b24gYSBsaW5lICovCi1zdGF0aWMgaW50IAotREVGVU4oIGlzY29tbWFuZCwocHRyLCBpZHgpLAot
ICAgICAgc3RyaW5nX3R5cGUgKnB0ciBBTkQKLSAgICAgIHVuc2lnbmVkIGludCBpZHgpCitzdGF0
aWMgaW50IGlzY29tbWFuZChzdHJpbmdfdHlwZSAqcywgdW5zaWduZWQgaW50IGlkeCkKIHsKICAg
ICB1bnNpZ25lZCBpbnQgbGVuID0gMDsKLSAgICB3aGlsZSAoYXQocHRyLGlkeCkpIHsKLQkgICAg
aWYgKGlzdXBwZXIoYXQocHRyLGlkeCkpIHx8IGF0KHB0cixpZHgpID09ICcgJyB8fAotCQlhdChw
dHIsaWR4KSA9PSAnXycpIAorICAgIHdoaWxlIChhdChzLGlkeCkpIHsKKwkgICAgaWYgKGlzdXBw
ZXIoYXQocyxpZHgpKSB8fCBhdChzLGlkeCkgPT0gJyAnIHx8CisJCWF0KHMsaWR4KSA9PSAnXycp
CiAJICAgIHsKLQkgICAgIGxlbisrOwotCSAgICAgaWR4Kys7Ci0JIH0KLQkgICAgZWxzZSBpZihh
dChwdHIsaWR4KSA9PSAnXG4nKQorCQlsZW4rKzsKKwkJaWR4Kys7CisJICAgIH0KKwkgICAgZWxz
ZSBpZihhdChzLGlkeCkgPT0gJ1xuJykKIAkgICAgewotCQlpZiAobGVuID40KSByZXR1cm4gMTsK
KwkJaWYgKGxlbiA+IDQpCisJCSAgICByZXR1cm4gMTsKIAkJcmV0dXJuIDA7CiAJICAgIH0KIAkg
ICAgZWxzZSByZXR1cm4gMDsKIAl9CiAgICAgcmV0dXJuIDA7Ci0KIH0KIAotCi1ERUZVTihjb3B5
X3Bhc3RfbmV3bGluZSwocHRyLCBpZHgsIGRzdCksCi0gICAgICBzdHJpbmdfdHlwZSAqcHRyIEFO
RAotICAgICAgdW5zaWduZWQgaW50IGlkeCBBTkQKLSAgICAgIHN0cmluZ190eXBlICpkc3QpCitz
dGF0aWMgaW50IGNvcHlfcGFzdF9uZXdsaW5lKHN0cmluZ190eXBlICpzLCB1bnNpZ25lZCBpbnQg
aWR4LCBzdHJpbmdfdHlwZSAqZHN0KQogewotICAgIHdoaWxlIChhdChwdHIsIGlkeCkgJiYgYXQo
cHRyLCBpZHgpICE9ICdcbicpIAorICAgIHdoaWxlIChhdChzLGlkeCkgJiYgYXQocyxpZHgpICE9
ICdcbicpIAogICAgIHsKLQljYXRjaGFyKGRzdCwgYXQocHRyLCBpZHgpKTsKKwljYXRjaGFyKGRz
dCwgYXQocyxpZHgpKTsKIAlpZHgrKzsKLQkKLSAgICB9ICAgIAotICAgIGNhdGNoYXIoZHN0LCBh
dChwdHIsIGlkeCkpOworICAgIH0KKyAgICBjYXRjaGFyKGRzdCwgYXQocyxpZHgpKTsKICAgICBp
ZHgrKzsKICAgICByZXR1cm4gaWR4OwotCiB9CiAKLVdPUkQoaWNvcHlfcGFzdF9uZXdsaW5lKQor
c3RhdGljIHZvaWQgaWNvcHlfcGFzdF9uZXdsaW5lKHZvaWQpCiB7CiAgICAgdG9zKys7CiAgICAg
aW5pdF9zdHJpbmcodG9zKTsKLSAgICBpZHggPSBjb3B5X3Bhc3RfbmV3bGluZShwdHIsIGlkeCwg
dG9zKTsKLSAgICBwYysrOwkKKyAgICBwb3MgPSBjb3B5X3Bhc3RfbmV3bGluZShwdHIsIHBvcywg
dG9zKTsKKyAgICBwYysrOwogfQogCiAKIC8qIGluZGVudAogICAgVGFrZSB0aGUgc3RyaW5nIGF0
IHRoZSB0b3Agb2YgdGhlIHN0YWNrLCBkbyBzb21lIHByZXR0eWluZyAqLwogCi0KLQotCi1XT1JE
KGtpbGxfYm9ndXNfbGluZXMpCitzdGF0aWMgdm9pZCBraWxsX2JvZ3VzX2xpbmVzKHZvaWQpCiB7
CiAgICAgaW50IHNsIDsKLSAgICAKLSAgICBpbnQgbmwgPSAwOwogICAgIGludCBpZHggPSAwOwog
ICAgIGludCBjOwotICAgIGludCBkb3QgPSAwICAgIDsKLSAgICAKLSAgICBzdHJpbmdfdHlwZSBv
dXQ7ICAgIAorICAgIGludCBkb3QgPSAwOworCisgICAgc3RyaW5nX3R5cGUgb3V0OwogICAgIGlu
aXRfc3RyaW5nKCZvdXQpOwogICAgIC8qIERyb3AgbGVhZGluZyBubCAqLwogICAgIHdoaWxlIChh
dCh0b3MsaWR4KSA9PSAnXG4nKQotICAgIHsKIAlpZHgrKzsKLSAgICB9CiAgICAgYyA9IGlkeDsK
LSAgICAKKwogICAgIC8qIEZpbmQgdGhlIGxhc3QgY2hhciAqLwogICAgIHdoaWxlIChhdCh0b3Ms
aWR4KSkKLSAgICB7CiAJaWR4Kys7Ci0gICAgfQotICAgIAorCiAgICAgLyogZmluZCB0aGUgbGFz
dCBub24gd2hpdGUgYmVmb3JlIHRoZSBubCAqLwogICAgIGlkeC0tOwotICAgIAorCiAgICAgd2hp
bGUgKGlkeCAmJiBpc3NwYWNlKGF0KHRvcyxpZHgpKSkKLSAgICAgaWR4LS07CisJaWR4LS07CiAg
ICAgaWR4Kys7Ci0gICAgCisKICAgICAvKiBDb3B5IGJ1ZmZlciB1cHRvIGxhc3QgY2hhciwgYnV0
IGJsYW5rIGxpbmVzIGJlZm9yZSBhbmQgYWZ0ZXIKICAgICAgICBkb3RzIGRvbid0IGNvdW50ICov
CiAgICAgc2wgPSAxOwogCiAgICAgd2hpbGUgKGMgPCBpZHgpCiAgICAgewotCWlmIChhdCh0b3Ms
YykgPT0gJ1xuJyAKLQkgICAgJiYgYXQodG9zLGMrMSkgPT0gJ1xuJwotCSAgICAmJiBhdCh0b3Ms
YysyKSA9PSAnLicpIAorCWlmIChhdCh0b3MsYykgICA9PSAnXG4nICYmCisJICAgIGF0KHRvcyxj
KzEpID09ICdcbicgJiYKKwkgICAgYXQodG9zLGMrMikgPT0gJy4nKQogCXsKIAkgICAgLyogSWdu
b3JlIHR3byBsaW5lbGluZXMgYmVmb3JlICBhIGRvdCovCiAJICAgIGMrKzsKQEAgLTg4OCw5ICs3
MjcsOCBAQCBXT1JEKGtpbGxfYm9ndXNfbGluZXMpCiAJICAgIC8qIHJlbWVtYmVyIHRoYXQgdGhp
cyBsaW5lIHN0YXJ0ZWQgd2l0aCBhIGRvdCAqLwogCSAgICBkb3Q9MjsKIAl9Ci0JZWxzZSBpZiAo
YXQodG9zLGMpID09ICdcbicgCi0JCSAmJiBhdCh0b3MsYysxKSA9PSAnXG4nCi0JCSAmJiBkb3Qp
CisJZWxzZSBpZiAoYXQodG9zLGMpICAgPT0gJ1xuJyAmJgorCQkgYXQodG9zLGMrMSkgPT0gJ1xu
JyAmJiBkb3QpCiAJewogCSAgICBjKys7CiAJICAgIC8qIElnbm9yZSB0d28gbmV3bGluZXMgd2hl
biBsYXN0IGxpbmUgd2FzIGRvdCAqLwpAQCAtOTAwLDI0ICs3MzgsMjIgQEAgV09SRChraWxsX2Jv
Z3VzX2xpbmVzKQogCWlmIChhdCh0b3MsYykgPT0gJ1xuJykKIAl7CiAJICAgIHNsID0gMTsKLQkg
ICAgCi0JICAgIGlmIChkb3QgPT0gMilkb3Q9MTtlbHNlIGRvdCA9IDA7CisJICAgIGlmIChkb3Qg
PT0gMikKKwkJZG90ID0gMTsKKwkgICAgZWxzZSBkb3QgPSAwOwogCX0KLQkKLQljKys7CQogCisJ
YysrOwogICAgIH0KLSAgICAKKwogICAgIC8qIEFwcGVuZCBubCovCiAgICAgY2F0Y2hhcigmb3V0
LCAnXG4nKTsKICAgICBwYysrOwogICAgIGRlbGV0ZV9zdHJpbmcodG9zKTsKICAgICAqdG9zID0g
b3V0OwotICAgIAotICAgIAogfQogCi1XT1JEKGluZGVudCkKK3N0YXRpYyB2b2lkIGluZGVudCh2
b2lkKQogewogICAgIHN0cmluZ190eXBlIG91dDsKICAgICBpbnQgdGFiID0gMDsKQEAgLTkyNSw2
MyArNzYxLDU2IEBAIFdPUkQoaW5kZW50KQogICAgIGludCBvbCA9MDsKICAgICBpbml0X3N0cmlu
Zygmb3V0KTsKICAgICB3aGlsZSAoYXQodG9zLGlkeCkpIHsKLQkgICAgc3dpdGNoIChhdCh0b3Ms
aWR4KSkgCi0JICAgIHsKLQkgICAgICBjYXNlICdcbic6Ci0JCWNhdHRleHQoJm91dCwiXG4iKTsK
LQkJaWR4Kys7Ci0JCWlmICh0YWIpIAotCQl7Ci0JCSAgICBjYXR0ZXh0KCZvdXQsIiAgICAiKTsK
LQkJfQotCQlvbCA9IDA7Ci0JCWJyZWFrOwotCSAgICAgIGNhc2UgJygnOgotCQl0YWIrKzsKLQkJ
aWYgKG9sID09IDApCi0JCSAgICBjYXR0ZXh0KCZvdXQsIiAgICIpOwotCQlpZHgrKzsKLQkJY2F0
dGV4dCgmb3V0LCIoIik7Ci0JCW9sID0gMTsKLQkJYnJlYWs7Ci0JICAgICAgY2FzZSAnKSc6Ci0J
CXRhYi0tOwotCQljYXR0ZXh0KCZvdXQsIikiKTsKLQkJaWR4Kys7Ci0JCW9sPTE7Ci0JCQotCQli
cmVhazsKLQkgICAgICBkZWZhdWx0OgotCQljYXRjaGFyKCZvdXQsYXQodG9zLGlkeCkpOwotCQlv
bD0xOwotCQkKLQkJaWR4Kys7Ci0JCWJyZWFrOwotCSAgICB9Ci0JfQkKKwlzd2l0Y2ggKGF0KHRv
cyxpZHgpKSAKKwl7CisJY2FzZSAnXG4nOgorCSAgICBjYXR0ZXh0KCZvdXQsIlxuIik7CisJICAg
IGlkeCsrOworCSAgICBpZiAodGFiKQorCQljYXR0ZXh0KCZvdXQsIiAgICAiKTsKKwkgICAgb2wg
PSAwOworCSAgICBicmVhazsKKwljYXNlICcoJzoKKwkgICAgdGFiKys7CisJICAgIGlmIChvbCA9
PSAwKQorCQljYXR0ZXh0KCZvdXQsIiAgICIpOworCSAgICBpZHgrKzsKKwkgICAgY2F0dGV4dCgm
b3V0LCIoIik7CisJICAgIG9sID0gMTsKKwkgICAgYnJlYWs7CisJY2FzZSAnKSc6CisJICAgIHRh
Yi0tOworCSAgICBjYXR0ZXh0KCZvdXQsIikiKTsKKwkgICAgaWR4Kys7CisJICAgIG9sPTE7CisJ
ICAgIGJyZWFrOworCWRlZmF1bHQ6CisJICAgIGNhdGNoYXIoJm91dCxhdCh0b3MsaWR4KSk7CisJ
ICAgIG9sPTE7CisJICAgIGlkeCsrOworCSAgICBicmVhazsKKwl9CisgICAgfQogCiAgICAgcGMr
KzsKICAgICBkZWxldGVfc3RyaW5nKHRvcyk7CiAgICAgKnRvcyA9IG91dDsKLQogfQogCiAvKiBD
aGFuZ2UgdGhlIFRPUyBzbyB0aGF0IGFsbCB0aGF0IGlzIGxlZnQgaXMgdGhlIHN0dWZmIGluc2lk
ZSB0aGUKLSBmaXJzdCA8PGZvbz4+IC4KKyAgIGZpcnN0IDw8Zm9vPj4KICovCi0KLVdPUkQoZ2V0
X3N0dWZmX2luX2FuZ2xlKQorc3RhdGljIHZvaWQgZ2V0X3N0dWZmX2luX2FuZ2xlKHZvaWQpCiB7
CiAgIHVuc2lnbmVkIGludCBpZHggPSAwOwogICBzdHJpbmdfdHlwZSBvdXQ7CiAgIGluaXRfc3Ry
aW5nKCZvdXQpOwotICAgIAotICB3aGlsZSAoYXQodG9zLCBpZHgpKSAKKworICB3aGlsZSAoYXQo
dG9zLGlkeCkpCiAgICAgewotICAgICAgaWYgKGF0KHRvcyxpZHgpID09ICc8JyAmJiBhdCh0b3Ms
aWR4KzEpID09JzwnKSAKKyAgICAgIGlmIChhdCh0b3MsaWR4KSA9PSAnPCcgJiYgYXQodG9zLGlk
eCsxKSA9PSc8JykKIAl7Ci0JICBpZHgrPTI7Ci0JICAKKwkgIGlkeCArPSAyOwogCSAgd2hpbGUg
KCEoYXQodG9zLGlkeCkgPT0gJz4nICYmIGF0KHRvcyxpZHgrMSkgPT0gJz4nKSkKIAkgICAgewog
CSAgICAgIGNhdGNoYXIoJm91dCwgYXQodG9zLCBpZHgpKTsKQEAgLTk5NCwyMTkgKzgyMywxODYg
QEAgV09SRChnZXRfc3R1ZmZfaW5fYW5nbGUpCiAjaWYgMAogICBjYXRjaGFyKCZvdXQsJ1xuJyk7
CiAjZW5kaWYKLSAgCisKICAgb3ZlcndyaXRlX3N0cmluZyh0b3MsICZvdXQpOwogICBwYysrOwog
fQogCi0KLVdPUkQoZ2V0X3N0dWZmX2luX2NvbW1hbmQpCitzdGF0aWMgdm9pZCBnZXRfc3R1ZmZf
aW5fY29tbWFuZCh2b2lkKQogewogICB0b3MrKzsKICAgaW5pdF9zdHJpbmcodG9zKTsKIAotICB3
aGlsZSAoYXQocHRyLCBpZHgpKSB7Ci0gICAgaWYgKGlzY29tbWFuZChwdHIsIGlkeCkpICBicmVh
azsKLSAgICBpZHggPSAgIGNvcHlfcGFzdF9uZXdsaW5lKHB0ciwgaWR4LCB0b3MpOworICB3aGls
ZSAoYXQocHRyLHBvcykpIHsKKyAgICBpZiAoaXNjb21tYW5kKHB0cixwb3MpKQorCWJyZWFrOwor
ICAgIHBvcyA9IGNvcHlfcGFzdF9uZXdsaW5lKHB0ciwgcG9zLCB0b3MpOwogICB9Ci0gIHBjKys7
ICAgIAorICBwYysrOwogfQogCi1XT1JEKHN3YXApCitzdGF0aWMgdm9pZCBzd2FwKHZvaWQpCiB7
CiAgICAgc3RyaW5nX3R5cGUgdDsKLSAgICAKKwogICAgIHQgPSB0b3NbMF07CiAgICAgdG9zWzBd
ID0gdG9zWy0xXTsKLSAgICB0b3NbLTFdID10OyAKKyAgICB0b3NbLTFdID0gdDsKICAgICBwYysr
OwotICAgIAogfQogCi1XT1JEKGR1cGxpY2F0ZSkKK3N0YXRpYyB2b2lkIGR1cGxpY2F0ZSh2b2lk
KQogewogICAgIHRvcysrOwogICAgIGluaXRfc3RyaW5nKHRvcyk7CiAgICAgY2F0c3RyKHRvcywg
dG9zLTEpOwogICAgIHBjKys7Ci0gICAgCiB9CiAKLQotCi1XT1JEKGljYXRzdHIpCitzdGF0aWMg
dm9pZCBpY2F0c3RyKHZvaWQpCiB7CiAgICAgY2F0c3RyKHRvcy0xLCB0b3MpOwogICAgIGRlbGV0
ZV9zdHJpbmcodG9zKTsKICAgICB0b3MtLTsKICAgICBwYysrOwotICAgIAogfQogCi1XT1JEKHNr
aXBfcGFzdF9uZXdsaW5lKQorc3RhdGljIHZvaWQgc2tpcF9wYXN0X25ld2xpbmUodm9pZCkKIHsK
LSAgICB3aGlsZSAoYXQocHRyLGlkeCkgCi0JICAgJiYgYXQocHRyLGlkeCkgIT0gJ1xuJykKLSAg
ICAgaWR4Kys7Ci0gICAgaWR4Kys7CisgICAgd2hpbGUgKGF0KHB0cixwb3MpICYmCisJICAgYXQo
cHRyLHBvcykgIT0gJ1xuJykKKwlwb3MrKzsKKworICAgIHBvcysrOwogICAgIHBjKys7CiB9CiAK
LQotV09SRChpbnRlcm5hbG1vZGUpCitzdGF0aWMgdm9pZCBpbnRlcm5hbG1vZGUodm9pZCkKIHsK
ICAgICBpbnRlcm5hbF9tb2RlID0gKihpc3ApOwogICAgIGlzcC0tOwogICAgIHBjKys7CiB9CiAK
LVdPUkQobWF5YmVjYXRzdHIpCitzdGF0aWMgdm9pZCBtYXliZWNhdHN0cih2b2lkKQogewotICAg
IGlmIChpbnRlcm5hbF93YW50ZWQgPT0gaW50ZXJuYWxfbW9kZSkgCisgICAgaWYgKGludGVybmFs
X3dhbnRlZCA9PSBpbnRlcm5hbF9tb2RlKQogICAgIHsKIAljYXRzdHIodG9zLTEsIHRvcyk7CiAg
ICAgfQogICAgIGRlbGV0ZV9zdHJpbmcodG9zKTsKICAgICB0b3MtLTsKICAgICBwYysrOwotICAg
IAogfQogCi1jaGFyICoKLURFRlVOKG5leHR3b3JkLChzdHJpbmcsIHdvcmQpLAotICAgICAgY2hh
ciAqc3RyaW5nIEFORAotICAgICAgY2hhciAqKndvcmQpCitzdGF0aWMgY2hhciAqbmV4dHdvcmQo
Y2hhciAqc3RyaW5nLCBjaGFyICoqd29yZCkKIHsKICAgY2hhciAqd29yZF9zdGFydDsKICAgaW50
IGlkeDsKICAgY2hhciAqZHN0OwogICBjaGFyICpzcmM7Ci0gICAgCiAgIGludCBsZW5ndGggPSAw
OwotICAgIAorCiAgIHdoaWxlIChpc3NwYWNlKCpzdHJpbmcpIHx8ICpzdHJpbmcgPT0gJy0nKSB7
Ci0gICAgICBpZiAoKnN0cmluZyA9PSAnLScpIAorICAgICAgaWYgKCpzdHJpbmcgPT0gJy0nKQog
ICAgICAgewotCXdoaWxlICgqc3RyaW5nICYmICpzdHJpbmcgIT0gJ1xuJykgCi0JIHN0cmluZysr
OwotCQkKKwl3aGlsZSAoKnN0cmluZyAmJiAqc3RyaW5nICE9ICdcbicpCisJICBzdHJpbmcrKzsK
ICAgICAgIH0KICAgICAgIGVsc2UgewogCSAgc3RyaW5nKys7Ci0JfQotICAgIH0KLSAgaWYgKCEq
c3RyaW5nKSByZXR1cm4gMDsKLSAgICAKLSAgd29yZF9zdGFydCA9IHN0cmluZzsgICAgCQotICBp
ZiAoKnN0cmluZyA9PSAnIicpIAorICAgICAgfQorICB9CisgIGlmICghKnN0cmluZykgcmV0dXJu
IE5VTEw7CisKKyAgd29yZF9zdGFydCA9IHN0cmluZzsKKyAgaWYgKCpzdHJpbmcgPT0gJyInKQog
ICB7CiAgICAgc3RyaW5nKys7CiAgICAgbGVuZ3RoKys7Ci0JCi0gICAgd2hpbGUgKCpzdHJpbmcg
IT0gJyInKSAKKworICAgIHdoaWxlICgqc3RyaW5nICE9ICciJykKICAgICB7CiAgICAgICBzdHJp
bmcrKzsKICAgICAgIGxlbmd0aCsrOwogICAgIH0KICAgfQotICBlbHNlICAgICAKKyAgZWxzZQog
ICB7Ci0JCi0KLSAgICB3aGlsZSAoIWlzc3BhY2UoKnN0cmluZykpIAorICAgIHdoaWxlICghaXNz
cGFjZSgqc3RyaW5nKSkKICAgICB7CiAgICAgICBzdHJpbmcrKzsKICAgICAgIGxlbmd0aCsrOwog
ICAgIH0KICAgfQotICAgIAorCiAgICp3b3JkID0gbWFsbG9jKGxlbmd0aCArIDEpOwogCiAgIGRz
dCA9ICp3b3JkOwogICBzcmMgPSB3b3JkX3N0YXJ0OwogCi0KLSAgZm9yIChpZHg9IDA7IGlkeCA8
IGxlbmd0aDsgaWR4KyspIAorICBmb3IgKGlkeD0gMDsgaWR4IDwgbGVuZ3RoOyBpZHgrKykKICAg
ewotICAgIAotICAgIGlmIChzcmNbaWR4XSA9PSAnXFwnICYmIHNyY1tpZHgrMV0gPT0gJ24nKSAK
KyAgICBpZiAoc3JjW2lkeF0gPT0gJ1xcJyAmJiBzcmNbaWR4KzFdID09ICduJykKICAgICB7CiAg
ICAgICAqZHN0KysgPSAnXG4nOwogICAgICAgaWR4Kys7Ci0gICAgCiAgICAgfQogICAgIGVsc2Ug
KmRzdCsrID0gc3JjW2lkeF07CiAgIH0KICAgKmRzdCsrID0gMDsKIAorICBpZigqc3RyaW5nKQor
ICAgICByZXR1cm4gc3RyaW5nICsgMTsKKyAgZWxzZQorICAgICByZXR1cm4gTlVMTDsKK30KIAog
CitzdGF0aWMgZGljdF90eXBlICpyb290OwogCi0KLSAgaWYoKnN0cmluZykgICAgCi0gICByZXR1
cm4gc3RyaW5nICsgMTsKLSAgZWxzZSAKLSAgIHJldHVybiAwOwotICAgIAotfQotZGljdF90eXBl
ICpyb290OwotZGljdF90eXBlICoKLURFRlVOKGxvb2t1cF93b3JkLCh3b3JkKSwKLSAgICAgIGNo
YXIgKndvcmQpCi17Ci0gICAgZGljdF90eXBlICpwdHIgPSByb290OwotICAgIHdoaWxlIChwdHIp
IHsKLQkgICAgaWYgKHN0cmNtcChwdHItPndvcmQsIHdvcmQpID09IDApIHJldHVybiBwdHI7Ci0J
ICAgIHB0ciA9IHB0ci0+bmV4dDsKLQkgICAgCi0JIH0KK3N0YXRpYyBkaWN0X3R5cGUgKmxvb2t1
cF93b3JkKGNvbnN0IGNoYXIgKndvcmQpCit7CisgICAgZGljdF90eXBlICpkID0gcm9vdDsKKyAg
ICB3aGlsZSAoZCkgeworCWlmIChzdHJjbXAoZC0+d29yZCwgd29yZCkgPT0gMCkKKwkgICAgcmV0
dXJuIGQ7CisJZCA9IGQtPm5leHQ7CisgICAgfQogICAgIGZwcmludGYoc3RkZXJyLCJDYW4ndCBm
aW5kICVzXG4iLHdvcmQpOwogICAgIHJldHVybiAwOwotICAgIAotICAgIAogfQogCi1zdGF0aWMg
dm9pZCBERUZVTl9WT0lEKHBlcmZvcm0pCitzdGF0aWMgdm9pZCBwZXJmb3JtKHZvaWQpCiB7CiAg
ICAgdG9zID0gc3RhY2s7Ci0gICAgCi0gICAgd2hpbGUgKGF0KHB0ciwgaWR4KSkgewotCSAgICAv
KiBJdCdzIHdvcnRoIGxvb2tpbmcgdGhyb3VnaCB0aGUgY29tbWFuZCBsaXN0ICovCi0JICAgIGlm
IChpc2NvbW1hbmQocHRyLCBpZHgpKQotCSAgICB7Ci0JCXVuc2lnbmVkIGludCBpOwotCQlpbnQg
Zm91bmQgPSAwOwotCi0JCWNoYXIgKm5leHQ7Ci0JCWRpY3RfdHlwZSAqd29yZCA7Ci0JCQotCQko
dm9pZCkJCW5leHR3b3JkKGFkZHIocHRyLCBpZHgpLCAmbmV4dCk7Ci0KLQotCQl3b3JkID0gbG9v
a3VwX3dvcmQobmV4dCk7CiAKKyAgICB3aGlsZSAoYXQocHRyLHBvcykpIHsKKwkvKiBJdCdzIHdv
cnRoIGxvb2tpbmcgdGhyb3VnaCB0aGUgY29tbWFuZCBsaXN0ICovCisJaWYgKGlzY29tbWFuZChw
dHIscG9zKSkKKwl7CisJICAgIGNoYXIgKm5leHQ7CisJICAgIGRpY3RfdHlwZSAqd29yZCA7CiAK
LQkJCisJICAgICh2b2lkKSBuZXh0d29yZChhZGRyKHB0ciwgcG9zKSwgJm5leHQpOworCSAgICB3
b3JkID0gbG9va3VwX3dvcmQobmV4dCk7CiAKLQkJaWYgKHdvcmQpIAotCQl7Ci0JCSAgICBleGVj
KHdvcmQpOwotCQl9Ci0JCWVsc2UKLQkJewotCQkgICAgZnByaW50ZihzdGRlcnIsIndhcm5pbmcs
ICVzIGlzIG5vdCByZWNvZ25pc2VkXG4iLCAgbmV4dCk7Ci0JCSAgICBza2lwX3Bhc3RfbmV3bGlu
ZSgpOwotCQl9Ci0JCQorCSAgICBpZiAod29yZCkKKwkgICAgeworCQlleGVjKHdvcmQpOworCSAg
ICB9CisJICAgIGVsc2UKKwkgICAgeworCQlmcHJpbnRmKHN0ZGVyciwid2FybmluZywgJXMgaXMg
bm90IHJlY29nbmlzZWRcbiIsIG5leHQpOworCQlza2lwX3Bhc3RfbmV3bGluZSgpOwogCSAgICB9
Ci0JICAgIGVsc2Ugc2tpcF9wYXN0X25ld2xpbmUoKTsKLQogCX0KKwllbHNlCisJICAgIHNraXBf
cGFzdF9uZXdsaW5lKCk7CisgICAgfQogfQogCi1kaWN0X3R5cGUgKgotREVGVU4obmV3ZW50cnks
KHdvcmQpLAotICAgICAgY2hhciAqd29yZCkKK3N0YXRpYyBkaWN0X3R5cGUgKm5ld2VudHJ5KGNo
YXIgKndvcmQpCiB7CiAgICAgZGljdF90eXBlICpuZXcgPSAoZGljdF90eXBlICopbWFsbG9jKHNp
emVvZihkaWN0X3R5cGUpKTsKICAgICBuZXctPndvcmQgPSB3b3JkOwpAQCAtMTIxNiwxNCArMTAx
Miw5IEBAIERFRlVOKG5ld2VudHJ5LCh3b3JkKSwKICAgICBuZXctPmNvZGVfbGVuZ3RoID0gMTsK
ICAgICBuZXctPmNvZGVfZW5kID0gMDsKICAgICByZXR1cm4gbmV3OwotICAgIAogfQogCi0KLXVu
c2lnbmVkIGludAotREVGVU4oYWRkX3RvX2RlZmluaXRpb24sKGVudHJ5LCB3b3JkKSwgCi0gICAg
ICBkaWN0X3R5cGUgKmVudHJ5IEFORAotICAgICAgc3RpbnN0X3R5cGUgd29yZCkKK3N0YXRpYyB1
bnNpZ25lZCBpbnQgYWRkX3RvX2RlZmluaXRpb24oZGljdF90eXBlICplbnRyeSwgc3RpbnN0X3R5
cGUgd29yZCkKIHsKICAgICBpZiAoZW50cnktPmNvZGVfZW5kID09IGVudHJ5LT5jb2RlX2xlbmd0
aCkgCiAgICAgewpAQCAtMTIzMywxODYgKzEwMjQsMTQ1IEBAIERFRlVOKGFkZF90b19kZWZpbml0
aW9uLChlbnRyeSwgd29yZCksIAogCQkJICAgICAgIGVudHJ5LT5jb2RlX2xlbmd0aCAqc2l6ZW9m
KHdvcmRfdHlwZSkpOwogICAgIH0KICAgICBlbnRyeS0+Y29kZVtlbnRyeS0+Y29kZV9lbmRdID0g
d29yZDsKLSAgICAKLXJldHVybiAgICAgZW50cnktPmNvZGVfZW5kKys7ICAKLX0KLQotCi0KLQot
CiAKKyAgICByZXR1cm4gZW50cnktPmNvZGVfZW5kKys7Cit9CiAKLXZvaWQKLURFRlVOKGFkZF9p
bnRyaW5zaWMsKG5hbWUsIGZ1bmMpLAotICAgICAgY2hhciAqbmFtZSBBTkQKLSAgICAgIHZvaWQg
KCpmdW5jKSgpKQorc3RhdGljIHZvaWQgYWRkX2ludHJpbnNpYyhjaGFyICpuYW1lLCB2b2lkICgq
ZnVuYykoKSkKIHsKICAgICBkaWN0X3R5cGUgKm5ldyA9IG5ld2VudHJ5KG5hbWUpOwogICAgIGFk
ZF90b19kZWZpbml0aW9uKG5ldywgZnVuYyk7CiAgICAgYWRkX3RvX2RlZmluaXRpb24obmV3LCAw
KTsKIH0KIAotV09SRChwdXNoX2FkZHIpCi17Ci0gICAgCi0KLX0KLQotdm9pZAotREVGVU4oYWRk
X3ZhciwobmFtZSksCi0gICAgICBjaGFyICpuYW1lKQorc3RhdGljIHZvaWQgYWRkX3ZhcihjaGFy
ICpuYW1lKQogewogICAgIGRpY3RfdHlwZSAqbmV3ID0gbmV3ZW50cnkobmFtZSk7CiAgICAgYWRk
X3RvX2RlZmluaXRpb24obmV3LCBwdXNoX251bWJlcik7CiAgICAgYWRkX3RvX2RlZmluaXRpb24o
bmV3LCAoc3RpbnN0X3R5cGUpKCYobmV3LT52YXIpKSk7CiAgICAgYWRkX3RvX2RlZmluaXRpb24o
bmV3LDApOwotICAgIAogfQotICAgICAgCi0KLQotCi12b2lkIAotREVGVU4oY29tcGlsZSwgKHN0
cmluZyksIAotICAgICAgY2hhciAqc3RyaW5nKQogCitzdGF0aWMgdm9pZCBjb21waWxlKGNoYXIg
KnN0cmluZykKIHsKLSAgICBpbnQganN0YWNrW1NUQUNLXTsKLSAgICBpbnQgKmpwdHIgPSBqc3Rh
Y2s7CiAgICAgLyogYWRkIHdvcmRzIHRvIHRoZSBkaWN0aW9uYXJ5ICovCiAgICAgY2hhciAqd29y
ZDsKICAgICBzdHJpbmcgPSBuZXh0d29yZChzdHJpbmcsICZ3b3JkKTsKLSAgICB3aGlsZSAoc3Ry
aW5nICYmICpzdHJpbmcgJiYgd29yZFswXSkgCisgICAgd2hpbGUgKHN0cmluZyAmJiAqc3RyaW5n
ICYmIHdvcmRbMF0pCiAgICAgewogCWlmIChzdHJjbXAod29yZCwidmFyIik9PTApIAogCXsKLSBz
dHJpbmc9bmV4dHdvcmQoc3RyaW5nLCAmd29yZCk7Ci0JICAKKwkgIHN0cmluZz1uZXh0d29yZChz
dHJpbmcsICZ3b3JkKTsKIAkgIGFkZF92YXIod29yZCk7Ci0gc3RyaW5nPW5leHR3b3JkKHN0cmlu
ZywgJndvcmQpOworCSAgc3RyaW5nPW5leHR3b3JkKHN0cmluZywgJndvcmQpOwogCX0KLWVsc2UJ
Ci0JICAgIAorCWVsc2UKIAlpZiAod29yZFswXSA9PSAnOicpCiAJewotCSAgICBkaWN0X3R5cGUg
KnB0cjsKKwkgICAgZGljdF90eXBlICpkOwogCSAgICAvKiBDb21waWxlIGEgd29yZCBhbmQgYWRk
IHRvIGRpY3Rpb25hcnkgKi8KIAkgICAgc3RyaW5nID0gbmV4dHdvcmQoc3RyaW5nLCAmd29yZCk7
Ci0JICAgIAotCSAgICBwdHIgPSBuZXdlbnRyeSh3b3JkKTsKKworCSAgICBkID0gbmV3ZW50cnko
d29yZCk7CiAJICAgIHN0cmluZyA9IG5leHR3b3JkKHN0cmluZywgJndvcmQpOwogCSAgICB3aGls
ZSAod29yZFswXSAhPSAnOycgKSAKIAkgICAgewotCQkgc3dpdGNoICh3b3JkWzBdKSAKLQkJIHsK
LQkJICAgIAotCQkgICAgCi0JCSAgIGNhc2UgJyInOgotCQkgICAgIC8qIGdvdCBhIHN0cmluZywg
ZW1iZWQgbWFnaWMgcHVzaCBzdHJpbmcKKwkJc3dpdGNoICh3b3JkWzBdKQorCQl7CisJCWNhc2Ug
JyInOgorCQkgICAgLyogZ290IGEgc3RyaW5nLCBlbWJlZCBtYWdpYyBwdXNoIHN0cmluZwogCQkJ
ZnVuY3Rpb24gKi8KLQkJICAgICBhZGRfdG9fZGVmaW5pdGlvbihwdHIsIHB1c2hfdGV4dCk7Ci0J
CSAgICAgYWRkX3RvX2RlZmluaXRpb24ocHRyLCAoc3RpbnN0X3R5cGUpKHdvcmQrMSkpOwotCQkg
ICAgIGJyZWFrOwotCQkgICBjYXNlICcwJzoKLQkJICAgY2FzZSAnMSc6Ci0JCSAgIGNhc2UgJzIn
OgotCQkgICBjYXNlICczJzoKLQkJICAgY2FzZSAnNCc6Ci0JCSAgIGNhc2UgJzUnOgotCQkgICBj
YXNlICc2JzoKLQkJICAgY2FzZSAnNyc6Ci0JCSAgIGNhc2UgJzgnOgotCQkgICBjYXNlICc5JzoK
LQkJICAgICAvKiBHb3QgYSBudW1iZXIsIGVtYmVkZCB0aGUgbWFnaWMgcHVzaCBudW1iZXIKKwkJ
ICAgIGFkZF90b19kZWZpbml0aW9uKGQsIHB1c2hfdGV4dCk7CisJCSAgICBhZGRfdG9fZGVmaW5p
dGlvbihkLCAoc3RpbnN0X3R5cGUpKHdvcmQrMSkpOworCQkgICAgYnJlYWs7CisJCWNhc2UgJzAn
OgorCQljYXNlICcxJzoKKwkJY2FzZSAnMic6CisJCWNhc2UgJzMnOgorCQljYXNlICc0JzoKKwkJ
Y2FzZSAnNSc6CisJCWNhc2UgJzYnOgorCQljYXNlICc3JzoKKwkJY2FzZSAnOCc6CisJCWNhc2Ug
JzknOgorCQkgICAgLyogR290IGEgbnVtYmVyLCBlbWJlZGQgdGhlIG1hZ2ljIHB1c2ggbnVtYmVy
CiAJCQlmdW5jdGlvbiAqLwotCQkgICAgIGFkZF90b19kZWZpbml0aW9uKHB0ciwgcHVzaF9udW1i
ZXIpOwotCQkgICAgIGFkZF90b19kZWZpbml0aW9uKHB0ciwgKHN0aW5zdF90eXBlKWF0b2wod29y
ZCkpOwotCQkgICAgIGJyZWFrOwotCQkgICBkZWZhdWx0OgotCQkgICAgIGFkZF90b19kZWZpbml0
aW9uKHB0ciwgY2FsbCk7Ci0JCSAgICAgYWRkX3RvX2RlZmluaXRpb24ocHRyLCAoc3RpbnN0X3R5
cGUpbG9va3VwX3dvcmQod29yZCkpOwotCQkgfQorCQkgICAgYWRkX3RvX2RlZmluaXRpb24oZCwg
cHVzaF9udW1iZXIpOworCQkgICAgYWRkX3RvX2RlZmluaXRpb24oZCwgKHN0aW5zdF90eXBlKShp
bnRwKWF0b2wod29yZCkpOworCQkgICAgYnJlYWs7CisJCWRlZmF1bHQ6CisJCSAgICBhZGRfdG9f
ZGVmaW5pdGlvbihkLCBjYWxsKTsKKwkJICAgIGFkZF90b19kZWZpbml0aW9uKGQsIChzdGluc3Rf
dHlwZSlsb29rdXBfd29yZCh3b3JkKSk7CisJCX0KIAotCQlzdHJpbmcgPSBuZXh0d29yZChzdHJp
bmcsICZ3b3JkKTsJCSAgICAgCisJCXN0cmluZyA9IG5leHR3b3JkKHN0cmluZywgJndvcmQpOwog
CSAgICB9Ci0JICAgIGFkZF90b19kZWZpbml0aW9uKHB0ciwwKTsKKwkgICAgYWRkX3RvX2RlZmlu
aXRpb24oZCwwKTsKIAkgICAgc3RyaW5nID0gbmV4dHdvcmQoc3RyaW5nLCAmd29yZCk7CiAJfQot
CWVsc2UgCisJZWxzZQogCXsKIAkgICAgZnByaW50ZihzdGRlcnIsInN5bnRheCBlcnJvciBhdCAl
c1xuIixzdHJpbmctMSk7Ci0JfQkgICAgCisJfQogICAgIH0KLQogfQogCi0gCi1zdGF0aWMgdm9p
ZCBERUZVTl9WT0lEKGJhbmcpCi17Ci0qKGludHAgKikoKGlzcFswXSkpID0gaXNwWy0xXTsKLWlz
cC09MjsKLXBjKys7CiAKK3N0YXRpYyB2b2lkIGJhbmcodm9pZCkKK3sKKyAgICAqKGludHAgKiko
KGlzcFswXSkpID0gaXNwWy0xXTsKKyAgICBpc3AtPTI7CisgICAgcGMrKzsKIH0KIAotV09SRChh
dHNpZ24pCitzdGF0aWMgdm9pZCBhdHNpZ24odm9pZCkKIHsKICAgICBpc3BbMF0gPSAqKGludHAg
KikoaXNwWzBdKTsKICAgICBwYysrOwogfQogCi1XT1JEKGhlbGxvKQorc3RhdGljIHZvaWQgaGVs
bG8odm9pZCkKIHsKLSAgICAKICAgICBwcmludGYoImhlbGxvXG4iKTsKLSAgICBwYysrOyAgICAK
KyAgICBwYysrOwogfQogCi0KLQotc3RhdGljIHZvaWQgREVGVU4ocmVhZF9pbiwgKHN0ciwgZmls
ZSksIAotCSAgIHN0cmluZ190eXBlICpzdHIgQU5ECi0JCSAgRklMRSAqZmlsZSkKK3N0YXRpYyB2
b2lkIHJlYWRfaW4oc3RyaW5nX3R5cGUgKnN0ciwgRklMRSAqZmlsZSkKIHsKLSAgICBjaGFyIGJ1
ZmZbMTAwMDBdOyAgICAKKyAgICBjaGFyIGJ1ZmZbMTAwMDBdOwogICAgIHVuc2lnbmVkIGludCBy
OwotICAgIGRvIAorCisgICAgZG8KICAgICB7CiAJciA9IGZyZWFkKGJ1ZmYsIDEsIHNpemVvZihi
dWZmKSwgZmlsZSk7CiAJY2F0YnVmKHN0ciwgYnVmZiwgcik7CiAgICAgfQogICAgIHdoaWxlIChy
KTsKICAgICBidWZmWzBdID0gMDsKLSAgICAKKwogICAgIGNhdGJ1ZihzdHIsIGJ1ZmYsMSk7Ci0g
ICAgCiB9CiAKIAotc3RhdGljIHZvaWQgREVGVU5fVk9JRCh1c2FnZSkKK3N0YXRpYyB2b2lkIHVz
YWdlKHZvaWQpCiB7CiAgICAgZnByaW50ZihzdGRlcnIsInVzYWdlOiAtW2R8aXxnXSA8ZmlsZSA+
ZmlsZVxuIik7Ci0gICAgZXhpdCgzMyk7ICAgIAorICAgIGV4aXQoMzMpOwogfQogCi1pbnQgREVG
VU4obWFpbiwoYWMsYXYpLAotaW50IGFjIEFORAotY2hhciAqYXZbXSkKK2ludCBtYWluKGludCBh
YywgY2hhciAqYXZbXSkKIHsKICAgICB1bnNpZ25lZCBpbnQgaTsKLSAgICAKLQorICAgIGludCBl
cnJfZmQ7CiAgICAgc3RyaW5nX3R5cGUgYnVmZmVyOwogICAgIHN0cmluZ190eXBlIHBwdHI7Ci0g
ICAgCiAKICAgICBpbml0X3N0cmluZygmYnVmZmVyKTsKICAgICBpbml0X3N0cmluZygmcHB0cik7
CiAgICAgaW5pdF9zdHJpbmcoc3RhY2srMCk7CiAgICAgdG9zPXN0YWNrKzE7CiAgICAgcHRyID0g
JnBwdHI7Ci0gICAgCisKICAgICBhZGRfaW50cmluc2ljKCJwdXNoX3RleHQiLCBwdXNoX3RleHQp
OwogICAgIGFkZF9pbnRyaW5zaWMoIiEiLCBiYW5nKTsKICAgICBhZGRfaW50cmluc2ljKCJAIiwg
YXRzaWduKTsKQEAgLTE0MzYsNTYgKzExODYsNjMgQEAgY2hhciAqYXZbXSkKICAgICBhZGRfaW50
cmluc2ljKCJpbmRlbnQiLCBpbmRlbnQpOwogICAgIGFkZF9pbnRyaW5zaWMoInF1aWNrcmVmIiwg
cXVpY2tyZWYpOwogICAgIGFkZF9pbnRyaW5zaWMoImludGVybmFsbW9kZSIsIGludGVybmFsbW9k
ZSk7Ci0gICAgCisKICAgICAvKiBQdXQgYSBubCBhdCB0aGUgc3RhcnQgKi8KICAgICBjYXRjaGFy
KCZidWZmZXIsJ1xuJyk7CiAKLSAgICBmb3IgKGk9IDE7IGkgPCBhYzsgaSsrKSAKKyAgICBmb3Ig
KGkgPSAxOyBpIDwgYWM7IGkrKykKICAgICB7CiAgICAgICBpZiAoYXZbaV1bMF0gPT0gJy0nICYm
IGF2W2ldWzFdID09ICdlJykKICAgICAgIHsKLQlpbnQgZXJyX2ZkID0gb3BlbiAoYXZbaSsxXSwg
T19XUk9OTFl8T19DUkVBVHxPX1RSVU5DLCAwNjY2KTsKLQotCWlmIChlcnJfZmQgPCAwIHx8IGR1
cDIgKGVycl9mZCwgMikgPT0gLTEpCi0JICBmcHJpbnRmIChzdGRlcnIsICJDYW4ndCByZWRpcmVj
dCBzdGRlcnIgdG8gJXNcbiIsIGF2W2krMV0pOworCWlmICgrK2kgPT0gYWMpIHVzYWdlKCk7CisJ
ZXJyX2ZkID0gb3BlbiAoYXZbaV0sIE9fV1JPTkxZfE9fQ1JFQVR8T19UUlVOQywgMDY2Nik7CisJ
aWYgKGVycl9mZCA8IDAgfHwgZHVwMihlcnJfZmQsMikgPT0gLTEpCisJICAgIGZwcmludGYgKHN0
ZGVyciwgIkNhbid0IHJlZGlyZWN0IHN0ZGVyciB0byAlc1xuIiwgYXZbaV0pOwogCWlmIChlcnJf
ZmQgPiAwKQotCSAgY2xvc2UgKGVycl9mZCk7CisJICAgIGNsb3NlIChlcnJfZmQpOwogICAgICAg
fQogICAgIH0KLSAgICByZWFkX2luKCZidWZmZXIsIHN0ZGluKTsgCisKKyAgICByZWFkX2luKCZi
dWZmZXIsIHN0ZGluKTsKICAgICByZW1vdmVfbm9uY29tbWVudHMoJmJ1ZmZlciwgcHRyKTsKLSAg
ICBmb3IgKGk9IDE7IGkgPCBhYzsgaSsrKSAKKworICAgIGZvciAoaSA9IDE7IGkgPCBhYzsgaSsr
KQogICAgIHsKIAlpZiAoYXZbaV1bMF0gPT0gJy0nKQogCXsKLQkgICAgaWYgKGF2W2ldWzFdID09
ICdmJykKKwkgICAgaWYgKGF2W2ldWzFdID09ICdlJykKKwkgICAgeworCQkrK2k7IC8qIGhhbmRs
ZWQgYWJvdmUgKi8KKwkgICAgfQorCSAgICBlbHNlIGlmIChhdltpXVsxXSA9PSAnZicpCiAJICAg
IHsKIAkJc3RyaW5nX3R5cGUgYjsKIAkJRklMRSAqZjsKLQkJaW5pdF9zdHJpbmcoJmIpOwogCi0J
CWYgID0gZm9wZW4oYXZbaSsxXSwiciIpOworCQlpZiAoKytpID09IGFjKSB1c2FnZSgpOworCisJ
CWluaXRfc3RyaW5nKCZiKTsKKwkJZiAgPSBmb3BlbihhdltpXSwiciIpOwogCQlpZiAoIWYpIAog
CQl7Ci0JCSAgZnByaW50ZihzdGRlcnIsIkNhbid0IG9wZW4gdGhlIGlucHV0IGZpbGUgJXNcbiIs
YXZbaSsxXSk7CisJCSAgZnByaW50ZihzdGRlcnIsIkNhbid0IG9wZW4gdGhlIGlucHV0IGZpbGUg
JXNcbiIsYXZbaV0pOwogCQkgIHJldHVybiAzMzsKIAkJfQotCQkKLQkJICAKIAkJcmVhZF9pbigm
YiwgZik7CiAJCWNvbXBpbGUoYi5wdHIpOwotCQlwZXJmb3JtKCk7CQorCQlwZXJmb3JtKCk7CiAJ
ICAgIH0KLQkgICAgZWxzZSBpZiAoYXZbaV1bMV0gPT0gJ2knKSAKKwkgICAgZWxzZSBpZiAoYXZb
aV1bMV0gPT0gJ2knKQogCSAgICB7CiAJCWludGVybmFsX3dhbnRlZCA9IDE7CiAJICAgIH0KKwkg
ICAgZWxzZQorCSAgICB7CisJCXVzYWdlKCk7CisJICAgIH0KIAl9CisgICAgfQogCi0gICAgfSAg
ICAgIAogICAgIHdyaXRlX2J1ZmZlcihzdGFjayswKTsKICAgICByZXR1cm4gMDsKIH0KLQotCi0K
--90e6ba614ed2a3d1640515a49626
Content-Type: application/octet-stream; name="006-bin2h.c-no-basename.patch"
Content-Disposition: attachment; filename="006-bin2h.c-no-basename.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: file6

c3JjL3V0aWxzL2JpbjJoLmM6IHJlbW92ZSBiYXNlbmFtZSgpIGRlcGVuZGVuY3kgYW5kIHJlcG9y
dCB0aGUgZXhlCm5hbWUgc2ltcGx5IGFzICdiaW4yaCcsIHNvIHRoYXQgaXQgY3Jvc3MtYnVpbGRz
IHdpdGhvdXQgd2FybmluZ3MuCgpJbmRleDogc3JjL3V0aWxzL2JpbjJoLmMKPT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpS
Q1MgZmlsZTogL2N2cy9kamdwcC9kamdwcC9zcmMvdXRpbHMvYmluMmguYyx2CnJldHJpZXZpbmcg
cmV2aXNpb24gMS43CmRpZmYgLXUgLXAgLXIxLjcgYmluMmguYwotLS0gc3JjL3V0aWxzL2JpbjJo
LmMJMiBNYXkgMjAxNSAwNzozMjozNCAtMDAwMAkxLjcKKysrIHNyYy91dGlscy9iaW4yaC5jCTkg
TWF5IDIwMTUgMTA6MzA6MTcgLTAwMDAKQEAgLTI1LDEzICsyNSwxMyBAQCBtYWluKGludCBhcmdj
LCBjaGFyICoqYXJndikKICAgaW50IGNvbD0wLCBpOwogICBpZiAoYXJnYyA8IDQpCiAgIHsKLSAg
ICBwcmludGYoInVzYWdlOiAlcyBpbmZpbGUgc3ltbmFtZSBvdXRmaWxlXG4iLCBiYXNlbmFtZShh
cmd2WzBdKSk7CisgICAgcHJpbnRmKCJ1c2FnZTogYmluMmggaW5maWxlIHN5bW5hbWUgb3V0Zmls
ZVxuIik7CiAgICAgZXhpdCgxKTsKICAgfQogICBmID0gb3Blbihhcmd2WzFdLCBPX1JET05MWXxP
X0JJTkFSWSk7CiAgIGlmIChmIDwgMSkKICAgewotICAgIHByaW50ZigiJXM6ICIsYmFzZW5hbWUo
YXJndlswXSkpOworICAgIHByaW50ZigiYmluMmg6ICIpOwogICAgIHBlcnJvcihhcmd2WzFdKTsK
ICAgICBleGl0KDEpOwogICB9CkBAIC00MCw3ICs0MCw3IEBAIG1haW4oaW50IGFyZ2MsIGNoYXIg
Kiphcmd2KQogCiAgIGlmIChvZiA9PSBOVUxMKQogICB7Ci0gICAgcHJpbnRmKCIlczogIixiYXNl
bmFtZShhcmd2WzBdKSk7CisgICAgcHJpbnRmKCJiaW4yaDogIik7CiAgICAgcGVycm9yKGFyZ3Zb
M10pOwogICAgIGV4aXQoMSk7CiAgIH0K
--90e6ba614ed2a3d1640515a49626--
0
Ozkan
5/9/2015 11:38:49 AM
--001a11354e16c99e720515bf03ae
Content-Type: text/plain; charset=UTF-8

On 5/9/15, Ozkan Sezer <sezeroz@gmail.com> wrote:
> On 5/4/15, Andris Pavenis (andris.pavenis@iki.fi)
> <djgpp-announce@delorie.com> wrote:
>> This is announcement of DJGPP 2.05 beta 1
>>
>> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
>> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
>> Unfortunately DJGPP v2.04 was never released and old beta version slowly
>> became almost unusable together with other newer DJGPP packages.
>>
>> More information about changes in DJGPP 2.05 beta 1 is available at
>>
>>      http://www.delorie.com/djgpp/doc/kb/
>>
>> both in sections about changes in 2.04 and 2.05. The same information is
>> also
>> available in file info/kb.inf in djdev205.zip
>>
>> It needs a lot of testing. Please test it if you have time and/or are
>> interested in any of the above features. Any level of testing would be
>> appreciated.
>
> Here are some more janitorial work: see the attached six patches:
>

Here's another: (attached: 007-realpath-leak.patch)

* realpath.c: fix a possible memory leak if user passes a NULL output
  buffer and __canonicalize_path() fails.

--
O.S.

--001a11354e16c99e720515bf03ae
Content-Type: application/octet-stream; name="007-realpath-leak.patch"
Content-Disposition: attachment; filename="007-realpath-leak.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: file0

cmVhbHBhdGguYzogZml4IGEgcG9zc2libGUgbWVtb3J5IGxlYWsgaWYgdXNlciBwYXNzZXMgYSBO
VUxMIG91dHB1dApidWZmZXIgYW5kIF9fY2Fub25pY2FsaXplX3BhdGgoKSBmYWlscy4KCkluZGV4
OiBzcmMvbGliYy9wb3NpeC9zdGRsaWIvcmVhbHBhdGguYwo9PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAv
Y3ZzL2RqZ3BwL2RqZ3BwL3NyYy9saWJjL3Bvc2l4L3N0ZGxpYi9yZWFscGF0aC5jLHYKcmV0cmll
dmluZyByZXZpc2lvbiAxLjIKZGlmZiAtdSAtcCAtcjEuMiByZWFscGF0aC5jCi0tLSBzcmMvbGli
Yy9wb3NpeC9zdGRsaWIvcmVhbHBhdGguYwk3IEp1biAyMDEwIDIyOjU5OjUwIC0wMDAwCTEuMgor
Kysgc3JjL2xpYmMvcG9zaXgvc3RkbGliL3JlYWxwYXRoLmMJMTAgTWF5IDIwMTUgMTg6MjU6MDgg
LTAwMDAKQEAgLTEyLDYgKzEyLDcgQEAgY2hhciAqCiByZWFscGF0aChjb25zdCBjaGFyICppbiwg
Y2hhciAqb3V0KQogewogICBjaGFyIGluMVtQQVRIX01BWF07CisgIGNoYXIgKnJldDsKIAogICBp
ZiAoaW4gPT0gTlVMTCkKICAgewpAQCAtMjUsMTcgKzI2LDIwIEBAIHJlYWxwYXRoKGNvbnN0IGNo
YXIgKmluLCBjaGFyICpvdXQpCiAgICAgcmV0dXJuIE5VTEw7CiAgIH0KIAotICBpZiAob3V0ID09
IE5VTEwgJiYgKG91dCA9IG1hbGxvYygoc2l6ZV90KVBBVEhfTUFYKSkgPT0gTlVMTCkKKyAgaWYg
KCFfX3NvbHZlX3N5bWxpbmtzKGluLCBpbjEpKQorICAgIHJldHVybiBOVUxMOyAvKiBSZXR1cm4g
ZXJybm8gZnJvbSBmcm9tIF9fc29sdmVfZGlyX3N5bWxpbmtzKCkuICAqLworCisgIGlmICghKHJl
dCA9IG91dCkgJiYgIShyZXQgPSBtYWxsb2MoUEFUSF9NQVgpKSkKICAgewogICAgIGVycm5vID0g
RU5PTUVNOwogICAgIHJldHVybiBOVUxMOwogICB9CiAKLSAgaWYgKCFfX3NvbHZlX3N5bWxpbmtz
KGluLCBpbjEpKQotICAgIHJldHVybiBOVUxMOyAvKiBSZXR1cm4gZXJybm8gZnJvbSBmcm9tIF9f
c29sdmVfZGlyX3N5bWxpbmtzKCkuICAqLwotCi0gIGlmIChfX2Nhbm9uaWNhbGl6ZV9wYXRoKGlu
MSwgb3V0LCBQQVRIX01BWCkgPT0gTlVMTCkKKyAgaWYgKF9fY2Fub25pY2FsaXplX3BhdGgoaW4x
LCByZXQsIFBBVEhfTUFYKSA9PSBOVUxMKQorICB7CisgICAgaWYgKHJldCAhPSBvdXQpIGZyZWUg
KHJldCk7CiAgICAgcmV0dXJuIE5VTEw7IC8qIFJldHVybiBlcnJubyBmcm9tIF9fY2Fub25pY2Fs
aXplX3BhdGgoKS4gICovCisgIH0KIAotICByZXR1cm4gb3V0OworICByZXR1cm4gcmV0OwogfQo=
--001a11354e16c99e720515bf03ae--
0
Ozkan
5/10/2015 7:10:28 PM
[adding list back to CC]

On 5/11/15, Andris Pavenis <andris.pavenis@iki.fi> wrote:
[...]
>
> You also mentioned stdbool.h and float.h issues (no patches yet). I do not
> think we should touch
> them now before actual 2.05 release. Also including GCC own header and ones
> modified by
> fixincludes in GCC build process before system ones is way how it is done
> (not only for DJGPP but also
> for other targets).

For float.h issue:  Well, -nostdinc means -nostdinc so I think that we
should be consistent with it.  For gcc >= 4.8 maybe define our _rdtsc()
as __builtin_ia32_rdtsc()??  What was the exact problem with _rdtsc()
with gcc >= 4.8?

For stdbool.h:  it defines bool, true and false which are native to C++
and therefore broken.  Gcc's own stdbool.h is good of course, so why
don't we copy from it?

--
O.S.
0
Ozkan
5/11/2015 8:12:55 AM
On 05/11/2015 11:12 AM, Ozkan Sezer (sezeroz@gmail.com) wrote:
> [adding list back to CC]
>
> On 5/11/15, Andris Pavenis <andris.pavenis@iki.fi> wrote:
> [...]
>> You also mentioned stdbool.h and float.h issues (no patches yet). I do not
>> think we should touch
>> them now before actual 2.05 release. Also including GCC own header and ones
>> modified by
>> fixincludes in GCC build process before system ones is way how it is done
>> (not only for DJGPP but also
>> for other targets).
> For float.h issue:  Well, -nostdinc means -nostdinc so I think that we
> should be consistent with it.  For gcc >= 4.8 maybe define our _rdtsc()
> as __builtin_ia32_rdtsc()??  What was the exact problem with _rdtsc()
> with gcc >= 4.8?
If we define own _rdtsc() we get duplicate definition of it when GCC own header x86intrin.h is also
included (for new GCC version). That was the reason why I used GCC defined function instead
of DJGPP one.

There is additional problem that GCC header files *intrin.h are not OK when -Wcast-qual is being used.
The problem is triggered when building DJGPP tests but not when building libc itself.

Andris

0
Andris
5/16/2015 6:54:48 PM
On 5/16/15, Andris Pavenis (andris.pavenis@iki.fi) <djgpp@delorie.com> wrote:
> On 05/11/2015 11:12 AM, Ozkan Sezer (sezeroz@gmail.com) wrote:
>> [adding list back to CC]
>>
>> On 5/11/15, Andris Pavenis <andris.pavenis@iki.fi> wrote:
>> [...]
>>> You also mentioned stdbool.h and float.h issues (no patches yet). I do
>>> not
>>> think we should touch
>>> them now before actual 2.05 release. Also including GCC own header and
>>> ones
>>> modified by
>>> fixincludes in GCC build process before system ones is way how it is
>>> done
>>> (not only for DJGPP but also
>>> for other targets).
>> For float.h issue:  Well, -nostdinc means -nostdinc so I think that we
>> should be consistent with it.  For gcc >= 4.8 maybe define our _rdtsc()
>> as __builtin_ia32_rdtsc()??  What was the exact problem with _rdtsc()
>> with gcc >= 4.8?
> If we define own _rdtsc() we get duplicate definition of it when GCC own
> header x86intrin.h is also
> included (for new GCC version). That was the reason why I used GCC defined
> function instead
> of DJGPP one.
>
> There is additional problem that GCC header files *intrin.h are not OK when
> -Wcast-qual is being used.
> The problem is triggered when building DJGPP tests but not when building
> libc itself.
>

Can you please show the error or warning messages form each
problematic case?

I tried to reproduce the problems: commented out the -I$(GCC_INC_DIR)
additions to CFLAGS in both src/ and tests/makefile.in, compiled src
using my gcc5 cross-compiler and got no errors or warnings for _rdtsc()
Tried compiling the test programs: since I am on linux, had to do some
voodoo in the makefiles by changing gcc and ld to cross- versions and
by replacing rem.com with /bin/true, they just compiled. (of course,
no run tests, and found other issues, but no _rdtsc() issues.)
0
Ozkan
5/16/2015 7:56:28 PM
Compilation of the test programs revealed the following
(There were some other warnings, but much less important
or unimportant.)

* tests/libc/posix/fcntl/makef3gb.c
makef3gb.c: In function 'main':
makef3gb.c:44:47: warning: iteration 512000u invokes undefined
behavior [-Waggressive-loop-optimizations]
   for (i = 0; i <= BIGBUFSIZE; i++) bigbuf[i] = (char) i;
                                               ^
makef3gb.c:44:3: note: containing loop
   for (i = 0; i <= BIGBUFSIZE; i++) bigbuf[i] = (char) i;
   ^

Just fixed in makef3gb.c r1.2 by changing comparison from le to lt.


* include/math.h (sincos) :
In file included from strtold1.c:4:0:
../../../../include/math.h:261:8: warning: conflicting types for
built-in function 'sincos'
 void   sincos(double *_cos, double *_sin, double _x);
        ^
In file included from strtod1.c:4:0:
../../../../include/math.h:261:8: warning: conflicting types for
built-in function 'sincos'
 void   sincos(double *_cos, double *_sin, double _x);
        ^

My linux man page for sincos() has the prototype:
void sincos(double x, double *sin, double *cos);
The djgpp version has the parameters in reversed order.
The library compilation doesn't warn because the source
is in assembly not C. What to do with this?

--
O.S.
0
Ozkan
5/16/2015 8:10:16 PM
On 05/16/2015 10:56 PM, Ozkan Sezer (sezeroz@gmail.com) wrote:
> On 5/16/15, Andris Pavenis (andris.pavenis@iki.fi) <djgpp@delorie.com> wrote:
>> with gcc >= 4.8?
>> If we define own _rdtsc() we get duplicate definition of it when GCC own
>> header x86intrin.h is also
>> included (for new GCC version). That was the reason why I used GCC defined
>> function instead
>> of DJGPP one.
>>
>> Can you please show the error or warning messages form each
>> problematic case?
>>
>> I tried to reproduce the problems: commented out the -I$(GCC_INC_DIR)
>> additions to CFLAGS in both src/ and tests/makefile.in, compiled src
>> using my gcc5 cross-compiler and got no errors or warnings for _rdtsc()
>> Tried compiling the test programs: since I am on linux, had to do some
>> voodoo in the makefiles by changing gcc and ld to cross- versions and
>> by replacing rem.com with /bin/true, they just compiled. (of course,
>> no run tests, and found other issues, but no _rdtsc() issues.)
I do not remember exactly with which piece of software I got this problem with _rdtsc

With DJGPP own _rdtsc the following 2 includes causes compile error:

#include <x86intrin.h>
#include <time.h>

One should be able to use SSE/MMX/AVX instructions with DJGPP.

ia32intrin.h defines _rdtsc() and as result one gets duplicate definition if one includes
x86intrin.h before time.h without that change (including x86intrin.h instead
of defining _rdtsc()).

There is fortunately another way without including x86intrin.h from time.h:

ia86intrin.h contains '#define _rdtsc() __rdtsc()' and it defines __rdtsc as an inline function.
One could also undefine _rdtsc before defining our own.

Andris

0
Andris
5/17/2015 5:39:50 AM
On 5/17/15, Andris Pavenis (andris.pavenis@iki.fi) <djgpp@delorie.com> wrote:
> On 05/16/2015 10:56 PM, Ozkan Sezer (sezeroz@gmail.com) wrote:
>> On 5/16/15, Andris Pavenis (andris.pavenis@iki.fi) <djgpp@delorie.com>
>> wrote:
>>> with gcc >= 4.8?
>>> If we define own _rdtsc() we get duplicate definition of it when GCC own
>>> header x86intrin.h is also
>>> included (for new GCC version). That was the reason why I used GCC
>>> defined
>>> function instead
>>> of DJGPP one.
>>>
>>> Can you please show the error or warning messages form each
>>> problematic case?
>>>
>>> I tried to reproduce the problems: commented out the -I$(GCC_INC_DIR)
>>> additions to CFLAGS in both src/ and tests/makefile.in, compiled src
>>> using my gcc5 cross-compiler and got no errors or warnings for _rdtsc()
>>> Tried compiling the test programs: since I am on linux, had to do some
>>> voodoo in the makefiles by changing gcc and ld to cross- versions and
>>> by replacing rem.com with /bin/true, they just compiled. (of course,
>>> no run tests, and found other issues, but no _rdtsc() issues.)
> I do not remember exactly with which piece of software I got this problem
> with _rdtsc
>
> With DJGPP own _rdtsc the following 2 includes causes compile error:
>
> #include <x86intrin.h>
> #include <time.h>
>
> One should be able to use SSE/MMX/AVX instructions with DJGPP.
>
> ia32intrin.h defines _rdtsc() and as result one gets duplicate definition if
> one includes
> x86intrin.h before time.h without that change (including x86intrin.h
> instead
> of defining _rdtsc()).
>
> There is fortunately another way without including x86intrin.h from time.h:
>
> ia86intrin.h contains '#define _rdtsc() __rdtsc()' and it defines __rdtsc as
> an inline function.
> One could also undefine _rdtsc before defining our own.
>
> Andris
>
>


How about something like the following:  when building djgpp, keep our
version of _rdtsc(), but for users defer to gcc's version:

Index: include/time.h
===================================================================
RCS file: /cvs/djgpp/djgpp/include/time.h,v
retrieving revision 1.16
diff -u -r1.16 time.h
--- include/time.h	2 May 2015 07:31:49 -0000	1.16
+++ include/time.h	17 May 2015 08:14:37 -0000
@@ -112,7 +112,7 @@
 void		tzsetwall(void);
 uclock_t	uclock(void);

-#if ((__GNUC__ == 4 && __GNUC_MINOR__ >= 8) || (__GNUC__ > 4))
+#if !defined(_IN_DJBUILD) && ((__GNUC__ == 4 && __GNUC_MINOR__ >= 8)
|| (__GNUC__ > 4))

 /* GCC-4.8 has own built-in _rdtsc for ix86. Therefore use it insted
of DJGPP one. */
 #include <x86intrin.h>
Index: src/makefile.cfg
===================================================================
RCS file: /cvs/djgpp/djgpp/src/makefile.cfg,v
retrieving revision 1.6
diff -u -r1.6 makefile.cfg
--- src/makefile.cfg	11 May 2015 11:00:14 -0000	1.6
+++ src/makefile.cfg	17 May 2015 08:14:37 -0000
@@ -46,16 +46,17 @@
 	@./misc.exe echo - "-Wundef" >>gcc.opt
 	@./misc.exe echo - "-Wcast-align" >>gcc.opt
 	@./misc.exe echo - "-Wsign-compare" >>gcc.opt
+	@./misc.exe echo - "-D_IN_DJBUILD" >>gcc.opt
 	@./misc.exe echo - "-nostdinc" >>gcc.opt
 	@./misc.exe echo - "$(IQUOTE)" >>gcc.opt

-
 gcc-l.opt: makefile.cfg
 	@./misc.exe echo - "-MD" >gcc-l.opt
 	@./misc.exe echo - "-O2" >>gcc-l.opt
 	@./misc.exe echo - "$(MTUNE)" >>gcc-l.opt
 	@./misc.exe echo - "-march=i386" >>gcc-l.opt
 	@./misc.exe echo - "-Wall" >>gcc-l.opt
+	@./misc.exe echo - "-D_IN_DJBUILD" >>gcc-l.opt
 	@./misc.exe echo - "-nostdinc" >>gcc-l.opt
 	@./misc.exe echo - "$(IQUOTE)" >>gcc-l.opt

Index: src/makefile.inc
===================================================================
RCS file: /cvs/djgpp/djgpp/src/makefile.inc,v
retrieving revision 1.16
diff -u -r1.16 makefile.inc
--- src/makefile.inc	30 Apr 2015 18:50:42 -0000	1.16
+++ src/makefile.inc	17 May 2015 08:14:37 -0000
@@ -51,7 +51,7 @@

 # Find GCC own include directory and add it to CFLAGS
 GCC_INC_DIR := $(shell $(CROSS_GCC) -print-file-name=include)
-CFLAGS += -I$(GCC_INC_DIR)
+#CFLAGS += -I$(GCC_INC_DIR)

 # Pass defines as compiler/assembler switches
 CFLAGS += -DGAS_MAJOR=$(GAS_MAJOR)

If this is acceptable (and works for you+everyone), a similar change
needs to be done in the tests makefiles. (I've done that locally and
cross-built the libc test programs without errors.)

--
O.S.
0
Ozkan
5/17/2015 8:45:10 AM
On 05/17/2015 11:45 AM, Ozkan Sezer (sezeroz@gmail.com) wrote:
> On 5/17/15, Andris Pavenis (andris.pavenis@iki.fi) <djgpp@delorie.com> wrote:
>> On 05/16/2015 10:56 PM, Ozkan Sezer (sezeroz@gmail.com) wrote:
>>> On 5/16/15, Andris Pavenis (andris.pavenis@iki.fi) <djgpp@delorie.com>
>>> wrote:
>>>> with gcc >= 4.8?
>>>> If we define own _rdtsc() we get duplicate definition of it when GCC own
>>>> header x86intrin.h is also
>>>> included (for new GCC version). That was the reason why I used GCC
>>>> defined
>>>> function instead
>>>> of DJGPP one.
>>>>
>>>> Can you please show the error or warning messages form each
>>>> problematic case?
>>>>
>>>> I tried to reproduce the problems: commented out the -I$(GCC_INC_DIR)
>>>> additions to CFLAGS in both src/ and tests/makefile.in, compiled src
>>>> using my gcc5 cross-compiler and got no errors or warnings for _rdtsc()
>>>> Tried compiling the test programs: since I am on linux, had to do some
>>>> voodoo in the makefiles by changing gcc and ld to cross- versions and
>>>> by replacing rem.com with /bin/true, they just compiled. (of course,
>>>> no run tests, and found other issues, but no _rdtsc() issues.)
>> I do not remember exactly with which piece of software I got this problem
>> with _rdtsc
>>
>> With DJGPP own _rdtsc the following 2 includes causes compile error:
>>
>> #include <x86intrin.h>
>> #include <time.h>
>>
>> One should be able to use SSE/MMX/AVX instructions with DJGPP.
>>
>> ia32intrin.h defines _rdtsc() and as result one gets duplicate definition if
>> one includes
>> x86intrin.h before time.h without that change (including x86intrin.h
>> instead
>> of defining _rdtsc()).
>>
>> There is fortunately another way without including x86intrin.h from time.h:
>>
>> ia86intrin.h contains '#define _rdtsc() __rdtsc()' and it defines __rdtsc as
>> an inline function.
>> One could also undefine _rdtsc before defining our own.
>>
>> Andris
>>
>>
>
> How about something like the following:  when building djgpp, keep our
> version of _rdtsc(), but for users defer to gcc's version:

I already committed change which avoid to include x86intrin.h at all. So also
-Wcat-qual related warnings from GCC MMX/SSE/AVX related stuff no more matter.

About removing GCC own include directory from header files search path:

I would prefer not to do it. The idea of -nostdinc was to tell GCC not to look-up
installed DJGPP header files but use ones from build directory added from command line.
GCC include files is a different stuff and should not be removed from look-up.
It is better to have them included in the same way as it is done when building
user applications.

Andris

>
> Index: include/time.h
> ===================================================================
> RCS file: /cvs/djgpp/djgpp/include/time.h,v
> retrieving revision 1.16
> diff -u -r1.16 time.h
> --- include/time.h	2 May 2015 07:31:49 -0000	1.16
> +++ include/time.h	17 May 2015 08:14:37 -0000
> @@ -112,7 +112,7 @@
>   void		tzsetwall(void);
>   uclock_t	uclock(void);
>
> -#if ((__GNUC__ == 4 && __GNUC_MINOR__ >= 8) || (__GNUC__ > 4))
> +#if !defined(_IN_DJBUILD) && ((__GNUC__ == 4 && __GNUC_MINOR__ >= 8)
> || (__GNUC__ > 4))
>
>   /* GCC-4.8 has own built-in _rdtsc for ix86. Therefore use it insted
> of DJGPP one. */
>   #include <x86intrin.h>
> Index: src/makefile.cfg
> ===================================================================
> RCS file: /cvs/djgpp/djgpp/src/makefile.cfg,v
> retrieving revision 1.6
> diff -u -r1.6 makefile.cfg
> --- src/makefile.cfg	11 May 2015 11:00:14 -0000	1.6
> +++ src/makefile.cfg	17 May 2015 08:14:37 -0000
> @@ -46,16 +46,17 @@
>   	@./misc.exe echo - "-Wundef" >>gcc.opt
>   	@./misc.exe echo - "-Wcast-align" >>gcc.opt
>   	@./misc.exe echo - "-Wsign-compare" >>gcc.opt
> +	@./misc.exe echo - "-D_IN_DJBUILD" >>gcc.opt
>   	@./misc.exe echo - "-nostdinc" >>gcc.opt
>   	@./misc.exe echo - "$(IQUOTE)" >>gcc.opt
>
> -
>   gcc-l.opt: makefile.cfg
>   	@./misc.exe echo - "-MD" >gcc-l.opt
>   	@./misc.exe echo - "-O2" >>gcc-l.opt
>   	@./misc.exe echo - "$(MTUNE)" >>gcc-l.opt
>   	@./misc.exe echo - "-march=i386" >>gcc-l.opt
>   	@./misc.exe echo - "-Wall" >>gcc-l.opt
> +	@./misc.exe echo - "-D_IN_DJBUILD" >>gcc-l.opt
>   	@./misc.exe echo - "-nostdinc" >>gcc-l.opt
>   	@./misc.exe echo - "$(IQUOTE)" >>gcc-l.opt
>
> Index: src/makefile.inc
> ===================================================================
> RCS file: /cvs/djgpp/djgpp/src/makefile.inc,v
> retrieving revision 1.16
> diff -u -r1.16 makefile.inc
> --- src/makefile.inc	30 Apr 2015 18:50:42 -0000	1.16
> +++ src/makefile.inc	17 May 2015 08:14:37 -0000
> @@ -51,7 +51,7 @@
>
>   # Find GCC own include directory and add it to CFLAGS
>   GCC_INC_DIR := $(shell $(CROSS_GCC) -print-file-name=include)
> -CFLAGS += -I$(GCC_INC_DIR)
> +#CFLAGS += -I$(GCC_INC_DIR)
>
>   # Pass defines as compiler/assembler switches
>   CFLAGS += -DGAS_MAJOR=$(GAS_MAJOR)
>
> If this is acceptable (and works for you+everyone), a similar change
> needs to be done in the tests makefiles. (I've done that locally and
> cross-built the libc test programs without errors.)
>
> --
> O.S.
>
>

0
Andris
5/17/2015 10:43:52 AM
Applied the following to dxe3res.c as of r1.4:

make dxe3res to build and run on unix:
- include sys/dxe.h from the local source tree only,
- do the LD_LIBRARY_PATH lookup only for DOS builds.

Index: src/dxe/dxe3res.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/dxe/dxe3res.c,v
retrieving revision 1.3
diff -u -p -r1.3 dxe3res.c
--- src/dxe/dxe3res.c	16 Jun 2013 01:15:12 -0000	1.3
+++ src/dxe/dxe3res.c	17 May 2015 10:37:50 -0000
@@ -12,7 +12,7 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
-#include <sys/dxe.h>
+#include "../../include/sys/dxe.h"

 #define VERSION "1.0"

@@ -288,7 +288,7 @@ static char *gettables(const char *filen
 {
   FILE *f;
   char *table;
-
+#ifdef __DJGPP__
   char *scan;
   char tempfn[FILENAME_MAX]; /* Temporary filename */

@@ -324,7 +324,7 @@ static char *gettables(const char *filen
     return NULL;
   }
 found:
-
+#endif /* __DJGPP__ */
   if ((f = fopen(filename, "rb")) != NULL)
   {
     if (readf(dxehdr, sizeof(dxe3_header), f, 0) && (isdxe(dxehdr) == 3))

--
O.S.
0
Ozkan
5/17/2015 11:00:10 AM
On 5/17/15, Andris Pavenis (andris.pavenis@iki.fi) <djgpp@delorie.com> wrote:
> On 05/17/2015 11:45 AM, Ozkan Sezer (sezeroz@gmail.com) wrote:
>> On 5/17/15, Andris Pavenis (andris.pavenis@iki.fi) <djgpp@delorie.com>
>> wrote:
>>> On 05/16/2015 10:56 PM, Ozkan Sezer (sezeroz@gmail.com) wrote:
>>>> On 5/16/15, Andris Pavenis (andris.pavenis@iki.fi) <djgpp@delorie.com>
>>>> wrote:
>>>>> with gcc >= 4.8?
>>>>> If we define own _rdtsc() we get duplicate definition of it when GCC
>>>>> own
>>>>> header x86intrin.h is also
>>>>> included (for new GCC version). That was the reason why I used GCC
>>>>> defined
>>>>> function instead
>>>>> of DJGPP one.
>>>>>
>>>>> Can you please show the error or warning messages form each
>>>>> problematic case?
>>>>>
>>>>> I tried to reproduce the problems: commented out the -I$(GCC_INC_DIR)
>>>>> additions to CFLAGS in both src/ and tests/makefile.in, compiled src
>>>>> using my gcc5 cross-compiler and got no errors or warnings for
>>>>> _rdtsc()
>>>>> Tried compiling the test programs: since I am on linux, had to do some
>>>>> voodoo in the makefiles by changing gcc and ld to cross- versions and
>>>>> by replacing rem.com with /bin/true, they just compiled. (of course,
>>>>> no run tests, and found other issues, but no _rdtsc() issues.)
>>> I do not remember exactly with which piece of software I got this
>>> problem
>>> with _rdtsc
>>>
>>> With DJGPP own _rdtsc the following 2 includes causes compile error:
>>>
>>> #include <x86intrin.h>
>>> #include <time.h>
>>>
>>> One should be able to use SSE/MMX/AVX instructions with DJGPP.
>>>
>>> ia32intrin.h defines _rdtsc() and as result one gets duplicate definition
>>> if
>>> one includes
>>> x86intrin.h before time.h without that change (including x86intrin.h
>>> instead
>>> of defining _rdtsc()).
>>>
>>> There is fortunately another way without including x86intrin.h from
>>> time.h:
>>>
>>> ia86intrin.h contains '#define _rdtsc() __rdtsc()' and it defines __rdtsc
>>> as
>>> an inline function.
>>> One could also undefine _rdtsc before defining our own.
>>>
>>> Andris
>>>
>>>
>>
>> How about something like the following:  when building djgpp, keep our
>> version of _rdtsc(), but for users defer to gcc's version:
>
> I already committed change which avoid to include x86intrin.h at all. So
> also
> -Wcat-qual related warnings from GCC MMX/SSE/AVX related stuff no more
> matter.
>

OK,

> About removing GCC own include directory from header files search path:
>
> I would prefer not to do it. The idea of -nostdinc was to tell GCC not to
> look-up
> installed DJGPP header files but use ones from build directory added from
> command line.
> GCC include files is a different stuff and should not be removed from
> look-up.
> It is better to have them included in the same way as it is done when
> building
> user applications.
>
> Andris
>

As I said in earlier in this thread, gcc's own headers (e.g. float.h) undefine
stuff from djgpp's headers and the resulting binaries differ, e.g. for DBL_MIN
and DBL_MAX.  I don't like this.  DJ, what do you think?

--
O.S.
0
Ozkan
5/17/2015 11:00:17 AM
If gcc and djgpp have differing values for DBL_MIN and DBL_MAX, one of
them is wrong.  Do we know which one?
0
DJ
5/18/2015 1:14:44 AM
On 5/18/15, DJ Delorie <dj@delorie.com> wrote:
>
> If gcc and djgpp have differing values for DBL_MIN and DBL_MAX, one of
> them is wrong.  Do we know which one?
>

* gcc float.h: (same for gcc3.4 and gcc5.1)
#undef FLT_MAX
#undef DBL_MAX
#undef LDBL_MAX
#define FLT_MAX		__FLT_MAX__
#define DBL_MAX		__DBL_MAX__
#define LDBL_MAX	__LDBL_MAX__

* gcc builtin defines:
#define __FLT_MAX__ 3.40282347e+38F /* gcc3.4 */
#define __FLT_MAX__ 3.40282346638528859812e+38F /* gcc5.1 */
#define __DBL_MAX__ 1.7976931348623157e+308 /* gcc3.4 */
#define __DBL_MAX__ ((double)1.79769313486231570815e+308L) /* gcc5.1 */
#define __LDBL_MAX__ 1.18973149535723176502e+4932L /* gcc3.4 */
#define __LDBL_MAX__ 1.18973149535723176502e+4932L /* gcc5.1 */

* dj float.h:
extern double __dj_double_max;
#define DBL_MAX		__dj_double_max

* libc/ansif/float/float_dx.c:
double_t __dj_double_max     = { 0xffffffffU, 0xfffff, 0x7fe, 0x0 };
* libc/ansif/float/float_fx.c:
float_t __dj_float_max     = { 0x7fffff, 0xfe, 0x0 };
0
Ozkan
5/18/2015 9:43:28 AM
I tested this with Linux gcc 5.1 and got the same bit patterns for
both cases:

typedef struct {
  unsigned mantissal:32;
  unsigned mantissah:20;
  unsigned exponent:11;
  unsigned sign:1;
} double_t;
double   gdm = ((double)1.79769313486231570815e+308L);
double_t ddm = { 0xffffffffU, 0xfffff, 0x7fe, 0x0 };

0
DJ
5/18/2015 12:16:36 PM
On 5/18/15, DJ Delorie <dj@delorie.com> wrote:
>
> I tested this with Linux gcc 5.1 and got the same bit patterns for
> both cases:
>
> typedef struct {
>   unsigned mantissal:32;
>   unsigned mantissah:20;
>   unsigned exponent:11;
>   unsigned sign:1;
> } double_t;
> double   gdm = ((double)1.79769313486231570815e+308L);
> double_t ddm = { 0xffffffffU, 0xfffff, 0x7fe, 0x0 };
>

OK, if we are good with gcc defines then change your float.h accordingly,
but that's not my point.

The discussion is about we are pointing to gcc's headers directory
for allowed includes when building djgpp itself, whereas

(i) we don't need that at all anymore (it was done only to work around
a gcc builtin problem and it got solved without needing this hack),

(ii) we are building with -nostdinc which means we are self-
sufficient, and that hack is against this,

(iii) since our DBL_MAX, etc are not compile time constants but symbols,
and gcc ones are, the binary output of several djgpp functions such as
strtod, etc, are different with and without gcc-headers hack.

Those are the reasons I am against allowing gcc's headers in djgpp
build.
0
Ozkan
5/18/2015 1:06:19 PM
> Date: Mon, 18 May 2015 08:16:36 -0400
> From: DJ Delorie <dj@delorie.com>
> 
> 
> I tested this with Linux gcc 5.1 and got the same bit patterns for
> both cases:
> 
> typedef struct {
>   unsigned mantissal:32;
>   unsigned mantissah:20;
>   unsigned exponent:11;
>   unsigned sign:1;
> } double_t;
> double   gdm = ((double)1.79769313486231570815e+308L);
> double_t ddm = { 0xffffffffU, 0xfffff, 0x7fe, 0x0 };

But with the one in DJGPP's headers, we are not at the mercy of the
compiler's bugs^H^H^H^Hfeatures...
0
Eli
5/18/2015 2:26:26 PM
> Date: Mon, 18 May 2015 16:06:19 +0300
> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
> 
> The discussion is about we are pointing to gcc's headers directory
> for allowed includes when building djgpp itself, whereas
> 
> (i) we don't need that at all anymore (it was done only to work around
> a gcc builtin problem and it got solved without needing this hack),
> 
> (ii) we are building with -nostdinc which means we are self-
> sufficient, and that hack is against this,
> 
> (iii) since our DBL_MAX, etc are not compile time constants but symbols,
> and gcc ones are, the binary output of several djgpp functions such as
> strtod, etc, are different with and without gcc-headers hack.
> 
> Those are the reasons I am against allowing gcc's headers in djgpp
> build.

AFAIR, -nostdinc means without library headers, but it does not
preclude the headers that are internal to the compiler.

IOW, I'm not sure I understand the problem you have with what we do.
Can you elaborate?
0
Eli
5/18/2015 2:28:55 PM
On 5/18/15, Eli Zaretskii (eliz@gnu.org) <djgpp@delorie.com> wrote:
>> Date: Mon, 18 May 2015 16:06:19 +0300
>> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
>>
>> The discussion is about we are pointing to gcc's headers directory
>> for allowed includes when building djgpp itself, whereas
>>
>> (i) we don't need that at all anymore (it was done only to work around
>> a gcc builtin problem and it got solved without needing this hack),
>>
>> (ii) we are building with -nostdinc which means we are self-
>> sufficient, and that hack is against this,
>>
>> (iii) since our DBL_MAX, etc are not compile time constants but symbols,
>> and gcc ones are, the binary output of several djgpp functions such as
>> strtod, etc, are different with and without gcc-headers hack.
>>
>> Those are the reasons I am against allowing gcc's headers in djgpp
>> build.
>
> AFAIR, -nostdinc means without library headers, but it does not
> preclude the headers that are internal to the compiler.
>

See below,

> IOW, I'm not sure I understand the problem you have with what we do.
> Can you elaborate?
>

I thought that I elaborated enough in the whole thread, but here goes.
Get the cvs, compile normally under src/.  Make a backup copy of
src/libc/ansi/stdlib/strtod.d and then do the following:

Index: makefile.inc
===================================================================
RCS file: /cvs/djgpp/djgpp/src/makefile.inc,v
retrieving revision 1.16
diff -u -r1.16 makefile.inc
--- makefile.inc	30 Apr 2015 18:50:42 -0000	1.16
+++ makefile.inc	18 May 2015 15:15:30 -0000
@@ -51,7 +51,7 @@

 # Find GCC own include directory and add it to CFLAGS
 GCC_INC_DIR := $(shell $(CROSS_GCC) -print-file-name=include)
-CFLAGS += -I$(GCC_INC_DIR)
+#CFLAGS += -I$(GCC_INC_DIR)

 # Pass defines as compiler/assembler switches
 CFLAGS += -DGAS_MAJOR=$(GAS_MAJOR)

Now do a make clean, recompile and compare the old and new strtod.d:

--- strtod.d.bak
+++ strtod.d
@@ -1,7 +1,6 @@
 strtod.o: strtod.c ../../../../include/libc/stubs.h \
   ../../../../include/locale.h ../../../../include/math.h \
   ../../../../include/stdlib.h ../../../../include/sys/djtypes.h \
-  /usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6/include/float.h \
   ../../../../include/float.h ../../../../include/errno.h \
   ../../../../include/ctype.h ../../../../include/inlines/ctype.ha \
   ../../../../include/inlines/ctype.hp \

As you see, -nostdinc does prevent compiler's own headers from being
used. But with current cvs as it is, we are telling the compiler to
do use its own headers: Not a good idea IMO.
0
Ozkan
5/18/2015 3:22:35 PM
On 05/18/2015 06:22 PM, Ozkan Sezer (sezeroz@gmail.com) wrote:
> On 5/18/15, Eli Zaretskii (eliz@gnu.org) <djgpp@delorie.com> wrote:
>>> Date: Mon, 18 May 2015 16:06:19 +0300
>>> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
>>>
>>> The discussion is about we are pointing to gcc's headers directory
>>> for allowed includes when building djgpp itself, whereas
>>>
>>> (i) we don't need that at all anymore (it was done only to work around
>>> a gcc builtin problem and it got solved without needing this hack),
>>>
>>> (ii) we are building with -nostdinc which means we are self-
>>> sufficient, and that hack is against this,
>>>
>>> (iii) since our DBL_MAX, etc are not compile time constants but symbols,
>>> and gcc ones are, the binary output of several djgpp functions such as
>>> strtod, etc, are different with and without gcc-headers hack.
>>>
>>> Those are the reasons I am against allowing gcc's headers in djgpp
>>> build.
>> AFAIR, -nostdinc means without library headers, but it does not
>> preclude the headers that are internal to the compiler.
>>
> See below,
>
>> IOW, I'm not sure I understand the problem you have with what we do.
>> Can you elaborate?
>>
> I thought that I elaborated enough in the whole thread, but here goes.
> Get the cvs, compile normally under src/.  Make a backup copy of
> src/libc/ansi/stdlib/strtod.d and then do the following:
>
> Index: makefile.inc
> ===================================================================
> RCS file: /cvs/djgpp/djgpp/src/makefile.inc,v
> retrieving revision 1.16
> diff -u -r1.16 makefile.inc
> --- makefile.inc	30 Apr 2015 18:50:42 -0000	1.16
> +++ makefile.inc	18 May 2015 15:15:30 -0000
> @@ -51,7 +51,7 @@
>
>   # Find GCC own include directory and add it to CFLAGS
>   GCC_INC_DIR := $(shell $(CROSS_GCC) -print-file-name=include)
> -CFLAGS += -I$(GCC_INC_DIR)
> +#CFLAGS += -I$(GCC_INC_DIR)
>
>   # Pass defines as compiler/assembler switches
>   CFLAGS += -DGAS_MAJOR=$(GAS_MAJOR)
>
> Now do a make clean, recompile and compare the old and new strtod.d:
>
> --- strtod.d.bak
> +++ strtod.d
> @@ -1,7 +1,6 @@
>   strtod.o: strtod.c ../../../../include/libc/stubs.h \
>     ../../../../include/locale.h ../../../../include/math.h \
>     ../../../../include/stdlib.h ../../../../include/sys/djtypes.h \
> -  /usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6/include/float.h \
>     ../../../../include/float.h ../../../../include/errno.h \
>     ../../../../include/ctype.h ../../../../include/inlines/ctype.ha \
>     ../../../../include/inlines/ctype.hp \
>
> As you see, -nostdinc does prevent compiler's own headers from being
> used. But with current cvs as it is, we are telling the compiler to
> do use its own headers: Not a good idea IMO.
>
>
Including GCC own headers at first is expected behavior.

There is however one other thing:

Unmodified GCC float.h does NOT include next float.h. See
https://github.com/gcc-mirror/gcc/blob/master/gcc/ginclude/float.h

For example in my Linux installation  there is no float.h in /usr/include.

Including  next float.h is an additional hack. I modified GCC float.h and put there
#ifdef __DJGPP__
#include_next <float.h>
#endif
near the begin of GCC float.h. As far I verified there is no float.h in gcc-3.2, but it appears
in gcc-3.3. The oldest 3.3 DJGPP port deleted/v2gnu/gcc331b.zip already includes DJGPP float.h
in the begin.

I verified now that for MINGW cross-compiler (I have it installed) "#include_next <float.h>" is at 
end of GCC float.h.
Maybe we should do in the same way. In that way DJGPP definitions would override GCC ones instead 
of doing otherwise.

Andris


0
Andris
5/18/2015 4:05:41 PM
> Date: Mon, 18 May 2015 18:22:35 +0300
> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
> 
> --- makefile.inc	30 Apr 2015 18:50:42 -0000	1.16
> +++ makefile.inc	18 May 2015 15:15:30 -0000
> @@ -51,7 +51,7 @@
> 
>  # Find GCC own include directory and add it to CFLAGS
>  GCC_INC_DIR := $(shell $(CROSS_GCC) -print-file-name=include)
> -CFLAGS += -I$(GCC_INC_DIR)
> +#CFLAGS += -I$(GCC_INC_DIR)
> 
>  # Pass defines as compiler/assembler switches
>  CFLAGS += -DGAS_MAJOR=$(GAS_MAJOR)
> 
> Now do a make clean, recompile and compare the old and new strtod.d:
> 
> --- strtod.d.bak
> +++ strtod.d
> @@ -1,7 +1,6 @@
>  strtod.o: strtod.c ../../../../include/libc/stubs.h \
>    ../../../../include/locale.h ../../../../include/math.h \
>    ../../../../include/stdlib.h ../../../../include/sys/djtypes.h \
> -  /usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6/include/float.h \
>    ../../../../include/float.h ../../../../include/errno.h \
>    ../../../../include/ctype.h ../../../../include/inlines/ctype.ha \
>    ../../../../include/inlines/ctype.hp \
> 
> As you see, -nostdinc does prevent compiler's own headers from being
> used. But with current cvs as it is, we are telling the compiler to
> do use its own headers: Not a good idea IMO.

Are you sure the compiler doesn't use that header when it sees
"-nostdinc"?  Could it be that it just doesn't put that header into
the dependencies?
0
Eli
5/18/2015 4:09:31 PM
On 5/18/15, Andris Pavenis (andris.pavenis@iki.fi) <djgpp@delorie.com> wrote:
> On 05/18/2015 06:22 PM, Ozkan Sezer (sezeroz@gmail.com) wrote:
>> On 5/18/15, Eli Zaretskii (eliz@gnu.org) <djgpp@delorie.com> wrote:
>>>> Date: Mon, 18 May 2015 16:06:19 +0300
>>>> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
>>>>
>>>> The discussion is about we are pointing to gcc's headers directory
>>>> for allowed includes when building djgpp itself, whereas
>>>>
>>>> (i) we don't need that at all anymore (it was done only to work around
>>>> a gcc builtin problem and it got solved without needing this hack),
>>>>
>>>> (ii) we are building with -nostdinc which means we are self-
>>>> sufficient, and that hack is against this,
>>>>
>>>> (iii) since our DBL_MAX, etc are not compile time constants but
>>>> symbols,
>>>> and gcc ones are, the binary output of several djgpp functions such as
>>>> strtod, etc, are different with and without gcc-headers hack.
>>>>
>>>> Those are the reasons I am against allowing gcc's headers in djgpp
>>>> build.
>>> AFAIR, -nostdinc means without library headers, but it does not
>>> preclude the headers that are internal to the compiler.
>>>
>> See below,
>>
>>> IOW, I'm not sure I understand the problem you have with what we do.
>>> Can you elaborate?
>>>
>> I thought that I elaborated enough in the whole thread, but here goes.
>> Get the cvs, compile normally under src/.  Make a backup copy of
>> src/libc/ansi/stdlib/strtod.d and then do the following:
>>
>> Index: makefile.inc
>> ===================================================================
>> RCS file: /cvs/djgpp/djgpp/src/makefile.inc,v
>> retrieving revision 1.16
>> diff -u -r1.16 makefile.inc
>> --- makefile.inc	30 Apr 2015 18:50:42 -0000	1.16
>> +++ makefile.inc	18 May 2015 15:15:30 -0000
>> @@ -51,7 +51,7 @@
>>
>>   # Find GCC own include directory and add it to CFLAGS
>>   GCC_INC_DIR := $(shell $(CROSS_GCC) -print-file-name=include)
>> -CFLAGS += -I$(GCC_INC_DIR)
>> +#CFLAGS += -I$(GCC_INC_DIR)
>>
>>   # Pass defines as compiler/assembler switches
>>   CFLAGS += -DGAS_MAJOR=$(GAS_MAJOR)
>>
>> Now do a make clean, recompile and compare the old and new strtod.d:
>>
>> --- strtod.d.bak
>> +++ strtod.d
>> @@ -1,7 +1,6 @@
>>   strtod.o: strtod.c ../../../../include/libc/stubs.h \
>>     ../../../../include/locale.h ../../../../include/math.h \
>>     ../../../../include/stdlib.h ../../../../include/sys/djtypes.h \
>> -  /usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6/include/float.h
>> \
>>     ../../../../include/float.h ../../../../include/errno.h \
>>     ../../../../include/ctype.h ../../../../include/inlines/ctype.ha \
>>     ../../../../include/inlines/ctype.hp \
>>
>> As you see, -nostdinc does prevent compiler's own headers from being
>> used. But with current cvs as it is, we are telling the compiler to
>> do use its own headers: Not a good idea IMO.
>>
>>
> Including GCC own headers at first is expected behavior.
>

Which djgpp didn't do for 20 years but only since recently,
for why I cannot understand

> There is however one other thing:
>
> Unmodified GCC float.h does NOT include next float.h. See
> https://github.com/gcc-mirror/gcc/blob/master/gcc/ginclude/float.h
>
> For example in my Linux installation  there is no float.h in /usr/include.
>
> Including  next float.h is an additional hack. I modified GCC float.h and
> put there
> #ifdef __DJGPP__
> #include_next <float.h>
> #endif
> near the begin of GCC float.h. As far I verified there is no float.h in
> gcc-3.2, but it appears
> in gcc-3.3. The oldest 3.3 DJGPP port deleted/v2gnu/gcc331b.zip already
> includes DJGPP float.h
> in the begin.
>
> I verified now that for MINGW cross-compiler (I have it installed)
> "#include_next <float.h>" is at
> end of GCC float.h.
> Maybe we should do in the same way. In that way DJGPP definitions would
> override GCC ones instead
> of doing otherwise.
>

That is reasonable: even if djgpp build wouldn't incude gcc's headers
the user programs do, and overriding gcc would be the right thing IMO
0
Ozkan
5/18/2015 4:12:26 PM
On 5/18/15, Eli Zaretskii (eliz@gnu.org) <djgpp@delorie.com> wrote:
>> Date: Mon, 18 May 2015 18:22:35 +0300
>> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
>>
>> --- makefile.inc	30 Apr 2015 18:50:42 -0000	1.16
>> +++ makefile.inc	18 May 2015 15:15:30 -0000
>> @@ -51,7 +51,7 @@
>>
>>  # Find GCC own include directory and add it to CFLAGS
>>  GCC_INC_DIR := $(shell $(CROSS_GCC) -print-file-name=include)
>> -CFLAGS += -I$(GCC_INC_DIR)
>> +#CFLAGS += -I$(GCC_INC_DIR)
>>
>>  # Pass defines as compiler/assembler switches
>>  CFLAGS += -DGAS_MAJOR=$(GAS_MAJOR)
>>
>> Now do a make clean, recompile and compare the old and new strtod.d:
>>
>> --- strtod.d.bak
>> +++ strtod.d
>> @@ -1,7 +1,6 @@
>>  strtod.o: strtod.c ../../../../include/libc/stubs.h \
>>    ../../../../include/locale.h ../../../../include/math.h \
>>    ../../../../include/stdlib.h ../../../../include/sys/djtypes.h \
>> -  /usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6/include/float.h
>> \
>>    ../../../../include/float.h ../../../../include/errno.h \
>>    ../../../../include/ctype.h ../../../../include/inlines/ctype.ha \
>>    ../../../../include/inlines/ctype.hp \
>>
>> As you see, -nostdinc does prevent compiler's own headers from being
>> used. But with current cvs as it is, we are telling the compiler to
>> do use its own headers: Not a good idea IMO.
>
> Are you sure the compiler doesn't use that header when it sees
> "-nostdinc"?  Could it be that it just doesn't put that header into
> the dependencies?
>

Joke, right?
0
Ozkan
5/18/2015 4:13:12 PM
> Date: Mon, 18 May 2015 19:13:12 +0300
> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
> 
> >> --- strtod.d.bak
> >> +++ strtod.d
> >> @@ -1,7 +1,6 @@
> >>  strtod.o: strtod.c ../../../../include/libc/stubs.h \
> >>    ../../../../include/locale.h ../../../../include/math.h \
> >>    ../../../../include/stdlib.h ../../../../include/sys/djtypes.h \
> >> -  /usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6/include/float.h
> >> \
> >>    ../../../../include/float.h ../../../../include/errno.h \
> >>    ../../../../include/ctype.h ../../../../include/inlines/ctype.ha \
> >>    ../../../../include/inlines/ctype.hp \
> >>
> >> As you see, -nostdinc does prevent compiler's own headers from being
> >> used. But with current cvs as it is, we are telling the compiler to
> >> do use its own headers: Not a good idea IMO.
> >
> > Are you sure the compiler doesn't use that header when it sees
> > "-nostdinc"?  Could it be that it just doesn't put that header into
> > the dependencies?
> >
> 
> Joke, right?

You mean, you are joking by asking whether I am?
0
Eli
5/18/2015 4:49:30 PM
On 5/18/15, Eli Zaretskii (eliz@gnu.org) <djgpp@delorie.com> wrote:
>> Date: Mon, 18 May 2015 19:13:12 +0300
>> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
>>
>> >> --- strtod.d.bak
>> >> +++ strtod.d
>> >> @@ -1,7 +1,6 @@
>> >>  strtod.o: strtod.c ../../../../include/libc/stubs.h \
>> >>    ../../../../include/locale.h ../../../../include/math.h \
>> >>    ../../../../include/stdlib.h ../../../../include/sys/djtypes.h \
>> >> -
>> >> /usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6/include/float.h
>> >> \
>> >>    ../../../../include/float.h ../../../../include/errno.h \
>> >>    ../../../../include/ctype.h ../../../../include/inlines/ctype.ha \
>> >>    ../../../../include/inlines/ctype.hp \
>> >>
>> >> As you see, -nostdinc does prevent compiler's own headers from being
>> >> used. But with current cvs as it is, we are telling the compiler to
>> >> do use its own headers: Not a good idea IMO.
>> >
>> > Are you sure the compiler doesn't use that header when it sees
>> > "-nostdinc"?  Could it be that it just doesn't put that header into
>> > the dependencies?
>> >
>>
>> Joke, right?
>
> You mean, you are joking by asking whether I am?
>

This is ridiculous.. To answer your original question, yes I am sure.
Did you even try to reproduce what I said?  If you ever bother to do
so, you can even add -save-temps to the cflags and compare the
assembler outputs to see what I am saying.
0
Ozkan
5/18/2015 4:59:05 PM
> Date: Mon, 18 May 2015 19:59:05 +0300
> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
> 
> On 5/18/15, Eli Zaretskii (eliz@gnu.org) <djgpp@delorie.com> wrote:
> >> Date: Mon, 18 May 2015 19:13:12 +0300
> >> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
> >>
> >> >> --- strtod.d.bak
> >> >> +++ strtod.d
> >> >> @@ -1,7 +1,6 @@
> >> >>  strtod.o: strtod.c ../../../../include/libc/stubs.h \
> >> >>    ../../../../include/locale.h ../../../../include/math.h \
> >> >>    ../../../../include/stdlib.h ../../../../include/sys/djtypes.h \
> >> >> -
> >> >> /usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6/include/float.h
> >> >> \
> >> >>    ../../../../include/float.h ../../../../include/errno.h \
> >> >>    ../../../../include/ctype.h ../../../../include/inlines/ctype.ha \
> >> >>    ../../../../include/inlines/ctype.hp \
> >> >>
> >> >> As you see, -nostdinc does prevent compiler's own headers from being
> >> >> used. But with current cvs as it is, we are telling the compiler to
> >> >> do use its own headers: Not a good idea IMO.
> >> >
> >> > Are you sure the compiler doesn't use that header when it sees
> >> > "-nostdinc"?  Could it be that it just doesn't put that header into
> >> > the dependencies?
> >> >
> >>
> >> Joke, right?
> >
> > You mean, you are joking by asking whether I am?
> 
> This is ridiculous.

Why "ridiculous"?  You asked questions, so I'm trying to help you
figure things out.  You can ignore what I say if you think it's
irrelevant, or doesn't help you.  But this reaction of yours is just
plain rude, for no good reason (and not for the first time, either).
I'm trying to help you as best I can, I don't think I deserve this
attitude of yours, even if what I say sound preposterous to you.

> Did you even try to reproduce what I said?

Did you even care to ask if I can set that up, or have enough time to
do so?  Why should that be a prerequisite for trying to think aloud
about the problem _you_ are asking questions about?

Or if that _is_ a prerequisite, please say so loud and clear, and I
won't bother answering you if I cannot try it myself.

> If you ever bother to do so, you can even add -save-temps to the
> cflags and compare the assembler outputs to see what I am saying.

I believe you.  I didn't ask that question because I thought you were
lying, or didn't know what you were talking about.  I asked it because
these issues are complicated, and sometimes we tend to think we
understand something, when in fact we miss some subtle aspects.  Like
in that example with _open and O_BINARY a couple of days ago.

So please don't assume that every question like that is a challenge of
your integrity or a personal attack on your intelligence.  It's just a
normal way of discussing a complicated issue, about which _you_ asked
questions.  I'm not attacking you, I'm trying to help, goddamit!
0
Eli
5/18/2015 5:22:57 PM
> Date: Mon, 18 May 2015 19:05:41 +0300
> From: "Andris Pavenis (andris.pavenis@iki.fi)" <djgpp@delorie.com>
> 
> On 05/18/2015 06:22 PM, Ozkan Sezer (sezeroz@gmail.com) wrote:
> > On 5/18/15, Eli Zaretskii (eliz@gnu.org) <djgpp@delorie.com> wrote:
> >>> Date: Mon, 18 May 2015 16:06:19 +0300
> >>> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
> >>>
> >>> The discussion is about we are pointing to gcc's headers directory
> >>> for allowed includes when building djgpp itself, whereas
> >>>
> >>> (i) we don't need that at all anymore (it was done only to work around
> >>> a gcc builtin problem and it got solved without needing this hack),
> >>>
> >>> (ii) we are building with -nostdinc which means we are self-
> >>> sufficient, and that hack is against this,
> >>>
> >>> (iii) since our DBL_MAX, etc are not compile time constants but symbols,
> >>> and gcc ones are, the binary output of several djgpp functions such as
> >>> strtod, etc, are different with and without gcc-headers hack.
> >>>
> >>> Those are the reasons I am against allowing gcc's headers in djgpp
> >>> build.
> >> AFAIR, -nostdinc means without library headers, but it does not
> >> preclude the headers that are internal to the compiler.

Actually, I think we use -nostdinc to make sure that the header files
come from the library being compiled, not from the installed
production environment.  IOW, if you have DJGPP v2.03 installed and
want to build a v2.05 library, you don't want to include, say, stdio.h
that came with v2.03.

Which means...

> >> [...]
> Including GCC own headers at first is expected behavior.

...that including GCC headers is fine, provided that it's needed.

But why is it needed?  Andris, you installed the change that added
that 2 years ago; do you remember what was the reason for that?

> There is however one other thing:
> 
> Unmodified GCC float.h does NOT include next float.h. See
> https://github.com/gcc-mirror/gcc/blob/master/gcc/ginclude/float.h
> 
> For example in my Linux installation  there is no float.h in /usr/include.
> 
> Including  next float.h is an additional hack. I modified GCC float.h and put there
> #ifdef __DJGPP__
> #include_next <float.h>
> #endif
> near the begin of GCC float.h. As far I verified there is no float.h in gcc-3.2, but it appears
> in gcc-3.3. The oldest 3.3 DJGPP port deleted/v2gnu/gcc331b.zip already includes DJGPP float.h
> in the begin.
> 
> I verified now that for MINGW cross-compiler (I have it installed) "#include_next <float.h>" is at end of GCC float.h.

In my native MinGW installation, there's no such include_next, FWIW.
0
Eli
5/18/2015 6:56:20 PM
On Tue, 19 May 2015 18:19:39 -0400, Hans-Bernhard Br=F6ker  =

<HBBroeker@t-online.de> wrote:
> Am 19.05.2015 um 23:58 schrieb Rod Pemberton:
>> On Tue, 19 May 2015 13:05:07 -0400, DJ Delorie <dj@delorie.com> wrote=
:

>>>> D.J.
>>>
>>> If you've been around all this time, why don't you spell
>>> my name correctly yet?
>>
>> I spelled it correctly.
>
> You're really quite full of it today, aren't you?

I don't know why you'd say that.  I did spell it correctly.
Only the first letter of a name is capitalized in English.

A common example in English is Billy Joe as in Billy Joe Smith
as BJ Smith or B.J. Smith.  E.g., if his name had been David
James Delorie, he would use DJ Delorie or D.J. Delorie.

English has a rule.  "DJ" means "D.J." and not "Dj".

As long as "DJ" insists on violating English rules by using
"DJ" instead of "Dj" he is going to have people who understand
his name to be "D.J."  End of story.


Rod Pemberton

-- =

If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?
0
Rod
5/19/2015 1:01:01 AM
On 05/18/2015 09:56 PM, Eli Zaretskii (eliz@gnu.org) wrote:
>> Date: Mon, 18 May 2015 19:05:41 +0300
>> From: "Andris Pavenis (andris.pavenis@iki.fi)" <djgpp@delorie.com>
>>
>> On 05/18/2015 06:22 PM, Ozkan Sezer (sezeroz@gmail.com) wrote:
>>> On 5/18/15, Eli Zaretskii (eliz@gnu.org) <djgpp@delorie.com> wrote:
>>>>> Date: Mon, 18 May 2015 16:06:19 +0300
>>>>> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
>>>>>
>>>>> The discussion is about we are pointing to gcc's headers directory
>>>>> for allowed includes when building djgpp itself, whereas
>>>>>
>>>>> (i) we don't need that at all anymore (it was done only to work around
>>>>> a gcc builtin problem and it got solved without needing this hack),
>>>>>
>>>>> (ii) we are building with -nostdinc which means we are self-
>>>>> sufficient, and that hack is against this,
>>>>>
>>>>> (iii) since our DBL_MAX, etc are not compile time constants but symbols,
>>>>> and gcc ones are, the binary output of several djgpp functions such as
>>>>> strtod, etc, are different with and without gcc-headers hack.
>>>>>
>>>>> Those are the reasons I am against allowing gcc's headers in djgpp
>>>>> build.
>>>> AFAIR, -nostdinc means without library headers, but it does not
>>>> preclude the headers that are internal to the compiler.
> Actually, I think we use -nostdinc to make sure that the header files
> come from the library being compiled, not from the installed
> production environment.  IOW, if you have DJGPP v2.03 installed and
> want to build a v2.05 library, you don't want to include, say, stdio.h
> that came with v2.03.
>
> Which means...
>
>>>> [...]
>> Including GCC own headers at first is expected behavior.
> ...that including GCC headers is fine, provided that it's needed.
GCC includes own headers before DJGPP ones when building user applications. As result
several DJGPP headers gets overridden by GCC ones for user applications. float.h is not the only
one. GCC provides own version of stdarg.h, stddef.h, stdint.h jne. Removing them would perhaps
cause trouble with libstdc++. GCC build process additionally provides a fixing system header files
for known incompatibilities by applying corrections to them and placing modified files into directory
which is also looked up before system header files.

I think it is best to have libc build environment as close to one used after that by users of built 
library
as possible. We need to replace installed DJGPP header ones with ones from version we are building
for that. There are however no need to replace GCC headers. It is best to expose and possibly avoid
incompatibilities between GCC and DJGPP header files as early as possible instead of hiding them by
not including GCC headers.

>
> But why is it needed?  Andris, you installed the change that added
> that 2 years ago; do you remember what was the reason for that?
Well, we discussed it recently again. Related file (time.h) is now changed not to include GCC own 
header
files directly any more.

http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2013/03/05/05:30:15

I would like however like to leave things as they are for reasons mentioned above


>
>> There is however one other thing:
>>
>> Unmodified GCC float.h does NOT include next float.h. See
>> https://github.com/gcc-mirror/gcc/blob/master/gcc/ginclude/float.h
>>
>> For example in my Linux installation  there is no float.h in /usr/include.
>>
>> Including  next float.h is an additional hack. I modified GCC float.h and put there
>> #ifdef __DJGPP__
>> #include_next <float.h>
>> #endif
>> near the begin of GCC float.h. As far I verified there is no float.h in gcc-3.2, but it appears
>> in gcc-3.3. The oldest 3.3 DJGPP port deleted/v2gnu/gcc331b.zip already includes DJGPP float.h
>> in the begin.
>>
>> I verified now that for MINGW cross-compiler (I have it installed) "#include_next <float.h>" is at end of GCC float.h.
> In my native MinGW installation, there's no such include_next, FWIW.

Fresh download of

http://garr.dl.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win32/Personal%20Builds/dongsheng-daily/4.8/gcc-4.8-win32_4.8.5-20150512.7z

shows that MINGW GCC float.h has '#include_next <float.h>' at end. Perhaps You have some different 
older version

Andris


0
Andris
5/19/2015 3:28:38 AM
Hi,

On Monday, May 18, 2015 at 1:56:43 PM UTC-5, Andris Pavenis (andris.pavenis@spam.sux) wrote:
> > Date: Mon, 18 May 2015 19:05:41 +0300
> > From: "Andris Pavenis (andris.pavenis@spam.sux)" <djgpp@spam.sux>
> 
> In my native MinGW installation, there's no such include_next, FWIW.

Just FYI, somewhat off-topic, but as you can see, Google Groups is
misattributing this message, making it seem like Andris is talking
to himself.   :-P
0
rugxulo
5/19/2015 3:46:44 AM
On Mon, 18 May 2015 13:22:57 -0400, Eli Zaretskii (eliz@gnu.org)  
<djgpp@delorie.com> wrote:

> [...] You asked questions, so I'm trying to help you
> figure things out.  You can ignore what I say if you think it's
> irrelevant, or doesn't help you.  But this reaction of yours is just
> plain rude, for no good reason (and not for the first time, either).
> I'm trying to help you as best I can, I don't think I deserve this
> attitude of yours, even if what I say sound preposterous to you.

Sigh, here we go again with Eli ...

Eli, we all know you are or once were a significant contributor to
DJGPP, who should know much about DJGPP's internals.  However, you
eventually respond this way to *EVERYBODY* ...  Usually, someone spends
an immense amount of time understanding a complicated issue for which
there is no documentation, only for you to say it doesn't work that
way in DJGPP without any further explanation of why it doesn't, or you
rudely ask them if they're sure after they just spent a huge amount of
time understanding the issue.  So, everybody gets angry with you ...
What did you expect to happen?  You then blame the other person for
being angry with you or for being rude, and then you insist you were
just attempting to help, or to help the other person understand an
issue they now know extra-thoroughly.  From my recollection, just
about everyone who has conversed with you for more than a post or
two becomes angry with you.  Given that so many people here have been
angered by you in about the _decade_ I've been reading and posting
here, have you even remotely considered that it's your response to or
perception of others which is abnormal?  ...  D.J. and Charles seem
to be the only people who haven't taken offense at one time or another
to you in all that time, but you don't respond that way to them, even
when D.J. has no knowledge of the issue at hand.

HTH,


Rod Pemberton

-- 
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?
0
Rod
5/19/2015 7:28:16 AM
> Date: Tue, 19 May 2015 06:28:38 +0300
> From: "Andris Pavenis (andris.pavenis@iki.fi)" <djgpp@delorie.com>
> 
> >> Including GCC own headers at first is expected behavior.
> > ...that including GCC headers is fine, provided that it's needed.
> GCC includes own headers before DJGPP ones when building user applications. As result
> several DJGPP headers gets overridden by GCC ones for user
> applications.

Sorry, I don't follow.  Are you talking about the situation where
"-nostdinc" is used, like we do in the library build?  If so, I think
only the headers from the explicitly mentioned -I directories are
included, and if so, the order of the directories mentioned on the
command line using -I is what determines which headers are included
first.  Isn't that true?

> I think it is best to have libc build environment as close to one
> used after that by users of built library as possible. We need to
> replace installed DJGPP header ones with ones from version we are
> building for that.

I don't think this is a practical alternative.  There should be a way
of building a library without overriding the production environment.
E.g., what if one wants to build a snapshot, or a version of the
development code that is not yet ready for prime time?  You cannot
tell users to break their production environment.

> > But why is it needed?  Andris, you installed the change that added
> > that 2 years ago; do you remember what was the reason for that?
> Well, we discussed it recently again. Related file (time.h) is now changed not to include GCC own 
> header
> files directly any more.

So this additional inclusion is not needed anymore, I guess.

> I would like however like to leave things as they are for reasons
> mentioned above

I don't yet understand those reasons, so I cannot tell if I agree.

> >> I verified now that for MINGW cross-compiler (I have it installed) "#include_next <float.h>" is at end of GCC float.h.
> > In my native MinGW installation, there's no such include_next, FWIW.
> 
> Fresh download of
> 
> http://garr.dl.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win32/Personal%20Builds/dongsheng-daily/4.8/gcc-4.8-win32_4.8.5-20150512.7z
> 
> shows that MINGW GCC float.h has '#include_next <float.h>' at end. Perhaps You have some different 
> older version

I'm using the last official mingw.org distribution of GCC, whcih is of
GCC 4.8.1.
0
Eli
5/19/2015 3:01:03 PM
> Sigh, here we go again with Eli ...

Sigh, here we go again with Rod ...

> However, you eventually respond this way to *EVERYBODY* ...

I re-read the thread, and Eli asked a perfectly valid (if unexpected)
question, and rather than respect the question, the OP disrespected
the poster.  Given that the issue is complex and yet still not fixed,
suggestions for the rare-but-possible cases are justified.  The only
people who should be insulted by such suggestions are those who have
already solved the problem, or already tried the advice indicated, not
those who are still trying to figure it out.

We've seen a lot of wierd bugs in the past, so if we suggest something
completely out of the blue, it's probably because it's happened
before.

> rudely

So you see it.  I don't.

> ask them if they're sure

Or, in this case, if they've considered the case where the compiler
might be lying to them about what it's doing.

> after they just spent a huge amount of time understanding the issue.

Yet still not solving.

> perception of others which is abnormal?  ...  D.J. and Charles seem

If you've been around all this time, why don't you spell my name
correctly yet?  "I'm insulted, and assume you're doing it on purpose
just to annoy me[*]."  Take the time to be precise in what you write,
and consider all the ways it can be read, and perhaps you'll have less
conflict with people who don't know you.  It's a lesson I've learned
the hard way over the decades.  Heck, I can't even tell when my
brother is joking in an email, and I've known him all his life.

[*] I'm not insulted, I assume you're innocently mistaken, just using
    it as an example of how people can mis-read others' posts.

> to be the only people who haven't taken offense at one time or another
> to you in all that time, but you don't respond that way to them, even
> when D.J. has no knowledge of the issue at hand.

I've gotten all sorts of responses from Eli.  Often, he's right.  He's
earned the right to suggest stupid things to me, because sometimes the
stupid is on my side.

Also, I've learned to look at conversations from the other point of
view, in case it's just a misunderstanding or miscommunication.
Remember, Eli's native language is *not* English, despite how well he
speaks it.

> HTH,

It doesn't.
0
DJ
5/19/2015 5:05:07 PM
> Sorry, I don't follow.  Are you talking about the situation where
> "-nostdinc" is used, like we do in the library build?  If so, I think
> only the headers from the explicitly mentioned -I directories are
> included, and if so, the order of the directories mentioned on the
> command line using -I is what determines which headers are included
> first.  Isn't that true?

I think they're talking about the fact that gcc will internally add
-I's for its own headers dir, ahead of the system headers dir.  This
used to be because system headers were "buggy" and gcc decided to fix
them, or system headers were missing/wrong/incompatible
(i.e. targetted their native compilers) and gcc had to provide
gcc-specific variants.

Since this is the default behavior, this is what users will see when
using djgpp, so that's the case we need to fix.  If we do something
different on the command lines in djgpp's libc makefiles to build the
djgpp library, we're just covering up the problem without fixing it.
(note: this may still be the right way to build libc, but only if
there are other reasons to do so)

This is an old problem with djgpp, we've been doing it "the djgpp way"
pretty much since the beginning, since we *also* wanted to be
compatible with Borland C, and the GCC headers weren't.  We've even
argued with upstream about which way is right.

Sometimes the gcc headers will #include_next the system headers, but
even then, they often do it at the beginning of the header so they can
"fix" bugs in the system header.  We (and apparently mingw ;) would
prefer they #include_next at the end of the header, so we can fix bugs
in the gcc headers.  IIRC we used to revisit this problem with every
gcc release, to see if there was a better way yet.
0
DJ
5/19/2015 5:14:53 PM
> Date: Tue, 19 May 2015 13:14:53 -0400
> From: DJ Delorie <dj@delorie.com>
> 
> > Sorry, I don't follow.  Are you talking about the situation where
> > "-nostdinc" is used, like we do in the library build?  If so, I think
> > only the headers from the explicitly mentioned -I directories are
> > included, and if so, the order of the directories mentioned on the
> > command line using -I is what determines which headers are included
> > first.  Isn't that true?
> 
> I think they're talking about the fact that gcc will internally add
> -I's for its own headers dir, ahead of the system headers dir.

Is that true even with -nostdinc?

> Since this is the default behavior, this is what users will see when
> using djgpp, so that's the case we need to fix.  If we do something
> different on the command lines in djgpp's libc makefiles to build the
> djgpp library, we're just covering up the problem without fixing it.
> (note: this may still be the right way to build libc, but only if
> there are other reasons to do so)

Yes, I agree.  So if we no longer have a reason to include GCC's
headers while building the library, we should remove that inclusion
from makefile.inc, I think.

> This is an old problem with djgpp, we've been doing it "the djgpp way"
> pretty much since the beginning, since we *also* wanted to be
> compatible with Borland C, and the GCC headers weren't.  We've even
> argued with upstream about which way is right.

Yep, the "NULL is zero" issue comes to mind.

> Sometimes the gcc headers will #include_next the system headers, but
> even then, they often do it at the beginning of the header so they can
> "fix" bugs in the system header.  We (and apparently mingw ;) would
> prefer they #include_next at the end of the header, so we can fix bugs
> in the gcc headers.  IIRC we used to revisit this problem with every
> gcc release, to see if there was a better way yet.

It's AFAIK the job of a platform maintainer for GCC, but I'm no longer
sure what exactly is the status of DJGPP support in GCC.  Do they
consider us a dead platform?  Debug info has been semi-broken for
years.
0
Eli
5/19/2015 5:23:43 PM
> > I think they're talking about the fact that gcc will internally add
> > -I's for its own headers dir, ahead of the system headers dir.
> 
> Is that true even with -nostdinc?

The argument is that we can't rely on that, because the users won't be
using it.

The answer, however, is no.  With --nostdinc, neither gcc's nor (I
assume, since I'm testing on Linux) djgpp's implicit includes are
included in the search list.

> Yes, I agree.  So if we no longer have a reason to include GCC's
> headers while building the library, we should remove that inclusion
> from makefile.inc, I think.

Exception: if the "reason" is "the headers are broken", then we should
instead fix the headers.  Otherwise, users will not get the same
headers as libc, and will/may still see the broken behavior.

> It's AFAIK the job of a platform maintainer for GCC,

The #include_next's are typically available for all platforms, unless
an exception is made.  That complicates things upstream.

> but I'm no longer sure what exactly is the status of DJGPP support
> in GCC.  Do they consider us a dead platform?  Debug info has been
> semi-broken for years.

We (Andris :) maintain our own port with some djgpp-specific changes
(like codegen) pushed upstream and others (like dos-isms) not.

What's wrong with the debug info?
0
DJ
5/19/2015 5:29:18 PM
> Date: Tue, 19 May 2015 13:29:18 -0400
> From: DJ Delorie <dj@delorie.com>
> 
> > Yes, I agree.  So if we no longer have a reason to include GCC's
> > headers while building the library, we should remove that inclusion
> > from makefile.inc, I think.
> 
> Exception: if the "reason" is "the headers are broken", then we should
> instead fix the headers.  Otherwise, users will not get the same
> headers as libc, and will/may still see the broken behavior.

Right.

> What's wrong with the debug info?

I don't really know, I never upgraded beyond GCC 3.4 and GDB 6.8,
because these two can still be used to debug executables with COFF
debug info.  (I need COFF for Emacs.)

Juan probably knows much more, as he built every version of GDB until
now, and it's from him that I know that COFF debugging is unusable
with latest versions of GCC and GDB.
0
Eli
5/19/2015 6:20:25 PM
On 5/4/15, Andris Pavenis (andris.pavenis@iki.fi)
<djgpp-announce@delorie.com> wrote:
> This is announcement of DJGPP 2.05 beta 1
>
> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
> Unfortunately DJGPP v2.04 was never released and old beta version slowly
> became almost unusable together with other newer DJGPP packages.
>
> More information about changes in DJGPP 2.05 beta 1 is available at
>
>      http://www.delorie.com/djgpp/doc/kb/
>
> both in sections about changes in 2.04 and 2.05. The same information is
> also
> available in file info/kb.inf in djdev205.zip
>
> It needs a lot of testing. Please test it if you have time and/or are
> interested in any of the above features. Any level of testing would be
> appreciated.

zoneinfo fails build using a 2.03-based toolchain:

i586-pc-msdosdjgpp-gcc -pipe
-DTZDIR=\"/dev/env/DJDIR~c:/djgpp~/zoneinfo\" -o zic.exe
-DHAVE_ADJTIME=0 -DHAVE_LONG_DOUBLE=1 -DHAVE_SETTIMEOFDAY=1
-DHAVE_STRERROR=1 -DHAVE_SYMLINK=0 -DHAVE_STDINT_H=1 -DSTD_INSPIRED
-DLOCALE_HOME=\"/dev/env/DJDIR~c:/djgpp~/share/locale\" -Dlint -g2
-fno-common -fstrict-aliasing -Wall -Wextra -Wbad-function-cast
-Wcast-align -Wcast-qual -Wformat=2 -Winit-self -Wmissing-declarations
-Wmissing-noreturn -Wmissing-prototypes -Wnested-externs
-Wno-format-nonliteral -Wno-sign-compare -Wno-unused-parameter
-Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings
-Wconversion -Wtraditional -O2  zic.o localtime.o asctime.o scheck.o
ialloc.o
/usr/local/cross-dj203/lib/gcc/i586-pc-msdosdjgpp/3.4.6/../../../../i586-pc-msdosdjgpp/lib/libc.a(ctime.o):ctime.c:(.text+0x11f0):
multiple definition of `_tzsetwall'
localtime.o:/home/ozzie/dj5/zoneinfo/src/localtime.c:1218: first defined here
collect2: ld returned 1 exit status
make[1]: *** [zic.exe] Error 1
make: [subs] Error 2 (ignored)

That's because tzsetwall is not stub'ed in 2.03.

Besides, djgpp versions of zoneinfo programs (date.exe, zic.exe,
zdump.exe) are built against toolchain-provided djgpp headers and
linked against the toolchain-provided djgpp libs, which doesn't
sound right: we should use the same methods building the programs
from src/utils/, I can do that if this is aggreed upon.

--
O.S.
0
Ozkan
5/19/2015 8:04:07 PM
Beware, if parts of the tzinfo package are included in libc.a, we'd
need to keep doing it the way it's currently done.
0
DJ
5/19/2015 8:42:02 PM
On 5/19/15, DJ Delorie <dj@delorie.com> wrote:
>
> Beware, if parts of the tzinfo package are included in libc.a, we'd
> need to keep doing it the way it's currently done.
>

tzsetwall() is part of libc.a:ctime.c but it is stubb'ed, therefore no
problems occur if zoneinfo is compiled using a 2.05-based toolchain.

As its build system currently is, the only way to make sure that it is
built+linked against current djgp is (i) build djgpp itself, (ii) update
your toolchain from that build, (iii) and rebuild djgpp and take tzinfo
stuff from that second build.
0
Ozkan
5/19/2015 8:58:55 PM
On Tue, 19 May 2015 13:05:07 -0400, DJ Delorie <dj@delorie.com> wrote:

>> D.J.
>
> If you've been around all this time, why don't you spell
> my name correctly yet?

I spelled it correctly.  You capitalized both letters which
in English indicates it's an abbreviation of a first and
middle name.  If it's not intended to be understood as
initials, then the second letter should be lowercased,
as in "Dj" like foreign names such as "Ng".

> "I'm insulted, and assume you're doing it on purpose
> just to annoy me[*]."
>
> [*] I'm not insulted, I assume you're innocently mistaken,
> just using it as an example of how people can mis-read
> others' posts.

Well, I should be insulted that you'd correct me for what
constitutes a spelling mistake on your part.  Although,
it's your name so you can claim it's spelled any way you
want.  You just don't have the right to correct others
when you chose to fail to follow English spelling rules.


Rod Pemberton

-- 
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?
0
Rod
5/19/2015 9:58:46 PM
On Tue, 19 May 2015 13:05:07 -0400, DJ Delorie <dj@delorie.com> wrote:

> Remember, Eli's native language is *not* English, despite how well he
> speaks it.

Well, then, he should chose to write in really bad English ...
No one would probably ever get mad at him again.

HTH,


Rod Pemberton

-- 
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?
0
Rod
5/19/2015 10:13:31 PM
Am 19.05.2015 um 23:58 schrieb Rod Pemberton:
> On Tue, 19 May 2015 13:05:07 -0400, DJ Delorie <dj@delorie.com> wrote:
>
>>> D.J.
>>
>> If you've been around all this time, why don't you spell
>> my name correctly yet?
>
> I spelled it correctly.

You're really quite full of it today, aren't you?
0
windows
5/19/2015 10:19:39 PM
On Tue, May 19, 2015 at 2:58 PM, Rod Pemberton <fork@lllljunkqwer.cpm> wrote:
> On Tue, 19 May 2015 13:05:07 -0400, DJ Delorie <dj@delorie.com> wrote:
>
>>> D.J.
>>
>>
>> If you've been around all this time, why don't you spell
>> my name correctly yet?
>
>
> I spelled it correctly.  You capitalized both letters which
> in English indicates it's an abbreviation of a first and
> middle name.  If it's not intended to be understood as
> initials, then the second letter should be lowercased,
> as in "Dj" like foreign names such as "Ng".
>
>> "I'm insulted, and assume you're doing it on purpose
>> just to annoy me[*]."
>>
>> [*] I'm not insulted, I assume you're innocently mistaken,
>> just using it as an example of how people can mis-read
>> others' posts.
>
>
> Well, I should be insulted that you'd correct me for what
> constitutes a spelling mistake on your part.  Although,
> it's your name so you can claim it's spelled any way you
> want.  You just don't have the right to correct others
> when you chose to fail to follow English spelling rules.

Please see [0][1][2].

[0] http://en.wikipedia.org/wiki/DJ_Delorie
[1] http://www.delorie.com/users/dj/
[2] http://www.delorie.com/users/dj/resume/
0
Louis
5/19/2015 10:30:43 PM
> I spelled it correctly.  You capitalized both letters which
> in English indicates it's an abbreviation of a first and
> middle name.  If it's not intended to be understood as
> initials, then the second letter should be lowercased,
> as in "Dj" like foreign names such as "Ng".

I find it amusing that you think you can tell me what my own name is.
It's my name, it's legal, and it's DJ - anything else is not my name.

(also... yes, I have the legal documents to prove it, and no, you may
not see them)
0
DJ
5/19/2015 10:34:38 PM
On Tue, 19 May 2015 13:05:07 -0400, DJ Delorie <dj@delorie.com> wrote:

>> rudely
>
> So you see it.  I don't.

This is going to sound rude, but you don't "see"
rudeness.  Well, I doubt that anyone "sees" rudeness ...

You stated you "can't even tell when my brother is
joking in an email, and I've known him all his life".

If you can't detect humor, how are you able to detect
rudeness?   I think that's a fair question.  Don't you?
If you can't detect rudeness, do you have the right
to make comments about it?  I would say you don't.


Rod Pemberton

-- 
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?
0
Rod
5/19/2015 11:02:13 PM
On Tue, 19 May 2015 18:34:38 -0400, DJ Delorie <dj@delorie.com> wrote:

>
>> I spelled it correctly.  You capitalized both letters which
>> in English indicates it's an abbreviation of a first and
>> middle name.  If it's not intended to be understood as
>> initials, then the second letter should be lowercased,
>> as in "Dj" like foreign names such as "Ng".
>
> I find it amusing that you think you can tell me what my own name is.
> It's my name, it's legal, and it's DJ - anything else is not my name.
>
> (also... yes, I have the legal documents to prove it, and no, you may
> not see them)

You still don't have the right to correct others when you chose to
fail to follow English spelling rules.  If "DJ" is your legal
first name, both capitals, then you should be well aware that it
doesn't follow conventional capitalization rules for English.  You've
most likely been aware of this for your entire life.  As such, your
just being a piece of shit by claiming that I misspelled your name.


Rod Pemberton

-- 
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?
0
Rod
5/19/2015 11:07:21 PM
See [0].  DJ is not an initialism, AFAIK.  As such, D.J. is not
correct.  Dj is not correct because his parents did not spell his name
that way in naming him.  It's not hard to understand [1].  And once
you come across his situation, you'll find his parents did a great job
in giving him a unique and memorable name [2].

[0] http://www.englishgrammar.org/common-grammar-exceptions/
[1] https://xkcd.com/327/
[2] http://en.wikipedia.org/wiki/A_Boy_Named_Sue


On Tue, May 19, 2015 at 3:59 PM, Rod Pemberton <fork@lllljunkqwer.cpm> wrote:
> On Tue, 19 May 2015 18:19:39 -0400, Hans-Bernhard Bröker
> <HBBroeker@t-online.de> wrote:
>>
>> Am 19.05.2015 um 23:58 schrieb Rod Pemberton:
>>>
>>> On Tue, 19 May 2015 13:05:07 -0400, DJ Delorie <dj@delorie.com> wrote:
>
>
>>>>> D.J.
>>>>
>>>>
>>>> If you've been around all this time, why don't you spell
>>>> my name correctly yet?
>>>
>>>
>>> I spelled it correctly.
>>
>>
>> You're really quite full of it today, aren't you?
>
>
> I don't know why you'd say that.  I did spell it correctly.
> Only the first letter of a name is capitalized in English.
>
> A common example in English is Billy Joe as in Billy Joe Smith
> as BJ Smith or B.J. Smith.  E.g., if his name had been David
> James Delorie, he would use DJ Delorie or D.J. Delorie.
>
> English has a rule.  "DJ" means "D.J." and not "Dj".
>
> As long as "DJ" insists on violating English rules by using
> "DJ" instead of "Dj" he is going to have people who understand
> his name to be "D.J."  End of story.
>
>
>
> Rod Pemberton
>
> --
> If fewer guns reduced murders, how does one explain
> Moscow, Chicago, New York, and South Africa?
>

0
Louis
5/19/2015 11:30:03 PM
> >> rudely
> >
> > So you see it.  I don't.
> 
> This is going to sound rude, but you don't "see"
> rudeness.  Well, I doubt that anyone "sees" rudeness ...

Just for the sake of completeness, the expression I abbreviated is
"You see it that way, I don't see it that way."  I'm merely noting
that point of view is important in interpreting some things.

> You stated you "can't even tell when my brother is
> joking in an email, and I've known him all his life".
>
> If you can't detect humor,

No, his humor just doesn't translate to email.  He thinks he's funny,
nobody else does.  Is it still humor?  He thinks so, I don't.

> how are you able to detect rudeness?  I think that's a fair
> question.  Don't you?

It's a fair question.  The answer is "Rudeness is what I think
rudeness is".  It's a personal opinion.  Mine is not always the same
as yours.

> If you can't detect rudeness, do you have the right
> to make comments about it?  I would say you don't.

There are no "rights" here, though.
0
DJ
5/19/2015 11:52:51 PM
> I don't know why you'd say that.  I did spell it correctly.

And the one person on the planet who's guaranteed to know better than
you, disagrees.

It's a name, not a word.  The rules of English (or any language) are
irrelevent.
0
DJ
5/19/2015 11:57:52 PM
Am 19.05.2015 20:20, schrieb Eli Zaretskii (eliz@gnu.org):
>> Date: Tue, 19 May 2015 13:29:18 -0400
>> From: DJ Delorie<dj@delorie.com>
>>
>>> Yes, I agree.  So if we no longer have a reason to include GCC's
>>> headers while building the library, we should remove that inclusion
>>> from makefile.inc, I think.
>>
>> Exception: if the "reason" is "the headers are broken", then we should
>> instead fix the headers.  Otherwise, users will not get the same
>> headers as libc, and will/may still see the broken behavior.
>
> Right.
>
>> What's wrong with the debug info?
>
> I don't really know, I never upgraded beyond GCC 3.4 and GDB 6.8,
> because these two can still be used to debug executables with COFF
> debug info.  (I need COFF for Emacs.)
>
> Juan probably knows much more, as he built every version of GDB until
> now, and it's from him that I know that COFF debugging is unusable
> with latest versions of GCC and GDB.


Today I have ported and compiled gdb-7.9.1.tar.gz.  The COFF/dwarf support is
as broken as with gdb-7.8. and later versions.  The last gdb version with working
djgpp support is gdb-7.7.1.tar.gz.  I do not think that they have intentionally
removed or brocken djgpp support.  But an inspection of the changelog file shows
that they have modified go32-nat.c but not only this one.  This change seems to be
part of a major modification or rewrite of that particular code segments.

 From Changelog-2014:

2014-03-07  Pedro Alves  <palves@redhat.com>

	* go32-nat.c: Include inf-child.h.
	(go32_ops): Delete global.
	(go32_close, go32_detach, go32_prepare_to_store, go32_can_run):
	Delete methods.
	(go32_create_inferior): Push the passed in target pointer instead
	of referencing go32_ops.
	(init_go32_ops): Delete function.  Moved parts to _initialize_go32_nat.
	(go32_target): New function, based on init_go32_ops, but inherit
	inf_child_target.
	(_initialize_go32_nat): Use go32_target.  Move parts of
	init_go32_ops here.

I have inspected those changes and they seem to have been well done.  So it is
not clear what has been brocken.
Unfortunately I have absolute no knowledge about DWARF and especially I do not
understand how the djgpp support of gdb works.  So I cannot debug nor figure out
this issue.

Unfortunately I have no other COFF/dwarf2 system to check if it is brocken too.
Of course I exclude PE-COFF.  If this target would have been brocken then
a lot of complains would have been sended to the gdb mailing list.  And of course
PE-COFF is not really the same than COFF.

I have compiled this gdb port using djdev204, gcc492 and bnu224br2.  I have
intentionally used djdev204 to avoid the inference of any bugs that may be
present in djdev205 and bnu225b (because compiled with djdev205).  The pain
is not worth to try to compile this gdb port using djdev203.  It would also
not work as the port of gdb 7.8 has already not worked.

I have compiled a simple hello-world program using the same configuration than
the one used to compile the gdb port.  It fails the same way it used to fail
with gdb 7.8.  Nothing changed compared against that version.
Please note that the same program can be flawlessly debugged using the gdb 7.7.1
port!  So this is certainly something brocken or in gdb or in bfd but not in our
libraries and ports.

For more information pleace read the thread:
<http://www.delorie.com/archives/browse.cgi?p=djgpp/2014/08/08/14:46:57>


Regards,
Juan M. Guerrero



C:\tmp\5>a
qwertz
C:\tmp\5>gdb a.exe
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i786-pc-msdosdjgpp --target=djgpp".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.exe...done.
(gdb) b main
Breakpoint 1 at 0x1ed8: file a.c, line 4.
(gdb) r
Starting program: c:/tmp/5/a.exe
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1ed8

(gdb) s
Single stepping until exit from function start,
which has no line number information.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1ed8
Cannot insert breakpoint -2.
Cannot access memory at address 0x57b0

(gdb)

0
Juan
5/20/2015 1:01:01 AM
> Date: Tue, 19 May 2015 23:04:07 +0300
> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
> 
> Besides, djgpp versions of zoneinfo programs (date.exe, zic.exe,
> zdump.exe) are built against toolchain-provided djgpp headers and
> linked against the toolchain-provided djgpp libs, which doesn't
> sound right: we should use the same methods building the programs
> from src/utils/, I can do that if this is aggreed upon.

Sounds right to me.
0
Eli
5/20/2015 2:39:36 AM
On Tue, 19 May 2015 19:30:03 -0400, Louis Santillan (lpsantil@gmail.com)  
<djgpp@delorie.com> wrote:

> See [0].  DJ is not an initialism, AFAIK.

That's not the point.

> As such, D.J. is not correct.

No, "DJ" is not correct according to English rules.  This was
stated previously.  Did you even read the thread?

As such, he has no right to hold others accountable to it
when they're unaware his name doesn't follow English rules.
That's the point.  That's what he was attempting to do.
That's wrong.  He blamed me for the faults with his name.

> Dj is not correct because his parents did not spell his name
> that way in naming him.

The point was that if he doesn't want people to think his name
is abbreviated first and second initial, then he shouldn't
capitalize both.  That's not hard to understand.  This was
also already stated previously.  Did you even read the thread?

If you read the thread, please stop responding as if you hadn't.


Rod Pemberton

-- 
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?
0
Rod
5/20/2015 11:27:48 AM
On Tue, 19 May 2015 19:57:52 -0400, DJ Delorie <dj@delorie.com> wrote:

>> I don't know why you'd say that.  I did spell it correctly.
>
> And the one person on the planet who's guaranteed to know better
> than you, disagrees.

Wrong.  I spelled it correctly according to English rules.  The fact
that you or your parents violated norms isn't my problem.  It's yours
and you have a simple solution which could prevent that from every
occuring again.  Yet, you're attempting to hold me accountable for
for you or your parents mistake or aberrant behavior.  That's wrong.
You have no right to do that.

> It's a name, not a word.

True.  And, English has rules for capitalizing and abbreviating them.

> The rules of English (or any language) are irrelevent.

No, they aren't.  You can't legitimately expect others to know
or respect the aberrant capitalization of your name.


Rod Pemberton

-- 
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?
0
Rod
5/20/2015 11:30:48 AM
On Tue, 19 May 2015 19:52:51 -0400, DJ Delorie <dj@delorie.com> wrote:

>> >> rudely
>> >
>> > So you see it.  I don't.
>>
>> This is going to sound rude, but you don't "see"
>> rudeness.  Well, I doubt that anyone "sees" rudeness ...
>
> Just for the sake of completeness, the expression I abbreviated is
> "You see it that way, I don't see it that way."  I'm merely noting
> that point of view is important in interpreting some things.
>
>> You stated you "can't even tell when my brother is
>> joking in an email, and I've known him all his life".
>>
>> If you can't detect humor,
>
> No, his humor just doesn't translate to email.  He thinks he's funny,
> nobody else does.  Is it still humor?  He thinks so, I don't.

How is that any different from my reply to Eli?  He thinks he's
helping but the way he responds he only makes others angry ...
I explained this in depth and politely.  This is documented, or
rather, archived.  Yet, you took issue with me pointing that out
to him, but you have no issue with pointing out basically the same
thing of your brother.

"Pot calling the kettle black ..."

>> how are you able to detect rudeness?  I think that's a fair
>> question.  Don't you?
>
> It's a fair question.  The answer is "Rudeness is what I think
> rudeness is".  It's a personal opinion.  Mine is not always the
> same as yours.

If everything of fact and truth is just personal opinion to you,
then what gives you the right to belittle and disrupt my serious
reply to Eli?  It's my personal opinion according to your
perspective and has every right to stand as is because "mine
is not always the same as yours."  Doesn't it?  That's the only
logical outcome given what you've stated.


Rod Pemberton

-- 
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?
0
Rod
5/20/2015 11:40:37 AM
--001a11354e16b385c8051684e5f1
Content-Type: text/plain; charset=UTF-8

On 5/20/15, Eli Zaretskii (eliz@gnu.org) <djgpp@delorie.com> wrote:
>> Date: Tue, 19 May 2015 23:04:07 +0300
>> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
>>
>> Besides, djgpp versions of zoneinfo programs (date.exe, zic.exe,
>> zdump.exe) are built against toolchain-provided djgpp headers and
>> linked against the toolchain-provided djgpp libs, which doesn't
>> sound right: we should use the same methods building the programs
>> from src/utils/, I can do that if this is aggreed upon.
>
> Sounds right to me.
>

OK then, here goes:  Attached three files z1.diff, z2.diff, z_all.diff
(and also the makefile itself atfer applying the patches, for convenience)

** z1.diff:
- zic: define as dos-zic.exe or host-zic.exe depending on cross
  or native build.
- host-zic: place in $(TOPDIR)/hostbin like other utils.
- HOST_ZIC: new var for 'host-zic' for cross-builds.
- LIBGCCA, DJGPP_DJL: copied defitinions from src/makefile.inc.
- CFLAGS: add -nostdinc -I$(TOPDIR)/include
- GCCFLAGS: (kept intact)
- zdump.exe, zic.exe, date.exe: change rules to link against
  freshly built crt0.o and libc.a.
- date.exe: remove logwtmpl.a building, because it was linking
  to locally built logwtmpl.a and logwtmp.o is simply an empty
  object for dos-targeting builds.

** z2.diff:
debug flags: made them to work old compilers too, and cleaned/tidied a bit.

** z_all.diff:
z1.diff and z2.diff combined

Cross-build-tested on linux using a gcc3.4/dj2.03 and gcc5.1/dj2.05
based toolchains.

OK for apply?

--
O.S.

--001a11354e16b385c8051684e5f1
Content-Type: text/plain; charset=US-ASCII; name="z1.diff"
Content-Disposition: attachment; filename="z1.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: file0

LSB6aWM6IGRlZmluZSBhcyBkb3MtemljLmV4ZSBvciBob3N0LXppYy5leGUgZGVwZW5kaW5nIG9u
IGNyb3NzCiAgb3IgbmF0aXZlIGJ1aWxkLgotIGhvc3QtemljOiBwbGFjZSBpbiAkKFRPUERJUikv
aG9zdGJpbiBsaWtlIG90aGVyIHV0aWxzLgotIEhPU1RfWklDOiBuZXcgdmFyIGZvciAnaG9zdC16
aWMnIGZvciBjcm9zcy1idWlsZHMuCi0gTElCR0NDQSwgREpHUFBfREpMOiBjb3BpZWQgZGVmaXRp
bmlvbnMgZnJvbSBzcmMvbWFrZWZpbGUuaW5jLgotIENGTEFHUzogYWRkIC1ub3N0ZGluYyAtSSQo
VE9QRElSKS9pbmNsdWRlCi0gR0NDRkxBR1M6IChrZXB0IGludGFjdCkKLSB6ZHVtcC5leGUsIHpp
Yy5leGUsIGRhdGUuZXhlOiBjaGFuZ2UgcnVsZXMgdG8gbGluayBhZ2FpbnN0CiAgZnJlc2hseSBi
dWlsdCBjcnQwLm8gYW5kIGxpYmMuYS4KLSBkYXRlLmV4ZTogcmVtb3ZlIGxvZ3d0bXBsLmEgYnVp
bGRpbmcsIGJlY2F1c2UgaXQgd2FzIGxpbmtpbmcKICB0byBsb2NhbGx5IGJ1aWx0IGxvZ3d0bXBs
LmEgYW5kIGxvZ3d0bXAubyBpcyBzaW1wbHkgYW4gZW1wdHkKICBvYmplY3QgZm9yIGRvcy10YXJn
ZXRpbmcgYnVpbGRzLgoKLS0tIHpvbmVpbmZvL3NyYy9tYWtlZmlsZX4KKysrIHpvbmVpbmZvL3Ny
Yy9tYWtlZmlsZQpAQCAtODcsNiArODcsMjEgQEAKIENST1NTX0dDQ19NQUpPUiA6PSAkKHdvcmQg
MywgJChzaGVsbCAuLi8uLi9zcmMvbWlzYy5leGUgfCAkKENST1NTX0dDQykgLUUgLWREIC14IGMg
LSB8IGVncmVwICdkZWZpbmVcICpfX0dOVUNfXycpKQogQ1JPU1NfR0NDX01JTk9SIDo9ICQod29y
ZCAzLCAkKHNoZWxsIC4uLy4uL3NyYy9taXNjLmV4ZSB8ICQoQ1JPU1NfR0NDKSAtRSAtZEQgLXgg
YyAtIHwgZWdyZXAgJ2RlZmluZVwgKl9fR05VQ19NSU5PUl9fJykpCiAKK2lmZXEgKCQoTElCR0ND
QSksKQorTElCR0NDQSA6PSAkKHNoZWxsICQoQ1JPU1NfR0NDKSAkKEdDQ19PUFQpIC1wcmludC1m
aWxlLW5hbWU9bGliZ2NjLmEpCitMSUJHQ0NBIDo9ICQoc3Vic3QgXCwvLCQoTElCR0NDQSkpCitl
eHBvcnQgTElCR0NDQQorZW5kaWYKKworaWZlcSAoJChESkdQUF9ESkwpLCkKK0RKR1BQX0RKTCA6
PSAkKHNoZWxsICQoQ1JPU1NfR0NDKSAkKEdDQ19PUFQpIC1wcmludC1maWxlLW5hbWU9ZGpncHAt
eC5kamwpCitpZmVxICgkKERKR1BQX0RKTCksZGpncHAteC5kamwpCitESkdQUF9ESkwgOj0gJChz
aGVsbCAkKENST1NTX0dDQykgJChHQ0NfT1BUKSAtcHJpbnQtZmlsZS1uYW1lPWRqZ3BwLmRqbCkK
K2VuZGlmCitESkdQUF9ESkwgOj0gJChzdWJzdCBcLC8sJChESkdQUF9ESkwpKQorZXhwb3J0IERK
R1BQX0RKTAorZW5kaWYKKwogIyBBIHJlcGxhY2VtZW50IGZvciAocG9zc2libHkgbWlzc2luZykg
VW5peCBwcm9ncmFtczoKIAogVVRJTD0JCSQoVE9QRElSKS9zcmMvbWlzYy5leGUKQEAgLTM0OSw3
ICszNjQsNyBAQAogCQktREhBVkVfU1RSRVJST1I9MSAtREhBVkVfU1lNTElOSz0wIC1ESEFWRV9T
VERJTlRfSD0xXAogCQktRFNURF9JTlNQSVJFRCBcCiAJCS1ETE9DQUxFX0hPTUU9XCIvZGV2L2Vu
di9ESkRJUn5jOi9kamdwcH4vc2hhcmUvbG9jYWxlXCIgXAotCQkkKENST1NTX0dDQ19ERUJVR19G
TEFHUykgLU8yCisJCSQoQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTKSAtTzIgLW5vc3RkaW5jIC1JJChU
T1BESVIpL2luY2x1ZGUKIAogIyBGbGFncyBmb3IgbmF0aXZlIGNvbXBpbGVyCiBHQ0NGTEFHUz0J
LURIQVZFX0FESlRJTUU9MCAtREhBVkVfTE9OR19ET1VCTEU9MSAtREhBVkVfU0VUVElNRU9GREFZ
PTEgXApAQCAtMzY4LDcgKzM4MywxMiBAQAogTERGTEFHUz0JJChMRkxBR1MpCiAKIEVYRUVYVD0J
CS5leGUKLXppYz0JCS4vaG9zdC16aWMKK0hPU1RfWklDPQkkKFRPUERJUikvaG9zdGJpbi96aWMk
KEVYRUVYVCkKK2lmZXEgKCQoQ1JPU1NfQlVJTEQpLDEpCit6aWM9CQkkKEhPU1RfWklDKQorZWxz
ZQoremljPQkJemljJChFWEVFWFQpCitlbmRpZgogWklDPQkJJCh6aWMpICQoWkZMQUdTKQogCiAj
IFRoZSBuYW1lIG9mIGEgUG9zaXgtY29tcGxpYW50IGBhd2snIG9uIHlvdXIgc3lzdGVtLgpAQCAt
NTA4LDcgKzUyOCw3IEBACiAJCSQoVVRJTCkgY3AgemR1bXAubWFuICQoTUFORElSKS9jYXQ4L3pk
dW1wLjgKIAkJJChVVElMKSBjcCB6aWMubWFuICQoTUFORElSKS9jYXQ4L3ppYy44CiAKLWFsbDoJ
CXR6c2VsZWN0IGhvc3QtemljIHppYyQoRVhFRVhUKSB6ZHVtcCQoRVhFRVhUKSAkKExJQk9CSlMp
CithbGw6CQl0enNlbGVjdCAkKEhPU1RfWklDKSB6aWMkKEVYRUVYVCkgemR1bXAkKEVYRUVYVCkg
JChMSUJPQkpTKQogCiBBTEw6CQlhbGwgZGF0ZSQoRVhFRVhUKQogCkBAIC01MTcsMTggKzUzNywx
OCBAQAogCQkgZWNobyAnc3RhdGljIGNoYXIgY29uc3QgVFpWRVJTSU9OW109IiQoVkVSU0lPTiki
OycgJiYgXAogCQkgZWNobyAnc3RhdGljIGNoYXIgY29uc3QgUkVQT1JUX0JVR1NfVE9bXT0iJChC
VUdFTUFJTCkiOycpID4kQAogCi16ZHVtcCQoRVhFRVhUKToJJChUWkRPQkpTKQotCQkkKENDKSAt
byAkQCAkKENGTEFHUykgJChMREZMQUdTKSAkKFRaRE9CSlMpICQoTERMSUJTKQotCQkkKENST1NT
X1NUUklQKSAkQAoremR1bXAkKEVYRUVYVCk6CSQoVFpET0JKUykgJChUT1BESVIpL2xpYi9jcnQw
Lm8gJChUT1BESVIpL2xpYi9saWJjLmEKKwkJJChDUk9TU19MRCkgLXMgJChMREZMQUdTKSAkKFRP
UERJUikvbGliL2NydDAubyAkKFRaRE9CSlMpIC1vICRAICQoVE9QRElSKS9saWIvbGliYy5hICQo
TElCR0NDQSkgLVQgJChESkdQUF9ESkwpCisJCSQoVE9QRElSKS9ob3N0YmluL3N0dWJpZnkuZXhl
ICRACiAKLWhvc3QtemljOgkkKFRaQ1NSQ1MpIHllYXJpc3R5cGUgdmVyc2lvbi5oCiskKEhPU1Rf
WklDKToJJChUWkNTUkNTKSB5ZWFyaXN0eXBlIHZlcnNpb24uaAogCQkkKEdDQykgLURUWkRJUj1c
Ii9kZXYvZW52L0RKRElSfmM6L2RqZ3Bwfi96b25laW5mb1wiIFwKIAkJJChHQ0NGTEFHUykgJChM
REZMQUdTKSAkKFRaQ1NSQ1MpICQoTERMSUJTKSAtbyAkQAogCQkkKFNUUklQKSAkQAogCi16aWMk
KEVYRUVYVCk6CSQoVFpDT0JKUykgeWVhcmlzdHlwZQotCQkkKENDKSAtbyAkQCAkKENGTEFHUykg
JChMREZMQUdTKSAkKFRaQ09CSlMpICQoTERMSUJTKQotCQkkKENST1NTX1NUUklQKSAkQAoremlj
JChFWEVFWFQpOgkkKFRaQ09CSlMpICQoVE9QRElSKS9saWIvY3J0MC5vICQoVE9QRElSKS9saWIv
bGliYy5hIHllYXJpc3R5cGUKKwkJJChDUk9TU19MRCkgLXMgJChMREZMQUdTKSAkKFRPUERJUikv
bGliL2NydDAubyAkKFRaQ09CSlMpIC1vICRAICQoVE9QRElSKS9saWIvbGliYy5hICQoTElCR0ND
QSkgLVQgJChESkdQUF9ESkwpCisJCSQoVE9QRElSKS9ob3N0YmluL3N0dWJpZnkuZXhlICRACiAK
IHllYXJpc3R5cGU6CXllYXJpc3R5cGUuc2gKIAkJJChVVElMKSBjcCB5ZWFyaXN0eXBlLnNoIHll
YXJpc3R5cGUKQEAgLTU3OCwxNSArNTk4LDkgQEAKIAkJLSQoVVRJTCkgbWtkaXIgJChMSUJESVIp
CiAJCSQoQ1JPU1NfQVIpIHJ1cyAkQCAkKExJQk9CSlMpCiAKLSMgV2UgdXNlIHRoZSBzeXN0ZW0n
cyBsb2d3dG1wIGluIHByZWZlcmVuY2UgdG8gb3VycyBpZiBhdmFpbGFibGUuCi0KLWRhdGUkKEVY
RUVYVCk6CSQoREFURU9CSlMpCi0JCSQoQ1JPU1NfQVIpIHJzIGxvZ3d0bXBsLmEgbG9nd3RtcC5v
Ci0JCSQoQ0MpICQoQ0ZMQUdTKSBkYXRlLm8gbG9jYWx0aW1lLm8gYXNjdGltZS5vIHN0cmZ0aW1l
Lm8gXAotCQkJJChMRExJQlMpIC1sYyBsb2d3dG1wbC5hIC1vICRACi0JCSQoQ1JPU1NfU1RSSVAp
ICRACi0JCSQoVVRJTCkgcm0gbG9nd3RtcGwuYQotCQkkKENST1NTX1NUUklQKSAkQAorZGF0ZSQo
RVhFRVhUKToJJChEQVRFT0JKUykgJChUT1BESVIpL2xpYi9jcnQwLm8gJChUT1BESVIpL2xpYi9s
aWJjLmEKKwkJJChDUk9TU19MRCkgLXMgJChMREZMQUdTKSAkKFRPUERJUikvbGliL2NydDAubyAk
KERBVEVPQkpTKSAtbyAkQCAkKFRPUERJUikvbGliL2xpYmMuYSAkKExJQkdDQ0EpIC1UICQoREpH
UFBfREpMKQorCQkkKFRPUERJUikvaG9zdGJpbi9zdHViaWZ5LmV4ZSAkQAogCiB0enNlbGVjdDoJ
dHpzZWxlY3Qua3NoCiAJCXNlZCBcCkBAIC02MTEsNyArNjI1LDcgQEAKIAogY2xlYW5fbWlzYzoK
IAkJJChVVElMKSBybSBjb3JlICoubyAqLm91dCB0enNlbGVjdCB6ZHVtcCQoRVhFRVhUKSB6aWMk
KEVYRUVYVCkgXAotCQkJeWVhcmlzdHlwZSBkYXRlJChFWEVFWFQpIGxvZ3d0bXBsKiAqLnRhci5n
eiBob3N0LXppYyAqLmV4ZSAqLm1hbiBcCisJCQl5ZWFyaXN0eXBlIGRhdGUkKEVYRUVYVCkgbG9n
d3RtcGwqICoudGFyLmd6ICQoSE9TVF9aSUMpICouZXhlICoubWFuIFwKIAkJCVREQVRBX2xpc3QK
IGNsZWFuOgkJY2xlYW5fbWlzYwogCQkkKFVUSUwpIHJtIC1mIC1yIHR6cHVibGljCg==
--001a11354e16b385c8051684e5f1
Content-Type: text/plain; charset=US-ASCII; name="z2.diff"
Content-Disposition: attachment; filename="z2.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: file0

ZGVidWcgZmxhZ3M6IG1hZGUgdGhlbSB0byB3b3JrIG9sZCBjb21waWxlcnMgdG9vLCBhbmQgY2xl
YW5lZC90aWRpZWQgYSBiaXQuCgotLS0gem9uZWluZm8vc3JjL21ha2VmaWxlfgorKysgem9uZWlu
Zm8vc3JjL21ha2VmaWxlCkBAIC0xNzcsOTcgKzE3Nyw0OCBAQAogIwktV3N1Z2dlc3QtYXR0cmli
dXRlPW5vcmV0dXJuIC1Xc3VnZ2VzdC1hdHRyaWJ1dGU9cHVyZSAtV3RyYW1wb2xpbmVzIFwKICMJ
LVd3cml0ZS1zdHJpbmdzCiAKK0NPTU1PTl9ERUJVR19GTEFHUyA9IC1EbGludCAtZyAtZm5vLWNv
bW1vbiAtZnN0cmljdC1hbGlhc2luZyBcCisJLVdhbGwgLVcgLVdjYXN0LWFsaWduIC1XY2FzdC1x
dWFsIC1XcG9pbnRlci1hcml0aCBcCisJLVdtaXNzaW5nLWRlY2xhcmF0aW9ucyAtV21pc3Npbmct
cHJvdG90eXBlcyAtV3N0cmljdC1wcm90b3R5cGVzIFwKKwktV25lc3RlZC1leHRlcm5zIC1Xc2hh
ZG93IC1Xd3JpdGUtc3RyaW5ncworCiAjIENyb3NzIGNvbXBpbGVyIGRlYnVnIGZsYWdzLgotQ1JP
U1NfR0NDX0RFQlVHX0ZMQUdTX0ZPUl9BTEwgPSAtRGxpbnQgLWcyIC1mbm8tY29tbW9uIC1mc3Ry
aWN0LWFsaWFzaW5nIFwKLQktV2FsbCAtV2V4dHJhIFwKLQktV2JhZC1mdW5jdGlvbi1jYXN0IC1X
Y2FzdC1hbGlnbiAtV2Nhc3QtcXVhbCBcCi0JLVdmb3JtYXQ9MiAtV2luaXQtc2VsZiBcCi0JLVdt
aXNzaW5nLWRlY2xhcmF0aW9ucyAtV21pc3Npbmctbm9yZXR1cm4gLVdtaXNzaW5nLXByb3RvdHlw
ZXMgXAotCS1XbmVzdGVkLWV4dGVybnMgLVduby1mb3JtYXQtbm9ubGl0ZXJhbCAtV25vLXNpZ24t
Y29tcGFyZSBcCi0JLVduby11bnVzZWQtcGFyYW1ldGVyICAtV3BvaW50ZXItYXJpdGggLVdzaGFk
b3cgLVdzdHJpY3QtcHJvdG90eXBlcyBcCi0JLVd3cml0ZS1zdHJpbmdzCi0KLWlmZXEgKCQoQ1JP
U1NfR0NDX01BSk9SKSwzKQotaWZlcSAoJChDUk9TU19HQ0NfTUlOT1IpLDQpCi1DUk9TU19HQ0Nf
REVCVUdfRkxBR1MgPSAkKENST1NTX0dDQ19ERUJVR19GTEFHU19GT1JfQUxMKSAtV2NvbnZlcnNp
b24gLVd0cmFkaXRpb25hbAoraWZlcSAoJChmaWx0ZXIgMiwkKENST1NTX0dDQ19NQUpPUikpLCkK
KyMgZ2NjID49IDMueAorQ1JPU1NfR0NDM19ERkxBR1MgPSAtV2JhZC1mdW5jdGlvbi1jYXN0IC1X
bm8tc2lnbi1jb21wYXJlIC1Xbm8tdW51c2VkLXBhcmFtZXRlcgoraWZlcSAoJChmaWx0ZXIgMywk
KENST1NTX0dDQ19NQUpPUikpLCkKK2lmZXEgKCQoZmlsdGVyIDQsJChDUk9TU19HQ0NfTUFKT1Ip
KSwpCisjIGdjYyA+PSA1LngKK0NST1NTX0dDQzRfREZMQUdTID0gLVduby10eXBlLWxpbWl0cwor
ZWxzZQorIyBnY2MgPj0gNC54CitpZmVxICgkKGZpbHRlciAwIDEgMiwkKENST1NTX0dDQ19NSU5P
UikpLCkKKyMgZ2NjID49IDQuMworQ1JPU1NfR0NDNF9ERkxBR1MgPSAtV25vLXR5cGUtbGltaXRz
CitlbmRpZgogZW5kaWYKIGVuZGlmCi0KLWlmZXEgKCQoQ1JPU1NfR0NDX01BSk9SKSw0KQotIGlm
ZXEgKCQoQ1JPU1NfR0NDX01JTk9SKSwwKQotQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTX1NQRUNJQUwg
PSAKLSBlbHNlCi0gIGlmZXEgKCQoQ1JPU1NfR0NDX01JTk9SKSwxKQotQ1JPU1NfR0NDX0RFQlVH
X0ZMQUdTX1NQRUNJQUwgPSAKLSAgZWxzZQotICAgaWZlcSAoJChDUk9TU19HQ0NfTUlOT1IpLDIp
Ci1DUk9TU19HQ0NfREVCVUdfRkxBR1NfU1BFQ0lBTCA9IC1Xb3Zlcmxlbmd0aC1zdHJpbmdzCi0g
ICBlbHNlCi0gICAgaWZlcSAoJChDUk9TU19HQ0NfTUlOT1IpLDMpCi1DUk9TU19HQ0NfREVCVUdf
RkxBR1NfU1BFQ0lBTCA9IC1Xb3Zlcmxlbmd0aC1zdHJpbmdzIC1Xbm8tc2lnbi1jb252ZXJzaW9u
IC1Xbm8tdHlwZS1saW1pdHMKLSAgICBlbHNlCi0gICAgIGlmZXEgKCQoQ1JPU1NfR0NDX01JTk9S
KSw0KQotQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTX1NQRUNJQUwgPSAtV292ZXJsZW5ndGgtc3RyaW5n
cyAtV25vLXNpZ24tY29udmVyc2lvbiAtV25vLXR5cGUtbGltaXRzCi0gICAgIGVsc2UKLSAgICAg
IGlmZXEgKCQoQ1JPU1NfR0NDX01JTk9SKSw1KQotQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTX1NQRUNJ
QUwgPSAtV292ZXJsZW5ndGgtc3RyaW5ncyAtV25vLXNpZ24tY29udmVyc2lvbiAtV25vLXR5cGUt
bGltaXRzCi0gICAgICBlbHNlCi0jIGdjYyA0LjYgYW5kIGxhdGVyIHdvcmtzLgotQ1JPU1NfR0ND
X0RFQlVHX0ZMQUdTX1NQRUNJQUwgPSAtV292ZXJsZW5ndGgtc3RyaW5ncyAtV25vLXNpZ24tY29u
dmVyc2lvbiAtV25vLXR5cGUtbGltaXRzIC1Xc3VnZ2VzdC1hdHRyaWJ1dGU9Y29uc3QgLVdzdWdn
ZXN0LWF0dHJpYnV0ZT1ub3JldHVybiAtV3N1Z2dlc3QtYXR0cmlidXRlPXB1cmUgLVd0cmFtcG9s
aW5lcwotICAgICAgZW5kaWYKLSAgICAgZW5kaWYKLSAgICBlbmRpZgotICAgZW5kaWYKLSAgZW5k
aWYKLUNST1NTX0dDQ19ERUJVR19GTEFHUyA9ICQoQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTX0ZPUl9B
TEwpICQoQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTX1NQRUNJQUwpCi0gZW5kaWYKIGVuZGlmCitDUk9T
U19HQ0NfREVCVUdfRkxBR1MgPSAkKENPTU1PTl9ERUJVR19GTEFHUykgJChDUk9TU19HQ0MzX0RG
TEFHUykgJChDUk9TU19HQ0M0X0RGTEFHUykKIAogIyBOYXRpdmUgY29tcGlsZXIgZGVidWcgZmxh
Z3MuCi1HQ0NfREVCVUdfRkxBR1NfRk9SX0FMTCA9IC1EbGludCAtZzIgLWZuby1jb21tb24gLWZz
dHJpY3QtYWxpYXNpbmcgXAotCS1XYWxsIC1XZXh0cmEgXAotCS1XYmFkLWZ1bmN0aW9uLWNhc3Qg
LVdjYXN0LWFsaWduIC1XY2FzdC1xdWFsIFwKLQktV2Zvcm1hdD0yIC1XaW5pdC1zZWxmIFwKLQkt
V21pc3NpbmctZGVjbGFyYXRpb25zIC1XbWlzc2luZy1ub3JldHVybiAtV21pc3NpbmctcHJvdG90
eXBlcyBcCi0JLVduZXN0ZWQtZXh0ZXJucyAtV25vLWZvcm1hdC1ub25saXRlcmFsIC1Xbm8tc2ln
bi1jb21wYXJlIFwKLQktV25vLXVudXNlZC1wYXJhbWV0ZXIgIC1XcG9pbnRlci1hcml0aCAtV3No
YWRvdyAtV3N0cmljdC1wcm90b3R5cGVzIFwKLQktV3dyaXRlLXN0cmluZ3MKLQotaWZlcSAoJChH
Q0NfTUFKT1IpLDMpCi1pZmVxICgkKEdDQ19NSU5PUiksNCkKLUdDQ19ERUJVR19GTEFHUyA9ICQo
R0NDX0RFQlVHX0ZMQUdTX0ZPUl9BTEwpIC1XY29udmVyc2lvbiAtV3RyYWRpdGlvbmFsCitpZmVx
ICgkKGZpbHRlciAyLCQoR0NDX01BSk9SKSksKQorIyBnY2MgPj0gMy54CitHQ0MzX0RFQlVHX0ZM
QUdTID0gLVdiYWQtZnVuY3Rpb24tY2FzdCAtV25vLXNpZ24tY29tcGFyZSAtV25vLXVudXNlZC1w
YXJhbWV0ZXIKK2lmZXEgKCQoZmlsdGVyIDMsJChHQ0NfTUFKT1IpKSwpCitpZmVxICgkKGZpbHRl
ciA0LCQoR0NDX01BSk9SKSksKQorIyBnY2MgPj0gNS54CitHQ0M0X0RFQlVHX0ZMQUdTID0gLVdu
by10eXBlLWxpbWl0cworZWxzZQorIyBnY2MgPj0gNC54CitpZmVxICgkKGZpbHRlciAwIDEgMiwk
KEdDQ19NSU5PUikpLCkKKyMgZ2NjID49IDQuMworR0NDNF9ERUJVR19GTEFHUyA9IC1Xbm8tdHlw
ZS1saW1pdHMKK2VuZGlmCiBlbmRpZgogZW5kaWYKLQotaWZlcSAoJChHQ0NfTUFKT1IpLDQpCi0g
aWZlcSAoJChHQ0NfTUlOT1IpLDApCi1HQ0NfREVCVUdfRkxBR1NfU1BFQ0lBTCA9IAotIGVsc2UK
LSAgaWZlcSAoJChHQ0NfTUlOT1IpLDEpCi1HQ0NfREVCVUdfRkxBR1NfU1BFQ0lBTCA9IAotICBl
bHNlCi0gICBpZmVxICgkKEdDQ19NSU5PUiksMikKLUdDQ19ERUJVR19GTEFHU19TUEVDSUFMID0g
LVdvdmVybGVuZ3RoLXN0cmluZ3MKLSAgIGVsc2UKLSAgICBpZmVxICgkKEdDQ19NSU5PUiksMykK
LUdDQ19ERUJVR19GTEFHU19TUEVDSUFMID0gLVdvdmVybGVuZ3RoLXN0cmluZ3MgLVduby1zaWdu
LWNvbnZlcnNpb24gLVduby10eXBlLWxpbWl0cwotICAgIGVsc2UKLSAgICAgaWZlcSAoJChHQ0Nf
TUlOT1IpLDQpCi1HQ0NfREVCVUdfRkxBR1NfU1BFQ0lBTCA9IC1Xb3Zlcmxlbmd0aC1zdHJpbmdz
IC1Xbm8tc2lnbi1jb252ZXJzaW9uIC1Xbm8tdHlwZS1saW1pdHMKLSAgICAgZWxzZQotICAgICAg
aWZlcSAoJChHQ0NfTUlOT1IpLDUpCi1HQ0NfREVCVUdfRkxBR1NfU1BFQ0lBTCA9IC1Xb3Zlcmxl
bmd0aC1zdHJpbmdzIC1Xbm8tc2lnbi1jb252ZXJzaW9uIC1Xbm8tdHlwZS1saW1pdHMKLSAgICAg
IGVsc2UKLSMgZ2NjIDQuNiBhbmQgbGF0ZXIgd29ya3MuCi1HQ0NfREVCVUdfRkxBR1NfU1BFQ0lB
TCA9IC1Xb3Zlcmxlbmd0aC1zdHJpbmdzIC1Xbm8tc2lnbi1jb252ZXJzaW9uIC1Xbm8tdHlwZS1s
aW1pdHMgLVdzdWdnZXN0LWF0dHJpYnV0ZT1jb25zdCAtV3N1Z2dlc3QtYXR0cmlidXRlPW5vcmV0
dXJuIC1Xc3VnZ2VzdC1hdHRyaWJ1dGU9cHVyZSAtV3RyYW1wb2xpbmVzCi0gICAgICBlbmRpZgot
ICAgICBlbmRpZgotICAgIGVuZGlmCi0gICBlbmRpZgotICBlbmRpZgotR0NDX0RFQlVHX0ZMQUdT
ID0gJChHQ0NfREVCVUdfRkxBR1NfRk9SX0FMTCkgJChHQ0NfREVCVUdfRkxBR1NfU1BFQ0lBTCkK
LSBlbmRpZgogZW5kaWYKK0dDQ19ERUJVR19GTEFHUyA9ICQoQ09NTU9OX0RFQlVHX0ZMQUdTKSAk
KEdDQzNfREVCVUdfRkxBR1MpICQoR0NDNF9ERUJVR19GTEFHUykKIAogIwogIyBJZiB5b3Ugd2Fu
dCB0byB1c2UgU3lzdGVtIFYgY29tcGF0aWJpbGl0eSBjb2RlLCBhZGQK
--001a11354e16b385c8051684e5f1
Content-Type: text/plain; charset=US-ASCII; name="z_all.diff"
Content-Disposition: attachment; filename="z_all.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: file0

ejEuZGlmZiBhbmQgejIuZGlmZiBjb21iaW5lZAoKLS0tIHpvbmVpbmZvL3NyYy9tYWtlZmlsZX4K
KysrIHpvbmVpbmZvL3NyYy9tYWtlZmlsZQpAQCAtODcsNiArODcsMjEgQEAKIENST1NTX0dDQ19N
QUpPUiA6PSAkKHdvcmQgMywgJChzaGVsbCAuLi8uLi9zcmMvbWlzYy5leGUgfCAkKENST1NTX0dD
QykgLUUgLWREIC14IGMgLSB8IGVncmVwICdkZWZpbmVcICpfX0dOVUNfXycpKQogQ1JPU1NfR0ND
X01JTk9SIDo9ICQod29yZCAzLCAkKHNoZWxsIC4uLy4uL3NyYy9taXNjLmV4ZSB8ICQoQ1JPU1Nf
R0NDKSAtRSAtZEQgLXggYyAtIHwgZWdyZXAgJ2RlZmluZVwgKl9fR05VQ19NSU5PUl9fJykpCiAK
K2lmZXEgKCQoTElCR0NDQSksKQorTElCR0NDQSA6PSAkKHNoZWxsICQoQ1JPU1NfR0NDKSAkKEdD
Q19PUFQpIC1wcmludC1maWxlLW5hbWU9bGliZ2NjLmEpCitMSUJHQ0NBIDo9ICQoc3Vic3QgXCwv
LCQoTElCR0NDQSkpCitleHBvcnQgTElCR0NDQQorZW5kaWYKKworaWZlcSAoJChESkdQUF9ESkwp
LCkKK0RKR1BQX0RKTCA6PSAkKHNoZWxsICQoQ1JPU1NfR0NDKSAkKEdDQ19PUFQpIC1wcmludC1m
aWxlLW5hbWU9ZGpncHAteC5kamwpCitpZmVxICgkKERKR1BQX0RKTCksZGpncHAteC5kamwpCitE
SkdQUF9ESkwgOj0gJChzaGVsbCAkKENST1NTX0dDQykgJChHQ0NfT1BUKSAtcHJpbnQtZmlsZS1u
YW1lPWRqZ3BwLmRqbCkKK2VuZGlmCitESkdQUF9ESkwgOj0gJChzdWJzdCBcLC8sJChESkdQUF9E
SkwpKQorZXhwb3J0IERKR1BQX0RKTAorZW5kaWYKKwogIyBBIHJlcGxhY2VtZW50IGZvciAocG9z
c2libHkgbWlzc2luZykgVW5peCBwcm9ncmFtczoKIAogVVRJTD0JCSQoVE9QRElSKS9zcmMvbWlz
Yy5leGUKQEAgLTE2Miw5NyArMTc3LDQ4IEBACiAjCS1Xc3VnZ2VzdC1hdHRyaWJ1dGU9bm9yZXR1
cm4gLVdzdWdnZXN0LWF0dHJpYnV0ZT1wdXJlIC1XdHJhbXBvbGluZXMgXAogIwktV3dyaXRlLXN0
cmluZ3MKIAorQ09NTU9OX0RFQlVHX0ZMQUdTID0gLURsaW50IC1nIC1mbm8tY29tbW9uIC1mc3Ry
aWN0LWFsaWFzaW5nIFwKKwktV2FsbCAtVyAtV2Nhc3QtYWxpZ24gLVdjYXN0LXF1YWwgLVdwb2lu
dGVyLWFyaXRoIFwKKwktV21pc3NpbmctZGVjbGFyYXRpb25zIC1XbWlzc2luZy1wcm90b3R5cGVz
IC1Xc3RyaWN0LXByb3RvdHlwZXMgXAorCS1XbmVzdGVkLWV4dGVybnMgLVdzaGFkb3cgLVd3cml0
ZS1zdHJpbmdzCisKICMgQ3Jvc3MgY29tcGlsZXIgZGVidWcgZmxhZ3MuCi1DUk9TU19HQ0NfREVC
VUdfRkxBR1NfRk9SX0FMTCA9IC1EbGludCAtZzIgLWZuby1jb21tb24gLWZzdHJpY3QtYWxpYXNp
bmcgXAotCS1XYWxsIC1XZXh0cmEgXAotCS1XYmFkLWZ1bmN0aW9uLWNhc3QgLVdjYXN0LWFsaWdu
IC1XY2FzdC1xdWFsIFwKLQktV2Zvcm1hdD0yIC1XaW5pdC1zZWxmIFwKLQktV21pc3NpbmctZGVj
bGFyYXRpb25zIC1XbWlzc2luZy1ub3JldHVybiAtV21pc3NpbmctcHJvdG90eXBlcyBcCi0JLVdu
ZXN0ZWQtZXh0ZXJucyAtV25vLWZvcm1hdC1ub25saXRlcmFsIC1Xbm8tc2lnbi1jb21wYXJlIFwK
LQktV25vLXVudXNlZC1wYXJhbWV0ZXIgIC1XcG9pbnRlci1hcml0aCAtV3NoYWRvdyAtV3N0cmlj
dC1wcm90b3R5cGVzIFwKLQktV3dyaXRlLXN0cmluZ3MKLQotaWZlcSAoJChDUk9TU19HQ0NfTUFK
T1IpLDMpCi1pZmVxICgkKENST1NTX0dDQ19NSU5PUiksNCkKLUNST1NTX0dDQ19ERUJVR19GTEFH
UyA9ICQoQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTX0ZPUl9BTEwpIC1XY29udmVyc2lvbiAtV3RyYWRp
dGlvbmFsCitpZmVxICgkKGZpbHRlciAyLCQoQ1JPU1NfR0NDX01BSk9SKSksKQorIyBnY2MgPj0g
My54CitDUk9TU19HQ0MzX0RGTEFHUyA9IC1XYmFkLWZ1bmN0aW9uLWNhc3QgLVduby1zaWduLWNv
bXBhcmUgLVduby11bnVzZWQtcGFyYW1ldGVyCitpZmVxICgkKGZpbHRlciAzLCQoQ1JPU1NfR0ND
X01BSk9SKSksKQoraWZlcSAoJChmaWx0ZXIgNCwkKENST1NTX0dDQ19NQUpPUikpLCkKKyMgZ2Nj
ID49IDUueAorQ1JPU1NfR0NDNF9ERkxBR1MgPSAtV25vLXR5cGUtbGltaXRzCitlbHNlCisjIGdj
YyA+PSA0LngKK2lmZXEgKCQoZmlsdGVyIDAgMSAyLCQoQ1JPU1NfR0NDX01JTk9SKSksKQorIyBn
Y2MgPj0gNC4zCitDUk9TU19HQ0M0X0RGTEFHUyA9IC1Xbm8tdHlwZS1saW1pdHMKIGVuZGlmCiBl
bmRpZgotCi1pZmVxICgkKENST1NTX0dDQ19NQUpPUiksNCkKLSBpZmVxICgkKENST1NTX0dDQ19N
SU5PUiksMCkKLUNST1NTX0dDQ19ERUJVR19GTEFHU19TUEVDSUFMID0gCi0gZWxzZQotICBpZmVx
ICgkKENST1NTX0dDQ19NSU5PUiksMSkKLUNST1NTX0dDQ19ERUJVR19GTEFHU19TUEVDSUFMID0g
Ci0gIGVsc2UKLSAgIGlmZXEgKCQoQ1JPU1NfR0NDX01JTk9SKSwyKQotQ1JPU1NfR0NDX0RFQlVH
X0ZMQUdTX1NQRUNJQUwgPSAtV292ZXJsZW5ndGgtc3RyaW5ncwotICAgZWxzZQotICAgIGlmZXEg
KCQoQ1JPU1NfR0NDX01JTk9SKSwzKQotQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTX1NQRUNJQUwgPSAt
V292ZXJsZW5ndGgtc3RyaW5ncyAtV25vLXNpZ24tY29udmVyc2lvbiAtV25vLXR5cGUtbGltaXRz
Ci0gICAgZWxzZQotICAgICBpZmVxICgkKENST1NTX0dDQ19NSU5PUiksNCkKLUNST1NTX0dDQ19E
RUJVR19GTEFHU19TUEVDSUFMID0gLVdvdmVybGVuZ3RoLXN0cmluZ3MgLVduby1zaWduLWNvbnZl
cnNpb24gLVduby10eXBlLWxpbWl0cwotICAgICBlbHNlCi0gICAgICBpZmVxICgkKENST1NTX0dD
Q19NSU5PUiksNSkKLUNST1NTX0dDQ19ERUJVR19GTEFHU19TUEVDSUFMID0gLVdvdmVybGVuZ3Ro
LXN0cmluZ3MgLVduby1zaWduLWNvbnZlcnNpb24gLVduby10eXBlLWxpbWl0cwotICAgICAgZWxz
ZQotIyBnY2MgNC42IGFuZCBsYXRlciB3b3Jrcy4KLUNST1NTX0dDQ19ERUJVR19GTEFHU19TUEVD
SUFMID0gLVdvdmVybGVuZ3RoLXN0cmluZ3MgLVduby1zaWduLWNvbnZlcnNpb24gLVduby10eXBl
LWxpbWl0cyAtV3N1Z2dlc3QtYXR0cmlidXRlPWNvbnN0IC1Xc3VnZ2VzdC1hdHRyaWJ1dGU9bm9y
ZXR1cm4gLVdzdWdnZXN0LWF0dHJpYnV0ZT1wdXJlIC1XdHJhbXBvbGluZXMKLSAgICAgIGVuZGlm
Ci0gICAgIGVuZGlmCi0gICAgZW5kaWYKLSAgIGVuZGlmCi0gIGVuZGlmCi1DUk9TU19HQ0NfREVC
VUdfRkxBR1MgPSAkKENST1NTX0dDQ19ERUJVR19GTEFHU19GT1JfQUxMKSAkKENST1NTX0dDQ19E
RUJVR19GTEFHU19TUEVDSUFMKQotIGVuZGlmCiBlbmRpZgorZW5kaWYKK0NST1NTX0dDQ19ERUJV
R19GTEFHUyA9ICQoQ09NTU9OX0RFQlVHX0ZMQUdTKSAkKENST1NTX0dDQzNfREZMQUdTKSAkKENS
T1NTX0dDQzRfREZMQUdTKQogCiAjIE5hdGl2ZSBjb21waWxlciBkZWJ1ZyBmbGFncy4KLUdDQ19E
RUJVR19GTEFHU19GT1JfQUxMID0gLURsaW50IC1nMiAtZm5vLWNvbW1vbiAtZnN0cmljdC1hbGlh
c2luZyBcCi0JLVdhbGwgLVdleHRyYSBcCi0JLVdiYWQtZnVuY3Rpb24tY2FzdCAtV2Nhc3QtYWxp
Z24gLVdjYXN0LXF1YWwgXAotCS1XZm9ybWF0PTIgLVdpbml0LXNlbGYgXAotCS1XbWlzc2luZy1k
ZWNsYXJhdGlvbnMgLVdtaXNzaW5nLW5vcmV0dXJuIC1XbWlzc2luZy1wcm90b3R5cGVzIFwKLQkt
V25lc3RlZC1leHRlcm5zIC1Xbm8tZm9ybWF0LW5vbmxpdGVyYWwgLVduby1zaWduLWNvbXBhcmUg
XAotCS1Xbm8tdW51c2VkLXBhcmFtZXRlciAgLVdwb2ludGVyLWFyaXRoIC1Xc2hhZG93IC1Xc3Ry
aWN0LXByb3RvdHlwZXMgXAotCS1Xd3JpdGUtc3RyaW5ncwotCi1pZmVxICgkKEdDQ19NQUpPUiks
MykKLWlmZXEgKCQoR0NDX01JTk9SKSw0KQotR0NDX0RFQlVHX0ZMQUdTID0gJChHQ0NfREVCVUdf
RkxBR1NfRk9SX0FMTCkgLVdjb252ZXJzaW9uIC1XdHJhZGl0aW9uYWwKK2lmZXEgKCQoZmlsdGVy
IDIsJChHQ0NfTUFKT1IpKSwpCisjIGdjYyA+PSAzLngKK0dDQzNfREVCVUdfRkxBR1MgPSAtV2Jh
ZC1mdW5jdGlvbi1jYXN0IC1Xbm8tc2lnbi1jb21wYXJlIC1Xbm8tdW51c2VkLXBhcmFtZXRlcgor
aWZlcSAoJChmaWx0ZXIgMywkKEdDQ19NQUpPUikpLCkKK2lmZXEgKCQoZmlsdGVyIDQsJChHQ0Nf
TUFKT1IpKSwpCisjIGdjYyA+PSA1LngKK0dDQzRfREVCVUdfRkxBR1MgPSAtV25vLXR5cGUtbGlt
aXRzCitlbHNlCisjIGdjYyA+PSA0LngKK2lmZXEgKCQoZmlsdGVyIDAgMSAyLCQoR0NDX01JTk9S
KSksKQorIyBnY2MgPj0gNC4zCitHQ0M0X0RFQlVHX0ZMQUdTID0gLVduby10eXBlLWxpbWl0cwor
ZW5kaWYKIGVuZGlmCiBlbmRpZgotCi1pZmVxICgkKEdDQ19NQUpPUiksNCkKLSBpZmVxICgkKEdD
Q19NSU5PUiksMCkKLUdDQ19ERUJVR19GTEFHU19TUEVDSUFMID0gCi0gZWxzZQotICBpZmVxICgk
KEdDQ19NSU5PUiksMSkKLUdDQ19ERUJVR19GTEFHU19TUEVDSUFMID0gCi0gIGVsc2UKLSAgIGlm
ZXEgKCQoR0NDX01JTk9SKSwyKQotR0NDX0RFQlVHX0ZMQUdTX1NQRUNJQUwgPSAtV292ZXJsZW5n
dGgtc3RyaW5ncwotICAgZWxzZQotICAgIGlmZXEgKCQoR0NDX01JTk9SKSwzKQotR0NDX0RFQlVH
X0ZMQUdTX1NQRUNJQUwgPSAtV292ZXJsZW5ndGgtc3RyaW5ncyAtV25vLXNpZ24tY29udmVyc2lv
biAtV25vLXR5cGUtbGltaXRzCi0gICAgZWxzZQotICAgICBpZmVxICgkKEdDQ19NSU5PUiksNCkK
LUdDQ19ERUJVR19GTEFHU19TUEVDSUFMID0gLVdvdmVybGVuZ3RoLXN0cmluZ3MgLVduby1zaWdu
LWNvbnZlcnNpb24gLVduby10eXBlLWxpbWl0cwotICAgICBlbHNlCi0gICAgICBpZmVxICgkKEdD
Q19NSU5PUiksNSkKLUdDQ19ERUJVR19GTEFHU19TUEVDSUFMID0gLVdvdmVybGVuZ3RoLXN0cmlu
Z3MgLVduby1zaWduLWNvbnZlcnNpb24gLVduby10eXBlLWxpbWl0cwotICAgICAgZWxzZQotIyBn
Y2MgNC42IGFuZCBsYXRlciB3b3Jrcy4KLUdDQ19ERUJVR19GTEFHU19TUEVDSUFMID0gLVdvdmVy
bGVuZ3RoLXN0cmluZ3MgLVduby1zaWduLWNvbnZlcnNpb24gLVduby10eXBlLWxpbWl0cyAtV3N1
Z2dlc3QtYXR0cmlidXRlPWNvbnN0IC1Xc3VnZ2VzdC1hdHRyaWJ1dGU9bm9yZXR1cm4gLVdzdWdn
ZXN0LWF0dHJpYnV0ZT1wdXJlIC1XdHJhbXBvbGluZXMKLSAgICAgIGVuZGlmCi0gICAgIGVuZGlm
Ci0gICAgZW5kaWYKLSAgIGVuZGlmCi0gIGVuZGlmCi1HQ0NfREVCVUdfRkxBR1MgPSAkKEdDQ19E
RUJVR19GTEFHU19GT1JfQUxMKSAkKEdDQ19ERUJVR19GTEFHU19TUEVDSUFMKQotIGVuZGlmCiBl
bmRpZgorR0NDX0RFQlVHX0ZMQUdTID0gJChDT01NT05fREVCVUdfRkxBR1MpICQoR0NDM19ERUJV
R19GTEFHUykgJChHQ0M0X0RFQlVHX0ZMQUdTKQogCiAjCiAjIElmIHlvdSB3YW50IHRvIHVzZSBT
eXN0ZW0gViBjb21wYXRpYmlsaXR5IGNvZGUsIGFkZApAQCAtMzQ5LDcgKzMxNSw3IEBACiAJCS1E
SEFWRV9TVFJFUlJPUj0xIC1ESEFWRV9TWU1MSU5LPTAgLURIQVZFX1NURElOVF9IPTFcCiAJCS1E
U1REX0lOU1BJUkVEIFwKIAkJLURMT0NBTEVfSE9NRT1cIi9kZXYvZW52L0RKRElSfmM6L2RqZ3Bw
fi9zaGFyZS9sb2NhbGVcIiBcCi0JCSQoQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTKSAtTzIKKwkJJChD
Uk9TU19HQ0NfREVCVUdfRkxBR1MpIC1PMiAtbm9zdGRpbmMgLUkkKFRPUERJUikvaW5jbHVkZQog
CiAjIEZsYWdzIGZvciBuYXRpdmUgY29tcGlsZXIKIEdDQ0ZMQUdTPQktREhBVkVfQURKVElNRT0w
IC1ESEFWRV9MT05HX0RPVUJMRT0xIC1ESEFWRV9TRVRUSU1FT0ZEQVk9MSBcCkBAIC0zNjgsNyAr
MzM0LDEyIEBACiBMREZMQUdTPQkkKExGTEFHUykKIAogRVhFRVhUPQkJLmV4ZQotemljPQkJLi9o
b3N0LXppYworSE9TVF9aSUM9CSQoVE9QRElSKS9ob3N0YmluL3ppYyQoRVhFRVhUKQoraWZlcSAo
JChDUk9TU19CVUlMRCksMSkKK3ppYz0JCSQoSE9TVF9aSUMpCitlbHNlCit6aWM9CQl6aWMkKEVY
RUVYVCkKK2VuZGlmCiBaSUM9CQkkKHppYykgJChaRkxBR1MpCiAKICMgVGhlIG5hbWUgb2YgYSBQ
b3NpeC1jb21wbGlhbnQgYGF3aycgb24geW91ciBzeXN0ZW0uCkBAIC01MDgsNyArNDc5LDcgQEAK
IAkJJChVVElMKSBjcCB6ZHVtcC5tYW4gJChNQU5ESVIpL2NhdDgvemR1bXAuOAogCQkkKFVUSUwp
IGNwIHppYy5tYW4gJChNQU5ESVIpL2NhdDgvemljLjgKIAotYWxsOgkJdHpzZWxlY3QgaG9zdC16
aWMgemljJChFWEVFWFQpIHpkdW1wJChFWEVFWFQpICQoTElCT0JKUykKK2FsbDoJCXR6c2VsZWN0
ICQoSE9TVF9aSUMpIHppYyQoRVhFRVhUKSB6ZHVtcCQoRVhFRVhUKSAkKExJQk9CSlMpCiAKIEFM
TDoJCWFsbCBkYXRlJChFWEVFWFQpCiAKQEAgLTUxNywxOCArNDg4LDE4IEBACiAJCSBlY2hvICdz
dGF0aWMgY2hhciBjb25zdCBUWlZFUlNJT05bXT0iJChWRVJTSU9OKSI7JyAmJiBcCiAJCSBlY2hv
ICdzdGF0aWMgY2hhciBjb25zdCBSRVBPUlRfQlVHU19UT1tdPSIkKEJVR0VNQUlMKSI7JykgPiRA
CiAKLXpkdW1wJChFWEVFWFQpOgkkKFRaRE9CSlMpCi0JCSQoQ0MpIC1vICRAICQoQ0ZMQUdTKSAk
KExERkxBR1MpICQoVFpET0JKUykgJChMRExJQlMpCi0JCSQoQ1JPU1NfU1RSSVApICRACit6ZHVt
cCQoRVhFRVhUKToJJChUWkRPQkpTKSAkKFRPUERJUikvbGliL2NydDAubyAkKFRPUERJUikvbGli
L2xpYmMuYQorCQkkKENST1NTX0xEKSAtcyAkKExERkxBR1MpICQoVE9QRElSKS9saWIvY3J0MC5v
ICQoVFpET0JKUykgLW8gJEAgJChUT1BESVIpL2xpYi9saWJjLmEgJChMSUJHQ0NBKSAtVCAkKERK
R1BQX0RKTCkKKwkJJChUT1BESVIpL2hvc3RiaW4vc3R1YmlmeS5leGUgJEAKIAotaG9zdC16aWM6
CSQoVFpDU1JDUykgeWVhcmlzdHlwZSB2ZXJzaW9uLmgKKyQoSE9TVF9aSUMpOgkkKFRaQ1NSQ1Mp
IHllYXJpc3R5cGUgdmVyc2lvbi5oCiAJCSQoR0NDKSAtRFRaRElSPVwiL2Rldi9lbnYvREpESVJ+
YzovZGpncHB+L3pvbmVpbmZvXCIgXAogCQkkKEdDQ0ZMQUdTKSAkKExERkxBR1MpICQoVFpDU1JD
UykgJChMRExJQlMpIC1vICRACiAJCSQoU1RSSVApICRACiAKLXppYyQoRVhFRVhUKToJJChUWkNP
QkpTKSB5ZWFyaXN0eXBlCi0JCSQoQ0MpIC1vICRAICQoQ0ZMQUdTKSAkKExERkxBR1MpICQoVFpD
T0JKUykgJChMRExJQlMpCi0JCSQoQ1JPU1NfU1RSSVApICRACit6aWMkKEVYRUVYVCk6CSQoVFpD
T0JKUykgJChUT1BESVIpL2xpYi9jcnQwLm8gJChUT1BESVIpL2xpYi9saWJjLmEgeWVhcmlzdHlw
ZQorCQkkKENST1NTX0xEKSAtcyAkKExERkxBR1MpICQoVE9QRElSKS9saWIvY3J0MC5vICQoVFpD
T0JKUykgLW8gJEAgJChUT1BESVIpL2xpYi9saWJjLmEgJChMSUJHQ0NBKSAtVCAkKERKR1BQX0RK
TCkKKwkJJChUT1BESVIpL2hvc3RiaW4vc3R1YmlmeS5leGUgJEAKIAogeWVhcmlzdHlwZToJeWVh
cmlzdHlwZS5zaAogCQkkKFVUSUwpIGNwIHllYXJpc3R5cGUuc2ggeWVhcmlzdHlwZQpAQCAtNTc4
LDE1ICs1NDksOSBAQAogCQktJChVVElMKSBta2RpciAkKExJQkRJUikKIAkJJChDUk9TU19BUikg
cnVzICRAICQoTElCT0JKUykKIAotIyBXZSB1c2UgdGhlIHN5c3RlbSdzIGxvZ3d0bXAgaW4gcHJl
ZmVyZW5jZSB0byBvdXJzIGlmIGF2YWlsYWJsZS4KLQotZGF0ZSQoRVhFRVhUKToJJChEQVRFT0JK
UykKLQkJJChDUk9TU19BUikgcnMgbG9nd3RtcGwuYSBsb2d3dG1wLm8KLQkJJChDQykgJChDRkxB
R1MpIGRhdGUubyBsb2NhbHRpbWUubyBhc2N0aW1lLm8gc3RyZnRpbWUubyBcCi0JCQkkKExETElC
UykgLWxjIGxvZ3d0bXBsLmEgLW8gJEAKLQkJJChDUk9TU19TVFJJUCkgJEAKLQkJJChVVElMKSBy
bSBsb2d3dG1wbC5hCi0JCSQoQ1JPU1NfU1RSSVApICRACitkYXRlJChFWEVFWFQpOgkkKERBVEVP
QkpTKSAkKFRPUERJUikvbGliL2NydDAubyAkKFRPUERJUikvbGliL2xpYmMuYQorCQkkKENST1NT
X0xEKSAtcyAkKExERkxBR1MpICQoVE9QRElSKS9saWIvY3J0MC5vICQoREFURU9CSlMpIC1vICRA
ICQoVE9QRElSKS9saWIvbGliYy5hICQoTElCR0NDQSkgLVQgJChESkdQUF9ESkwpCisJCSQoVE9Q
RElSKS9ob3N0YmluL3N0dWJpZnkuZXhlICRACiAKIHR6c2VsZWN0Ogl0enNlbGVjdC5rc2gKIAkJ
c2VkIFwKQEAgLTYxMSw3ICs1NzYsNyBAQAogCiBjbGVhbl9taXNjOgogCQkkKFVUSUwpIHJtIGNv
cmUgKi5vICoub3V0IHR6c2VsZWN0IHpkdW1wJChFWEVFWFQpIHppYyQoRVhFRVhUKSBcCi0JCQl5
ZWFyaXN0eXBlIGRhdGUkKEVYRUVYVCkgbG9nd3RtcGwqICoudGFyLmd6IGhvc3QtemljICouZXhl
ICoubWFuIFwKKwkJCXllYXJpc3R5cGUgZGF0ZSQoRVhFRVhUKSBsb2d3dG1wbCogKi50YXIuZ3og
JChIT1NUX1pJQykgKi5leGUgKi5tYW4gXAogCQkJVERBVEFfbGlzdAogY2xlYW46CQljbGVhbl9t
aXNjCiAJCSQoVVRJTCkgcm0gLWYgLXIgdHpwdWJsaWMK
--001a11354e16b385c8051684e5f1
Content-Type: application/octet-stream; name=makefile
Content-Disposition: attachment; filename=makefile
Content-Transfer-Encoding: base64
X-Attachment-Id: file0

IyA8cHJlPgojIFRoaXMgZmlsZSBpcyBpbiB0aGUgcHVibGljIGRvbWFpbiwgc28gY2xhcmlmaWVk
IGFzIG9mCiMgMjAwOS0wNS0xNyBieSBBcnRodXIgRGF2aWQgT2xzb24uCgojIFBhY2thZ2UgbmFt
ZSBmb3IgdGhlIGNvZGUgZGlzdHJpYnV0aW9uLgpQQUNLQUdFPQl0emNvZGUKCiMgVmVyc2lvbiBu
dW1iZXJzIG9mIHRoZSBjb2RlIGFuZCBkYXRhIGRpc3RyaWJ1dGlvbnMuClZFUlNJT049CTIwMTNk
CgojIEVtYWlsIGFkZHJlc3MgZm9yIGJ1ZyByZXBvcnRzLgpCVUdFTUFJTD0JdHpAaWFuYS5vcmcK
CiMgQ2hhbmdlIHRoZSBsaW5lIGJlbG93IGZvciB5b3VyIHRpbWUgem9uZSAoYWZ0ZXIgZmluZGlu
ZyB0aGUgem9uZSB5b3Ugd2FudCBpbgojIHRoZSB0aW1lIHpvbmUgZmlsZXMsIG9yIGFkZGluZyBp
dCB0byBhIHRpbWUgem9uZSBmaWxlKS4KIyBBbHRlcm5hdGVseSwgaWYgeW91IGRpc2NvdmVyIHlv
dSd2ZSBnb3QgdGhlIHdyb25nIHRpbWUgem9uZSwgeW91IGNhbiBqdXN0CiMJemljIC1sIHJpZ2h0
em9uZQojIHRvIGNvcnJlY3QgdGhpbmdzLgojIFVzZSB0aGUgY29tbWFuZAojCW1ha2Ugem9uZW5h
bWVzCiMgdG8gZ2V0IGEgbGlzdCBvZiB0aGUgdmFsdWVzIHlvdSBjYW4gdXNlIGZvciBMT0NBTFRJ
TUUuCgpMT0NBTFRJTUU9CUdNVAoKIyBJZiB5b3Ugd2FudCBzb21ldGhpbmcgb3RoZXIgdGhhbiBF
YXN0ZXJuIFVuaXRlZCBTdGF0ZXMgdGltZSBhcyBhIHRlbXBsYXRlCiMgZm9yIGhhbmRsaW5nIFBP
U0lYLXN0eWxlIHRpbWUgem9uZSBlbnZpcm9ubWVudCB2YXJpYWJsZXMsCiMgY2hhbmdlIHRoZSBs
aW5lIGJlbG93IChhZnRlciBmaW5kaW5nIHRoZSB6b25lIHlvdSB3YW50IGluIHRoZQojIHRpbWUg
em9uZSBmaWxlcywgb3IgYWRkaW5nIGl0IHRvIGEgdGltZSB6b25lIGZpbGUpLgojIChXaGVuIGEg
UE9TSVgtc3R5bGUgZW52aXJvbm1lbnQgdmFyaWFibGUgaXMgaGFuZGxlZCwgdGhlIHJ1bGVzIGlu
IHRoZQojIHRlbXBsYXRlIGZpbGUgYXJlIHVzZWQgdG8gZGV0ZXJtaW5lICJzcHJpbmcgZm9yd2Fy
ZCIgYW5kICJmYWxsIGJhY2siIGRheXMgYW5kCiMgdGltZXM7IHRoZSBlbnZpcm9ubWVudCB2YXJp
YWJsZSBpdHNlbGYgc3BlY2lmaWVzIFVUQyBvZmZzZXRzIG9mIHN0YW5kYXJkIGFuZAojIHN1bW1l
ciB0aW1lLikKIyBBbHRlcm5hdGVseSwgaWYgeW91IGRpc2NvdmVyIHlvdSd2ZSBnb3QgdGhlIHdy
b25nIHRpbWUgem9uZSwgeW91IGNhbiBqdXN0CiMJemljIC1wIHJpZ2h0em9uZQojIHRvIGNvcnJl
Y3QgdGhpbmdzLgojIFVzZSB0aGUgY29tbWFuZAojCW1ha2Ugem9uZW5hbWVzCiMgdG8gZ2V0IGEg
bGlzdCBvZiB0aGUgdmFsdWVzIHlvdSBjYW4gdXNlIGZvciBQT1NJWFJVTEVTLgojIElmIHlvdSB3
YW50IFBPU0lYIGNvbXBhdGliaWxpdHksIHVzZSAiQW1lcmljYS9OZXdfWW9yayIuCgpQT1NJWFJV
TEVTPQlBbWVyaWNhL05ld19Zb3JrCgojIEFsc28gc2VlIFRaREVGUlVMRVNUUklORyBiZWxvdywg
d2hpY2ggdGFrZXMgZWZmZWN0IG9ubHkKIyBpZiB0aGUgdGltZSB6b25lIGZpbGVzIGNhbm5vdCBi
ZSBhY2Nlc3NlZC4KCiMgRXZlcnl0aGluZyBnZXRzIHB1dCBpbiBzdWJkaXJlY3RvcmllcyBvZi4g
LiAuCgpUT1BESVI9CQkuLi8uLgoKIyAiQ29tcGlsZWQiIHRpbWUgem9uZSBpbmZvcm1hdGlvbiBp
cyBwbGFjZWQgaW4gdGhlICJUWkRJUiIgZGlyZWN0b3J5CiMgKGFuZCBzdWJkaXJlY3Rvcmllcyku
CiMgVXNlIGFuIGFic29sdXRlIHBhdGggbmFtZSBmb3IgVFpESVIgdW5sZXNzIHlvdSdyZSBqdXN0
IHRlc3RpbmcgdGhlIHNvZnR3YXJlLgoKVFpESVI9CQkkKFRPUERJUikvem9uZWluZm8KCiMgVHlw
ZXMgdG8gdHJ5LCBhcyBhbiBhbHRlcm5hdGl2ZSB0byB0aW1lX3QuICBpbnQ2NF90IHNob3VsZCBi
ZSBmaXJzdC4KVElNRV9UX0FMVEVSTkFUSVZFUz0gaW50NjRfdCBpbnQzMl90IHVpbnQzMl90IHVp
bnQ2NF90CgojIFRoZSAidHpzZWxlY3QiLCAiemljIiwgYW5kICJ6ZHVtcCIgY29tbWFuZHMgZ2V0
IGluc3RhbGxlZCBpbi4gLiAuCgpFVENESVI9CQkkKFRPUERJUikvZXRjCgojIElmIHlvdSAibWFr
ZSBJTlNUQUxMIiwgdGhlICJkYXRlIiBjb21tYW5kIGdldHMgaW5zdGFsbGVkIGluLiAuIC4KCkJJ
TkRJUj0JCSQoVE9QRElSKS9ldGMKCiMgTWFudWFsIHBhZ2VzIGdvIGluIHN1YmRpcmVjdG9yaWVz
IG9mLiAuIC4KClNIQVJFRElSPQkkKFRPUERJUikvc2hhcmUKTUFORElSPQkJJChTSEFSRURJUikv
bWFuCgojIExpYnJhcnkgZnVuY3Rpb25zIGFyZSBwdXQgaW4gYW4gYXJjaGl2ZSBpbiBMSUJESVIu
CgpMSUJESVI9CQkkKFRPUERJUikvbGliClRaTElCPQkJJChMSUJESVIpL2xpYnR6LmEKCiMgVGhp
cyBkZWZpbmVzIHNldmVyYWwgdmFyaWFibGVzIHRoYXQgZW5hYmxlIHpvbmVpbmZvL3NyYy8qIGZp
bGVzIHRvIGJlCiMgYnVpbHQgYm90aCBuYXRpdmVseSBhbmQgd2l0aCBjcm9zcy10b29scyBvbiBV
bml4LgoKaW5jbHVkZSAkKFRPUERJUikvc3JjL21ha2VmaWxlLmRlZgpleHBvcnQgQ1JPU1NfQlVJ
TEQKCiMgSWYgY3Jvc3MgY29tcGlsaW5nIHRoZSBuYXRpdmUgYW5kIGNyb3NzLWNvbXBpbGVyIHZl
cnNpb25zIG1heSBub3QgbWF0Y2guCiMgQWxsb3cgZGlmZmVyZW50IGZsYWcgc2V0dGluZ3MgYWNj
cm9yZGluZyB0aGUgY29tcGlsZXIgdmVyc2lvbi4KR0NDX01BSk9SIDo9ICQod29yZCAzLCAkKHNo
ZWxsIC4uLy4uL3NyYy9taXNjLmV4ZSB8ICQoR0NDKSAtRSAtZEQgLXggYyAtIHwgZWdyZXAgJ2Rl
ZmluZVwgKl9fR05VQ19fJykpCkdDQ19NSU5PUiA6PSAkKHdvcmQgMywgJChzaGVsbCAuLi8uLi9z
cmMvbWlzYy5leGUgfCAkKEdDQykgLUUgLWREIC14IGMgLSB8IGVncmVwICdkZWZpbmVcICpfX0dO
VUNfTUlOT1JfXycpKQpDUk9TU19HQ0NfTUFKT1IgOj0gJCh3b3JkIDMsICQoc2hlbGwgLi4vLi4v
c3JjL21pc2MuZXhlIHwgJChDUk9TU19HQ0MpIC1FIC1kRCAteCBjIC0gfCBlZ3JlcCAnZGVmaW5l
XCAqX19HTlVDX18nKSkKQ1JPU1NfR0NDX01JTk9SIDo9ICQod29yZCAzLCAkKHNoZWxsIC4uLy4u
L3NyYy9taXNjLmV4ZSB8ICQoQ1JPU1NfR0NDKSAtRSAtZEQgLXggYyAtIHwgZWdyZXAgJ2RlZmlu
ZVwgKl9fR05VQ19NSU5PUl9fJykpCgppZmVxICgkKExJQkdDQ0EpLCkKTElCR0NDQSA6PSAkKHNo
ZWxsICQoQ1JPU1NfR0NDKSAkKEdDQ19PUFQpIC1wcmludC1maWxlLW5hbWU9bGliZ2NjLmEpCkxJ
QkdDQ0EgOj0gJChzdWJzdCBcLC8sJChMSUJHQ0NBKSkKZXhwb3J0IExJQkdDQ0EKZW5kaWYKCmlm
ZXEgKCQoREpHUFBfREpMKSwpCkRKR1BQX0RKTCA6PSAkKHNoZWxsICQoQ1JPU1NfR0NDKSAkKEdD
Q19PUFQpIC1wcmludC1maWxlLW5hbWU9ZGpncHAteC5kamwpCmlmZXEgKCQoREpHUFBfREpMKSxk
amdwcC14LmRqbCkKREpHUFBfREpMIDo9ICQoc2hlbGwgJChDUk9TU19HQ0MpICQoR0NDX09QVCkg
LXByaW50LWZpbGUtbmFtZT1kamdwcC5kamwpCmVuZGlmCkRKR1BQX0RKTCA6PSAkKHN1YnN0IFws
LywkKERKR1BQX0RKTCkpCmV4cG9ydCBESkdQUF9ESkwKZW5kaWYKCiMgQSByZXBsYWNlbWVudCBm
b3IgKHBvc3NpYmx5IG1pc3NpbmcpIFVuaXggcHJvZ3JhbXM6CgpVVElMPQkJJChUT1BESVIpL3Ny
Yy9taXNjLmV4ZQoKIyBJZiB5b3UgYWx3YXlzIHdhbnQgdGltZSB2YWx1ZXMgaW50ZXJwcmV0ZWQg
YXMgInNlY29uZHMgc2luY2UgdGhlIGVwb2NoCiMgKG5vdCBjb3VudGluZyBsZWFwIHNlY29uZHMp
IiwgdXNlCiMJUkVETz0JCXBvc2l4X29ubHkKIyBiZWxvdy4gIElmIHlvdSBhbHdheXMgd2FudCBy
aWdodCB0aW1lIHZhbHVlcyBpbnRlcnByZXRlZCBhcyAic2Vjb25kcyBzaW5jZQojIHRoZSBlcG9j
aCIgKGNvdW50aW5nIGxlYXAgc2Vjb25kcykiLCB1c2UKIwlSRURPPQkJcmlnaHRfb25seQojIGJl
bG93LiAgSWYgeW91IHdhbnQgYm90aCBzZXRzIG9mIGRhdGEgYXZhaWxhYmxlLCB3aXRoIGxlYXAg
c2Vjb25kcyBub3QKIyBjb3VudGVkIG5vcm1hbGx5LCB1c2UKIwlSRURPPQkJcG9zaXhfcmlnaHQK
IyBiZWxvdy4gIElmIHlvdSB3YW50IGJvdGggc2V0cyBvZiBkYXRhIGF2YWlsYWJsZSwgd2l0aCBs
ZWFwIHNlY29uZHMgY291bnRlZAojIG5vcm1hbGx5LCB1c2UKIwlSRURPPQkJcmlnaHRfcG9zaXgK
IyBiZWxvdy4KIyBQT1NJWCBtYW5kYXRlcyB0aGF0IGxlYXAgc2Vjb25kcyBub3QgYmUgY291bnRl
ZDsgZm9yIGNvbXBhdGliaWxpdHkgd2l0aCBpdCwKIyB1c2UgZWl0aGVyICJwb3NpeF9vbmx5IiBv
ciAicG9zaXhfcmlnaHQiLgoKUkVETz0JCXBvc2l4X29ubHkKCiMgU2luY2UgIi4iIG1heSBub3Qg
YmUgaW4gUEFUSC4uLgoKWUVBUklTVFlQRT0JLi95ZWFyaXN0eXBlCgojIE5vbi1kZWZhdWx0IGxp
YnJhcmllcyBuZWVkZWQgdG8gbGluay4KIyBBZGQgLWxpbnRsIGlmIHlvdSB3YW50IHRvIHVzZSBg
Z2V0dGV4dCcgb24gU29sYXJpcy4KTERMSUJTPQoKIyBBZGQgdGhlIGZvbGxvd2luZyB0byB0aGUg
ZW5kIG9mIHRoZSAiQ0ZMQUdTPSIgbGluZSBhcyBuZWVkZWQuCiMgIC1ESEFWRV9BREpUSU1FPTAg
aWYgYGFkanRpbWUnIGRvZXMgbm90IGV4aXN0IChTVlIwPykKIyAgLURIQVZFX0RPU19GSUxFX05B
TUVTIGlmIGZpbGUgbmFtZXMgaGF2ZSBkcml2ZSBzcGVjaWZpZXJzIGV0Yy4gKE1TLURPUykKIyAg
LURIQVZFX0dFVFRFWFQ9MSBpZiBgZ2V0dGV4dCcgd29ya3MgKEdOVSwgTGludXgsIFNvbGFyaXMp
OyBhbHNvIHNlZSBMRExJQlMKIyAgLURIQVZFX0lOQ09NUEFUSUJMRV9DVElNRV9SPTEgaWYgeW91
ciBzeXN0ZW0ncyB0aW1lLmggZGVjbGFyZXMKIwljdGltZV9yIGFuZCBhc2N0aW1lX3IgaW5jb21w
YXRpYmx5IHdpdGggdGhlIFBPU0lYIHN0YW5kYXJkIChTb2xhcmlzIDgpLgojICAtREhBVkVfSU5U
VFlQRVNfSD0xIGlmIHlvdSBoYXZlIGEgcHJlLUM5OSBjb21waWxlciB3aXRoICJpbnR0eXBlcy5o
IgojICAtREhBVkVfU0VUVElNRU9GREFZPTAgaWYgc2V0dGltZW9mZGF5IGRvZXMgbm90IGV4aXN0
IChTVlIwPykKIyAgLURIQVZFX1NFVFRJTUVPRkRBWT0xIGlmIHNldHRpbWVvZmRheSBoYXMganVz
dCAxIGFyZyAoU1ZSNCkKIyAgLURIQVZFX1NFVFRJTUVPRkRBWT0yIGlmIHNldHRpbWVvZmRheSB1
c2VzIDJuZCBhcmcgKDQuM0JTRCkKIyAgLURIQVZFX1NFVFRJTUVPRkRBWT0zIGlmIHNldHRpbWVv
ZmRheSBpZ25vcmVzIDJuZCBhcmcgKDQuNEJTRCkKIyAgLURIQVZFX1NURElOVF9IPTEgaWYgeW91
IGhhdmUgYSBwcmUtQzk5IGNvbXBpbGVyIHdpdGggInN0ZGludC5oIgojICAtREhBVkVfU1lNTElO
Sz0wIGlmIHlvdXIgc3lzdGVtIGxhY2tzIHRoZSBzeW1saW5rIGZ1bmN0aW9uCiMgIC1ESEFWRV9T
WVNfU1RBVF9IPTAgaWYgeW91ciBjb21waWxlciBsYWNrcyBhICJzeXMvc3RhdC5oIgojICAtREhB
VkVfU1lTX1dBSVRfSD0wIGlmIHlvdXIgY29tcGlsZXIgbGFja3MgYSAic3lzL3dhaXQuaCIKIyAg
LURIQVZFX1VOSVNURF9IPTAgaWYgeW91ciBjb21waWxlciBsYWNrcyBhICJ1bmlzdGQuaCIgKE1p
Y3Jvc29mdCBDKysgNz8pCiMgIC1ESEFWRV9VVE1QWF9IPTEgaWYgeW91ciBjb21waWxlciBoYXMg
YSAidXRtcHguaCIKIyAgLURMT0NBTEVfSE9NRT1cInBhdGhcIiBpZiBsb2NhbGVzIGFyZSBpbiAi
cGF0aCIsIG5vdCAiL3Vzci9saWIvbG9jYWxlIgojICAtRE5PX1JVTl9USU1FX1dBUk5JTkdTX0FC
T1VUX1lFQVJfMjAwMF9QUk9CTEVNU19USEFOS19ZT1U9MQojCWlmIHlvdSBkbyBub3Qgd2FudCBy
dW4gdGltZSB3YXJuaW5ncyBhYm91dCBmb3JtYXRzIHRoYXQgbWF5IGNhdXNlCiMJeWVhciAyMDAw
IGdyaWVmCiMgIC1EVElNRV9UX0ZMT0FUSU5HPTEgaWYgeW91ciB0aW1lX3QgKG9yIHRpbWVfdHop
IGlzIGZsb2F0aW5nIHBvaW50CiMgIC1EdGltZV90ej1cIlRcIiB0byB1c2UgVCBhcyB0aGUgdGlt
ZV90IHR5cGUsIHJhdGhlciB0aGFuIHRoZSBzeXN0ZW0gdGltZV90CiMgIC1EVFpfRE9NQUlOPVwi
Zm9vXCIgdG8gdXNlICJmb28iIGZvciBnZXR0ZXh0IGRvbWFpbiBuYW1lOyBkZWZhdWx0IGlzICJ0
eiIKIyAgLVRUWl9ET01BSU5ESVI9XCIvcGF0aFwiIHRvIHVzZSAiL3BhdGgiIGZvciBnZXR0ZXh0
IGRpcmVjdG9yeTsKIwl0aGUgZGVmYXVsdCBpcyBzeXN0ZW0tc3VwcGxpZWQsIHR5cGljYWxseSAi
L3Vzci9saWIvbG9jYWxlIgojICAtRFRaREVGUlVMRVNUUklORz1cIixkYXRlL3RpbWUsZGF0ZS90
aW1lXCIgdG8gZGVmYXVsdCB0byB0aGUgc3BlY2lmaWVkCiMJRFNUIHRyYW5zaXRpb25zIGlmIHRo
ZSB0aW1lIHpvbmUgZmlsZXMgY2Fubm90IGJlIGFjY2Vzc2VkCiMgIC1EWklDX01BWF9BQkJSX0xF
Tl9XT19XQVJOPTMKIwkob3Igc29tZSBvdGhlciBudW1iZXIpIHRvIHNldCB0aGUgbWF4aW11bSB0
aW1lIHpvbmUgYWJicmV2aWF0aW9uIGxlbmd0aAojCXRoYXQgemljIHdpbGwgYWNjZXB0IHdpdGhv
dXQgYSB3YXJuaW5nICh0aGUgZGVmYXVsdCBpcyA2KQojICAkKEdDQ19ERUJVR19GTEFHUykgaWYg
eW91IGFyZSB1c2luZyBHQ0MgYW5kIHdhbnQgbG90cyBvZiBjaGVja2luZwojR0NDX0RFQlVHX0ZM
QUdTID0gLURsaW50IC1nMyAtTzMgLWZuby1jb21tb24gLWZzdHJpY3QtYWxpYXNpbmcgXAojCS1X
YWxsIC1XZXh0cmEgXAojCS1XYmFkLWZ1bmN0aW9uLWNhc3QgLVdjYXN0LWFsaWduIC1XY2FzdC1x
dWFsIFwKIwktV2Zvcm1hdD0yIC1XaW5pdC1zZWxmIFwKIwktV21pc3NpbmctZGVjbGFyYXRpb25z
IC1XbWlzc2luZy1ub3JldHVybiAtV21pc3NpbmctcHJvdG90eXBlcyBcCiMJLVduZXN0ZWQtZXh0
ZXJucyBcCiMJLVduby1mb3JtYXQtbm9ubGl0ZXJhbCAtV25vLXNpZ24tY29tcGFyZSAtV25vLXNp
Z24tY29udmVyc2lvbiBcCiMJLVduby10eXBlLWxpbWl0cyBcCiMJLVduby11bnVzZWQtcGFyYW1l
dGVyIC1Xb3Zlcmxlbmd0aC1zdHJpbmdzIC1XcG9pbnRlci1hcml0aCBcCiMJLVdzaGFkb3cgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV3N1Z2dlc3QtYXR0cmlidXRlPWNvbnN0IFwKIwktV3N1Z2dlc3Qt
YXR0cmlidXRlPW5vcmV0dXJuIC1Xc3VnZ2VzdC1hdHRyaWJ1dGU9cHVyZSAtV3RyYW1wb2xpbmVz
IFwKIwktV3dyaXRlLXN0cmluZ3MKCkNPTU1PTl9ERUJVR19GTEFHUyA9IC1EbGludCAtZyAtZm5v
LWNvbW1vbiAtZnN0cmljdC1hbGlhc2luZyBcCgktV2FsbCAtVyAtV2Nhc3QtYWxpZ24gLVdjYXN0
LXF1YWwgLVdwb2ludGVyLWFyaXRoIFwKCS1XbWlzc2luZy1kZWNsYXJhdGlvbnMgLVdtaXNzaW5n
LXByb3RvdHlwZXMgLVdzdHJpY3QtcHJvdG90eXBlcyBcCgktV25lc3RlZC1leHRlcm5zIC1Xc2hh
ZG93IC1Xd3JpdGUtc3RyaW5ncwoKIyBDcm9zcyBjb21waWxlciBkZWJ1ZyBmbGFncy4KaWZlcSAo
JChmaWx0ZXIgMiwkKENST1NTX0dDQ19NQUpPUikpLCkKIyBnY2MgPj0gMy54CkNST1NTX0dDQzNf
REZMQUdTID0gLVdiYWQtZnVuY3Rpb24tY2FzdCAtV25vLXNpZ24tY29tcGFyZSAtV25vLXVudXNl
ZC1wYXJhbWV0ZXIKaWZlcSAoJChmaWx0ZXIgMywkKENST1NTX0dDQ19NQUpPUikpLCkKaWZlcSAo
JChmaWx0ZXIgNCwkKENST1NTX0dDQ19NQUpPUikpLCkKIyBnY2MgPj0gNS54CkNST1NTX0dDQzRf
REZMQUdTID0gLVduby10eXBlLWxpbWl0cwplbHNlCiMgZ2NjID49IDQueAppZmVxICgkKGZpbHRl
ciAwIDEgMiwkKENST1NTX0dDQ19NSU5PUikpLCkKIyBnY2MgPj0gNC4zCkNST1NTX0dDQzRfREZM
QUdTID0gLVduby10eXBlLWxpbWl0cwplbmRpZgplbmRpZgplbmRpZgplbmRpZgpDUk9TU19HQ0Nf
REVCVUdfRkxBR1MgPSAkKENPTU1PTl9ERUJVR19GTEFHUykgJChDUk9TU19HQ0MzX0RGTEFHUykg
JChDUk9TU19HQ0M0X0RGTEFHUykKCiMgTmF0aXZlIGNvbXBpbGVyIGRlYnVnIGZsYWdzLgppZmVx
ICgkKGZpbHRlciAyLCQoR0NDX01BSk9SKSksKQojIGdjYyA+PSAzLngKR0NDM19ERUJVR19GTEFH
UyA9IC1XYmFkLWZ1bmN0aW9uLWNhc3QgLVduby1zaWduLWNvbXBhcmUgLVduby11bnVzZWQtcGFy
YW1ldGVyCmlmZXEgKCQoZmlsdGVyIDMsJChHQ0NfTUFKT1IpKSwpCmlmZXEgKCQoZmlsdGVyIDQs
JChHQ0NfTUFKT1IpKSwpCiMgZ2NjID49IDUueApHQ0M0X0RFQlVHX0ZMQUdTID0gLVduby10eXBl
LWxpbWl0cwplbHNlCiMgZ2NjID49IDQueAppZmVxICgkKGZpbHRlciAwIDEgMiwkKEdDQ19NSU5P
UikpLCkKIyBnY2MgPj0gNC4zCkdDQzRfREVCVUdfRkxBR1MgPSAtV25vLXR5cGUtbGltaXRzCmVu
ZGlmCmVuZGlmCmVuZGlmCmVuZGlmCkdDQ19ERUJVR19GTEFHUyA9ICQoQ09NTU9OX0RFQlVHX0ZM
QUdTKSAkKEdDQzNfREVCVUdfRkxBR1MpICQoR0NDNF9ERUJVR19GTEFHUykKCiMKIyBJZiB5b3Ug
d2FudCB0byB1c2UgU3lzdGVtIFYgY29tcGF0aWJpbGl0eSBjb2RlLCBhZGQKIwktRFVTR19DT01Q
QVQKIyB0byB0aGUgZW5kIG9mIHRoZSAiQ0ZMQUdTPSIgbGluZS4gIFRoaXMgYXJyYW5nZSBmb3Ig
InRpbWV6b25lIiBhbmQgImRheWxpZ2h0IgojIHZhcmlhYmxlcyB0byBiZSBrZXB0IHVwLXRvLWRh
dGUgYnkgdGhlIHRpbWUgY29udmVyc2lvbiBmdW5jdGlvbnMuICBOZWl0aGVyCiMgInRpbWV6b25l
IiBub3IgImRheWxpZ2h0IiBpcyBkZXNjcmliZWQgaW4gWDNKMTEncyB3b3JrLgojCiMgSWYgeW91
ciBzeXN0ZW0gaGFzIGEgIkdNVCBvZmZzZXQiIGZpZWxkIGluIGl0cyAic3RydWN0IHRtInMKIyAo
b3IgaWYgeW91IGRlY2lkZSB0byBhZGQgc3VjaCBhIGZpZWxkIGluIHlvdXIgc3lzdGVtJ3MgInRp
bWUuaCIgZmlsZSksCiMgYWRkIHRoZSBuYW1lIHRvIGEgZGVmaW5lIHN1Y2ggYXMKIwktRFRNX0dN
VE9GRj10bV9nbXRvZmYKIyBvcgojCS1EVE1fR01UT0ZGPV90bV9nbXRvZmYKIyB0byB0aGUgZW5k
IG9mIHRoZSAiQ0ZMQUdTPSIgbGluZS4KIyBOZWl0aGVyIHRtX2dtdG9mZiBub3IgX3RtX2dtdG9m
ZiBpcyBkZXNjcmliZWQgaW4gWDNKMTEncyB3b3JrOwojIGluIGl0cyB3b3JrLCB1c2Ugb2YgInRt
X2dtdG9mZiIgaXMgZGVzY3JpYmVkIGFzIG5vbi1jb25mb3JtaW5nLgojIEJvdGggTGludXggYW5k
IEJTRCBoYXZlIGRvbmUgdGhlIGVxdWl2YWxlbnQgb2YgZGVmaW5pbmcgVE1fR01UT0ZGIGluCiMg
dGhlaXIgcmVjZW50IHJlbGVhc2VzLgojCiMgSWYgeW91ciBzeXN0ZW0gaGFzIGEgInpvbmUgYWJi
cmV2aWF0aW9uIiBmaWVsZCBpbiBpdHMgInN0cnVjdCB0bSJzCiMgKG9yIGlmIHlvdSBkZWNpZGUg
dG8gYWRkIHN1Y2ggYSBmaWVsZCBpbiB5b3VyIHN5c3RlbSdzICJ0aW1lLmgiIGZpbGUpLAojIGFk
ZCB0aGUgbmFtZSB0byBhIGRlZmluZSBzdWNoIGFzCiMJLURUTV9aT05FPXRtX3pvbmUKIyBvcgoj
CS1EVE1fWk9ORT1fdG1fem9uZQojIHRvIHRoZSBlbmQgb2YgdGhlICJDRkxBR1M9IiBsaW5lLgoj
IE5laXRoZXIgdG1fem9uZSBub3IgX3RtX3pvbmUgaXMgZGVzY3JpYmVkIGluIFgzSjExJ3Mgd29y
azsKIyBpbiBpdHMgd29yaywgdXNlIG9mICJ0bV96b25lIiBpcyBkZXNjcmliZWQgYXMgbm9uLWNv
bmZvcm1pbmcuCiMgQm90aCBVQ0IgYW5kIFN1biBoYXZlIGRvbmUgdGhlIGVxdWl2YWxlbnQgb2Yg
ZGVmaW5pbmcgVE1fWk9ORSBpbgojIHRoZWlyIHJlY2VudCByZWxlYXNlcy4KIwojIElmIHlvdSB3
YW50IGZ1bmN0aW9ucyB0aGF0IHdlcmUgaW5zcGlyZWQgYnkgZWFybHkgdmVyc2lvbnMgb2YgWDNK
MTEncyB3b3JrLAojIGFkZAojCS1EU1REX0lOU1BJUkVECiMgdG8gdGhlIGVuZCBvZiB0aGUgIkNG
TEFHUz0iIGxpbmUuICBUaGlzIGFycmFuZ2VzIGZvciB0aGUgZnVuY3Rpb25zCiMgInR6c2V0d2Fs
bCIsICJvZmZ0aW1lIiwgInRpbWVsb2NhbCIsICJ0aW1lZ20iLCAidGltZW9mZiIsCiMgInBvc2l4
MnRpbWUiLCBhbmQgInRpbWUycG9zaXgiIHRvIGJlIGFkZGVkIHRvIHRoZSB0aW1lIGNvbnZlcnNp
b24gbGlicmFyeS4KIyAidHpzZXR3YWxsIiBpcyBsaWtlICJ0enNldCIgZXhjZXB0IHRoYXQgaXQg
YXJyYW5nZXMgZm9yIGxvY2FsIHdhbGwgY2xvY2sKIyB0aW1lIChyYXRoZXIgdGhhbiB0aGUgdGlt
ZSBzcGVjaWZpZWQgaW4gdGhlIFRaIGVudmlyb25tZW50IHZhcmlhYmxlKQojIHRvIGJlIHVzZWQu
CiMgIm9mZnRpbWUiIGlzIGxpa2UgImdtdGltZSIgZXhjZXB0IHRoYXQgaXQgYWNjZXB0cyBhIHNl
Y29uZCAobG9uZykgYXJndW1lbnQKIyB0aGF0IGdpdmVzIGFuIG9mZnNldCB0byBhZGQgdG8gdGhl
IHRpbWVfdCB3aGVuIGNvbnZlcnRpbmcgaXQuCiMgInRpbWVsb2NhbCIgaXMgZXF1aXZhbGVudCB0
byAibWt0aW1lIi4KIyAidGltZWdtIiBpcyBsaWtlICJ0aW1lbG9jYWwiIGV4Y2VwdCB0aGF0IGl0
IHR1cm5zIGEgc3RydWN0IHRtIGludG8KIyBhIHRpbWVfdCB1c2luZyBVVEMgKHJhdGhlciB0aGFu
IGxvY2FsIHRpbWUgYXMgInRpbWVsb2NhbCIgZG9lcykuCiMgInRpbWVvZmYiIGlzIGxpa2UgInRp
bWVnbSIgZXhjZXB0IHRoYXQgaXQgYWNjZXB0cyBhIHNlY29uZCAobG9uZykgYXJndW1lbnQKIyB0
aGF0IGdpdmVzIGFuIG9mZnNldCB0byB1c2Ugd2hlbiBjb252ZXJ0aW5nIHRvIGEgdGltZV90Lgoj
ICJwb3NpeDJ0aW1lIiBhbmQgInRpbWUycG9zaXgiIGFyZSBkZXNjcmliZWQgaW4gYW4gaW5jbHVk
ZWQgbWFudWFsIHBhZ2UuCiMgWDNKMTEncyB3b3JrIGRvZXMgbm90IGRlc2NyaWJlIGFueSBvZiB0
aGVzZSBmdW5jdGlvbnMuCiMgU3VuIGhhcyBwcm92aWRlZCAidHpzZXR3YWxsIiwgInRpbWVsb2Nh
bCIsIGFuZCAidGltZWdtIiBpbiBTdW5PUyA0LjAuCiMgVGhlc2UgZnVuY3Rpb25zIG1heSB3ZWxs
IGRpc2FwcGVhciBpbiBmdXR1cmUgcmVsZWFzZXMgb2YgdGhlIHRpbWUKIyBjb252ZXJzaW9uIHBh
Y2thZ2UuCiMKIyBJZiB5b3UnbGwgbmV2ZXIgd2FudCB0byBoYW5kbGUgc29sYXItdGltZS1iYXNl
ZCB0aW1lIHpvbmVzLCBhZGQKIwktRE5PU09MQVIKIyB0byB0aGUgZW5kIG9mIHRoZSAiQ0ZMQUdT
PSIgbGluZQojIChhbmQgY29tbWVudCBvdXQgdGhlICJTREFUQT0iIGxpbmUgYmVsb3cpLgojIFRo
aXMgcmVkdWNlcyAoc2xpZ2h0bHkpIHRoZSBydW4tdGltZSBkYXRhLXNwYWNlIHJlcXVpcmVtZW50
cyBvZgojIHRoZSB0aW1lIGNvbnZlcnNpb24gZnVuY3Rpb25zOyBpdCBtYXkgcmVkdWNlIHRoZSBh
Y2NlcHRhYmlsaXR5IG9mIHlvdXIgc3lzdGVtCiMgdG8gZm9sa3MgaW4gb2lsLSBhbmQgY2FzaC1y
aWNoIHBsYWNlcy4KIwojIElmIHlvdSB3YW50IHRvIGFsbG9jYXRlIHN0YXRlIHN0cnVjdHVyZXMg
aW4gbG9jYWx0aW1lLCBhZGQKIwktREFMTF9TVEFURQojIHRvIHRoZSBlbmQgb2YgdGhlICJDRkxB
R1M9IiBsaW5lLiAgU3RvcmFnZSBpcyBvYnRhaW5lZCBieSBjYWxsaW5nIG1hbGxvYy4KIwojIElm
IHlvdSB3YW50IGFuICJhbHR6b25lIiB2YXJpYWJsZSAoYSBsYSBTeXN0ZW0gViBSZWxlYXNlIDMu
MSksIGFkZAojCS1EQUxUWk9ORQojIHRvIHRoZSBlbmQgb2YgdGhlICJDRkxBR1M9IiBsaW5lLgoj
IFRoaXMgdmFyaWFibGUgaXMgbm90IGRlc2NyaWJlZCBpbiBYM0oxMSdzIHdvcmsuCiMKIyBJZiB5
b3Ugd2FudCBhICJndGltZSIgZnVuY3Rpb24gKGEgbGEgTUFDSCksIGFkZAojCS1EQ01VQ1MKIyB0
byB0aGUgZW5kIG9mIHRoZSAiQ0ZMQUdTPSIgbGluZQojIFRoaXMgZnVuY3Rpb24gaXMgbm90IGRl
c2NyaWJlZCBpbiBYM0oxMSdzIHdvcmsuCiMKIyBOSVNULVBDVFM6MTUxLTIsIFZlcnNpb24gMS40
LCAoMTk5My0xMi0wMykgaXMgYSB0ZXN0IHN1aXRlIHB1dAojIG91dCBieSB0aGUgTmF0aW9uYWwg
SW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neQojIHdoaWNoIGNsYWltcyB0byB0
ZXN0IEMgYW5kIFBvc2l4IGNvbmZvcm1hbmNlLiAgSWYgeW91IHdhbnQgdG8gcGFzcyBQQ1RTLCBh
ZGQKIwktRFBDVFMKIyB0byB0aGUgZW5kIG9mIHRoZSAiQ0ZMQUdTPSIgbGluZS4KIwojIElmIHlv
dSB3YW50IHN0cmljdCBjb21wbGlhbmNlIHdpdGggWFBHNCBhcyBvZiAxOTk0LTA0LTA5LCBhZGQK
IwktRFhQRzRfMTk5NF8wNF8wOQojIHRvIHRoZSBlbmQgb2YgdGhlICJDRkxBR1M9IiBsaW5lLiAg
VGhpcyBjYXVzZXMgInN0cmZ0aW1lIiB0byBhbHdheXMgcmV0dXJuCiMgNTMgYXMgYSB3ZWVrIG51
bWJlciAocmF0aGVyIHRoYW4gNTIgb3IgNTMpIGZvciB0aG9zZSBkYXlzIGluIEphbnVhcnkgdGhh
dAojIGJlZm9yZSB0aGUgZmlyc3QgTW9uZGF5IGluIEphbnVhcnkgd2hlbiBhICIlViIgZm9ybWF0
IGlzIHVzZWQgYW5kIEphbnVhcnkgMQojIGZhbGxzIG9uIGEgRnJpZGF5LCBTYXR1cmRheSwgb3Ig
U3VuZGF5LgoKIyBJZiBjcm9zcyBjb21waWxpbmcgdGhlIG5hdGl2ZSBhbmQgY3Jvc3MtY29tcGls
ZXIgdmVyc2lvbnMgbWF5IG5vdCBtYXRjaC4KIyBBbGxvdyBkaWZmZXJlbnQgZmxhZyBzZXR0aW5n
cyBhY2Nyb3JkaW5nIHRoZSBjb21waWxlciB2ZXJzaW9uLgojIEZsYWdzIGZvciBjcm9zcyBjb21w
aWxlcgpDRkxBR1M9CQktREhBVkVfQURKVElNRT0wIC1ESEFWRV9MT05HX0RPVUJMRT0xIC1ESEFW
RV9TRVRUSU1FT0ZEQVk9MSBcCgkJLURIQVZFX1NUUkVSUk9SPTEgLURIQVZFX1NZTUxJTks9MCAt
REhBVkVfU1RESU5UX0g9MVwKCQktRFNURF9JTlNQSVJFRCBcCgkJLURMT0NBTEVfSE9NRT1cIi9k
ZXYvZW52L0RKRElSfmM6L2RqZ3Bwfi9zaGFyZS9sb2NhbGVcIiBcCgkJJChDUk9TU19HQ0NfREVC
VUdfRkxBR1MpIC1PMiAtbm9zdGRpbmMgLUkkKFRPUERJUikvaW5jbHVkZQoKIyBGbGFncyBmb3Ig
bmF0aXZlIGNvbXBpbGVyCkdDQ0ZMQUdTPQktREhBVkVfQURKVElNRT0wIC1ESEFWRV9MT05HX0RP
VUJMRT0xIC1ESEFWRV9TRVRUSU1FT0ZEQVk9MSBcCgkJLURIQVZFX1NUUkVSUk9SPTEgLURIQVZF
X1NZTUxJTks9MCAtREhBVkVfU1RESU5UX0g9MSBcCgkJLURTVERfSU5TUElSRUQgXAoJCS1ETE9D
QUxFX0hPTUU9XCIvZGV2L2Vudi9ESkRJUn5jOi9kamdwcH4vc2hhcmUvbG9jYWxlXCIgXAoJCSQo
R0NDX0RFQlVHX0ZMQUdTKSAtTzIKCiMgRG9uJ3QgdXNlIC1zIGhlcmUsIHNpbmNlICJnY2MgLXMi
IG9uIERKJ3MgSXJpeCBtYWNoaW5lIGR1bXBzIGNvcmUKIyB3aGVuIGludm9rZWQgd2l0aCAtcy4g
IFRvIHdvcmsgYXJvdW5kLCB3ZSB1c2Ugc3RyaXAgZXhwbGljaXRseS4KTEZMQUdTPQoKIyBMaW5r
ZXIgZmxhZ3MuICBEZWZhdWx0IHRvICQoTEZMQUdTKSBmb3IgYmFja3dhcmRzIGNvbXBhdGliaWxp
dHkKIyB0byB0emNvZGUyMDEyaCBhbmQgZWFybGllci4KCkxERkxBR1M9CSQoTEZMQUdTKQoKRVhF
RVhUPQkJLmV4ZQpIT1NUX1pJQz0JJChUT1BESVIpL2hvc3RiaW4vemljJChFWEVFWFQpCmlmZXEg
KCQoQ1JPU1NfQlVJTEQpLDEpCnppYz0JCSQoSE9TVF9aSUMpCmVsc2UKemljPQkJemljJChFWEVF
WFQpCmVuZGlmClpJQz0JCSQoemljKSAkKFpGTEFHUykKCiMgVGhlIG5hbWUgb2YgYSBQb3NpeC1j
b21wbGlhbnQgYGF3aycgb24geW91ciBzeXN0ZW0uCkFXSz0JCWdhd2sKCiMgVGhlIGZ1bGwgcGF0
aCBuYW1lIG9mIGEgUG9zaXgtY29tcGxpYW50IHNoZWxsIHRoYXQgc3VwcG9ydHMgdGhlIEtvcm4g
c2hlbGwncwojICdzZWxlY3QnIHN0YXRlbWVudCwgYXMgYW4gZXh0ZW5zaW9uLiAgVGhlc2UgZGF5
cywgQmFzaCBpcyB0aGUgbW9zdCBwb3B1bGFyLgpLU0hFTEw9CQkvYmluL2Jhc2gKCiMgVGhlIHBh
dGggd2hlcmUgU0dNTCBEVERzIGFyZSBrZXB0LgojIFRoZSBkZWZhdWx0IGlzIGFwcHJvcHJpYXRl
IGZvciBVYnVudHUgMTIuMTAuClNHTUxfVE9QRElSPSAvdXNyClNHTUxfRFRERElSPSAkKFNHTUxf
VE9QRElSKS9zaGFyZS94bWwvdzNjLXNnbWwtbGliL3NjaGVtYS9kdGQKU0dNTF9TRUFSQ0hfUEFU
SD0gJChTR01MX0RURERJUikvUkVDLWh0bWw0MDEtMTk5OTEyMjQKCiMgVGhlIGNhdGFsb2cgZmls
ZShzKSB0byB1c2Ugd2hlbiB2YWxpZGF0aW5nLgpTR01MX0NBVEFMT0dfRklMRVM9IEhUTUw0LmNh
dAoKIyBUaGUgbmFtZSwgYXJndW1lbnRzIGFuZCBlbnZpcm9ubWVudCBvZiBhIHByb2dyYW0gdG8g
dmFsaWRhdGUgeW91ciB3ZWIgcGFnZXMuCiMgU2VlIDxodHRwOi8vd3d3LmpjbGFyay5jb20vc3Av
PiBmb3IgYSB2YWxpZGF0b3IsIGFuZAojIDxodHRwOi8vdmFsaWRhdG9yLnczLm9yZy9zb3VyY2Uv
PiBmb3IgYSB2YWxpZGF0aW9uIGxpYnJhcnkuClZBTElEQVRFID0gbnNnbWxzClZBTElEQVRFX0ZM
QUdTID0gLXMgLUIgLXdhbGwgLXduby11bnVzZWQtcGFyYW0KVkFMSURBVEVfRU5WID0gXAogIFNH
TUxfQ0FUQUxPR19GSUxFUz0kKFNHTUxfQ0FUQUxPR19GSUxFUykgXAogIFNHTUxfU0VBUkNIX1BB
VEg9JChTR01MX1NFQVJDSF9QQVRIKSBcCiAgU1BfQ0hBUlNFVF9GSVhFRD1ZRVMgXAogIFNQX0VO
Q09ESU5HPVVURi04CgojIElOVkFMSURfQ0hBUiBpcyBhIHJlZ3VsYXIgZXhwcmVzc2lvbiB0aGF0
IG1hdGNoZXMgaW52YWxpZCBjaGFyYWN0ZXJzIGluCiMgZGlzdHJpYnV0ZWQgZmlsZXMuICBGb3Ig
bm93LCBzdGljayB0byBhIHNhZmUgc3Vic2V0IG9mIEFTQ0lJLgojIFRoZSBjYWxsZXIgbXVzdCBz
ZXQgdGhlIHNoZWxsIHZhcmlhYmxlICdzaGFycCcgdG8gdGhlIGNoYXJhY3RlciAnIycsCiMgc2lu
Y2UgTWFrZWZpbGUgbWFjcm9zIGNhbm5vdCBjb250YWluICcjJy4KIyBUQUJfQ0hBUiBpcyBhIHNp
bmdsZSB0YWIgY2hhcmFjdGVyLCBpbiBzaW5nbGUgcXVvdGVzLgpUQUJfQ0hBUj0JJwknCklOVkFM
SURfQ0hBUjE9CSQoVEFCX0NIQVIpJyAhXCInJCRzaGFycCckJCUmJ1wnJygpKissLi8wMTIzNDU2
Nzg5Ojs8PT4/QCcKSU5WQUxJRF9DSEFSMj0JJ0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xc
Xl9gJwpJTlZBTElEX0NIQVIzPQknYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp7fH1+JwpJTlZB
TElEX0NIQVI9CSdbXl0nJChJTlZBTElEX0NIQVIxKSQoSU5WQUxJRF9DSEFSMikkKElOVkFMSURf
Q0hBUjMpJy1dJwoKIyBGbGFncyB0byBnaXZlICd0YXInIHdoZW4gbWFraW5nIGEgZGlzdHJpYnV0
aW9uLgojIFRyeSB0byB1c2UgZmxhZ3MgYXBwcm9wcmlhdGUgZm9yIEdOVSB0YXIuCkdOVVRBUkZM
QUdTPQktLW51bWVyaWMtb3duZXIgLS1vd25lcj0wIC0tZ3JvdXA9MCAtLW1vZGU9Z28rdSxnby13
ClRBUkZMQUdTPQlgaWYgdGFyICQoR05VVEFSRkxBR1MpIC0tdmVyc2lvbiA+L2Rldi9udWxsIDI+
JjE7IFwKCQkgdGhlbiBlY2hvICQoR05VVEFSRkxBR1MpOyBcCgkJIGVsc2UgOjsgXAoJCSBmaWAK
CiMgRmxhZ3MgdG8gZ2l2ZSAnZ3ppcCcgd2hlbiBtYWtpbmcgYSBkaXN0cmlidXRpb24uCkdaSVBG
TEFHUz0JLTluCgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCgpjYz0JCSQoQ1JPU1NfR0NDKQpDQz0J
CSQoY2MpIC1EVFpESVI9XCIvZGV2L2Vudi9ESkRJUn5jOi9kamdwcH4vem9uZWluZm9cIgoKVFpD
U1JDUz0JemljLmMgbG9jYWx0aW1lLmMgYXNjdGltZS5jIHNjaGVjay5jIGlhbGxvYy5jClRaQ09C
SlM9CXppYy5vIGxvY2FsdGltZS5vIGFzY3RpbWUubyBzY2hlY2subyBpYWxsb2MubwpUWkRTUkNT
PQl6ZHVtcC5jIGxvY2FsdGltZS5jIGlhbGxvYy5jClRaRE9CSlM9CXpkdW1wLm8gbG9jYWx0aW1l
Lm8gaWFsbG9jLm8KREFURVNSQ1M9CWRhdGUuYyBsb2NhbHRpbWUuYyBsb2d3dG1wLmMgc3RyZnRp
bWUuYyBhc2N0aW1lLmMKREFURU9CSlM9CWRhdGUubyBsb2NhbHRpbWUubyBsb2d3dG1wLm8gc3Ry
ZnRpbWUubyBhc2N0aW1lLm8KTElCU1JDUz0JbG9jYWx0aW1lLmMgYXNjdGltZS5jIGRpZmZ0aW1l
LmMKTElCT0JKUz0JbG9jYWx0aW1lLm8gYXNjdGltZS5vIGRpZmZ0aW1lLm8KSEVBREVSUz0JdHpm
aWxlLmggcHJpdmF0ZS5oCk5PTkxJQlNSQ1M9CXppYy5jIHpkdW1wLmMgc2NoZWNrLmMgaWFsbG9j
LmMKTkVXVUNCU1JDUz0JZGF0ZS5jIGxvZ3d0bXAuYyBzdHJmdGltZS5jClNPVVJDRVM9CSQoSEVB
REVSUykgJChMSUJTUkNTKSAkKE5PTkxJQlNSQ1MpICQoTkVXVUNCU1JDUykgdHpzZWxlY3Qua3No
Ck1BTlM9CQluZXdjdGltZS4zIG5ld3N0cmZ0aW1lLjMgbmV3dHpzZXQuMyB0aW1lMnBvc2l4LjMg
XAoJCQl0emZpbGUuNSB0enNlbGVjdC44IHppYy44IHpkdW1wLjgKQ09NTU9OPQkJTWFrZWZpbGUK
RE9DUz0JCVJFQURNRSBUaGVvcnkgJChNQU5TKSBkYXRlLjEKUFJJTUFSWV9ZREFUQT0JYWZyaWNh
IGFudGFyY3RpY2EgYXNpYSBhdXN0cmFsYXNpYSBcCgkJZXVyb3BlIG5vcnRoYW1lcmljYSBzb3V0
aGFtZXJpY2EKWURBVEE9CQkkKFBSSU1BUllfWURBVEEpIHBhY2lmaWNuZXcgZXRjZXRlcmEgYmFj
a3dhcmQKTkRBVEE9CQlzeXN0ZW12IGZhY3RvcnkKU0RBVEE9CQlzb2xhcjg3IHNvbGFyODggc29s
YXI4OQpUREFUQT0JCSQoWURBVEEpICQoTkRBVEEpICQoU0RBVEEpClRBQkRBVEE9CWlzbzMxNjYu
dGFiIHpvbmUudGFiCkRBVEE9CQkkKFlEQVRBKSAkKE5EQVRBKSAkKFNEQVRBKSAkKFRBQkRBVEEp
IGxlYXBzZWNvbmRzIHllYXJpc3R5cGUuc2gKV0VCX1BBR0VTPQl0ei1hcnQuaHRtIHR6LWxpbmsu
aHRtCk1JU0M9CQl1c25vMTk4OCB1c25vMTk4OSB1c25vMTk4OWEgdXNubzE5OTUgdXNubzE5OTcg
dXNubzE5OTggXAoJCQkkKFdFQl9QQUdFUykgY2hlY2t0YWIuYXdrIHdvcmttYW4uc2ggXAoJCQl6
b25laW5mbzJ0ZGYucGwKRU5DSElMQURBPQkkKENPTU1PTikgJChET0NTKSAkKFNPVVJDRVMpICQo
REFUQSkgJChNSVNDKQoKIyBBbmQgZm9yIHRoZSBiZW5lZml0IG9mIGNzaCB1c2VycyBvbiBzeXN0
ZW1zIHRoYXQgYXNzdW1lIHRoZSB1c2VyCiMgc2hlbGwgc2hvdWxkIGJlIHVzZWQgdG8gaGFuZGxl
IGNvbW1hbmRzIGluIE1ha2VmaWxlcy4gLiAuCgpTSEVMTD0JCS9iaW4vc2gKCklOU1RBTEw6CUFM
TCBpbnN0YWxsIGRhdGUuMQoJCS0kKFVUSUwpIG1rZGlyICQoVE9QRElSKQoJCS0kKFVUSUwpIG1r
ZGlyICQoQklORElSKQoJCSQoVVRJTCkgY3AgZGF0ZSQoRVhFRVhUKSAkKEJJTkRJUikvZGF0ZSQo
RVhFRVhUKQoJCS0kKFVUSUwpIG1rZGlyICQoU0hBUkVESVIpCgkJLSQoVVRJTCkgbWtkaXIgJChN
QU5ESVIpCgkJLSQoVVRJTCkgbWtkaXIgJChNQU5ESVIpL2NhdDEKCQktJChVVElMKSBybSAkKE1B
TkRJUikvY2F0MS9kYXRlLjEKCQktZ3JvZmYgLW1tYW4gLVRhc2NpaSBkYXRlLjEgPiBkYXRlLm1h
bgoJCSQoVVRJTCkgY3AgZGF0ZS5tYW4gJChNQU5ESVIpL2NhdDEvZGF0ZS4xCgppbnN0YWxsOglh
bGwgJChEQVRBKSAkKFJFRE8pICQoVFpMSUIpICQoTUFOUykgJChUQUJEQVRBKQoJCSQoWklDKSAt
eSAkKFlFQVJJU1RZUEUpIFwKCQkJLWQgJChUWkRJUikgLWwgJChMT0NBTFRJTUUpIC1wICQoUE9T
SVhSVUxFUykKCQktJChVVElMKSBybSAtZiAkKFRaRElSKS9pc28zMTY2LnRhYiAkKFRaRElSKS96
b25lLnRhYgoJCSQoVVRJTCkgY3AgaXNvMzE2Ni50YWIgJChUWkRJUikvaXNvMzE2Ni50YWIKCQkk
KFVUSUwpIGNwIHpvbmUudGFiICQoVFpESVIpL3pvbmUudGFiCgkJLSQoVVRJTCkgbWtkaXIgJChU
T1BESVIpCgkJLSQoVVRJTCkgbWtkaXIgJChFVENESVIpCgkJJChVVElMKSBjcCB6aWMkKEVYRUVY
VCkgJChFVENESVIpL3ppYyQoRVhFRVhUKQoJCSQoVVRJTCkgY3AgemR1bXAkKEVYRUVYVCkgJChF
VENESVIpL3pkdW1wJChFWEVFWFQpCgkJJChVVElMKSBjcCB0enNlbGVjdCAkKEVUQ0RJUikvdHpz
ZWxlY3QKCQktJChVVElMKSBta2RpciAkKFNIQVJFRElSKQoJCS0kKFVUSUwpIG1rZGlyICQoTUFO
RElSKQoJCS0kKFVUSUwpIG1rZGlyICQoTUFORElSKS9jYXQzCgkJLSQoVVRJTCkgbWtkaXIgJChN
QU5ESVIpL2NhdDUKCQktJChVVElMKSBta2RpciAkKE1BTkRJUikvY2F0OAoJCS0kKFVUSUwpIHJt
IC1mICQoTUFORElSKS9jYXQzL25ld2N0aW1lLjMgXAoJCQkkKE1BTkRJUikvY2F0My9uZXd0enNl
dC4zIFwKCQkJJChNQU5ESVIpL2NhdDUvdHpmaWxlLjUgXAoJCQkkKE1BTkRJUikvY2F0OC90enNl
bGVjdC44IFwKCQkJJChNQU5ESVIpL2NhdDgvemR1bXAuOCBcCgkJCSQoTUFORElSKS9jYXQ4L3pp
Yy44CgkJLWdyb2ZmIC1tbWFuIC1UYXNjaWkgbmV3Y3RpbWUuMyA+IG5ld2N0aW1lLm1hbgoJCS1n
cm9mZiAtbW1hbiAtVGFzY2lpIG5ld3R6c2V0LjMgPiBuZXd0enNldC5tYW4KCQktZ3JvZmYgLW1t
YW4gLVRhc2NpaSB0aW1lMnBvc2l4LjMgPiB0aW1lMnBvc2l4Lm1hbgoJCS1ncm9mZiAtbW1hbiAt
VGFzY2lpIHR6ZmlsZS41ID4gdHpmaWxlLm1hbgoJCS1ncm9mZiAtbW1hbiAtVGFzY2lpIHR6c2Vs
ZWN0LjggPiB0enNlbGVjdC5tYW4KCQktZ3JvZmYgLW1tYW4gLVRhc2NpaSB6ZHVtcC44ID4gemR1
bXAubWFuCgkJLWdyb2ZmIC1tbWFuIC1UYXNjaWkgemljLjggPiB6aWMubWFuCgkJJChVVElMKSBj
cCBuZXdjdGltZS5tYW4gJChNQU5ESVIpL2NhdDMvbmV3Y3RpbWUuMwoJCSQoVVRJTCkgY3AgbmV3
dHpzZXQubWFuICQoTUFORElSKS9jYXQzL25ld3R6c2V0LjMKCQkkKFVUSUwpIGNwIHRpbWUycG9z
aXgubWFuICQoTUFORElSKS9jYXQzL3RpbWUycG9zaXguMwoJCSQoVVRJTCkgY3AgdHpmaWxlLm1h
biAkKE1BTkRJUikvY2F0NS90emZpbGUuNQoJCSQoVVRJTCkgY3AgdHpzZWxlY3QubWFuICQoTUFO
RElSKS9jYXQ4L3R6c2VsZWN0LjgKCQkkKFVUSUwpIGNwIHpkdW1wLm1hbiAkKE1BTkRJUikvY2F0
OC96ZHVtcC44CgkJJChVVElMKSBjcCB6aWMubWFuICQoTUFORElSKS9jYXQ4L3ppYy44CgphbGw6
CQl0enNlbGVjdCAkKEhPU1RfWklDKSB6aWMkKEVYRUVYVCkgemR1bXAkKEVYRUVYVCkgJChMSUJP
QkpTKQoKQUxMOgkJYWxsIGRhdGUkKEVYRUVYVCkKCnZlcnNpb24uaDoKCQkoZWNobyAnc3RhdGlj
IGNoYXIgY29uc3QgUEtHVkVSU0lPTltdPSIoJChQQUNLQUdFKSkgIjsnICYmIFwKCQkgZWNobyAn
c3RhdGljIGNoYXIgY29uc3QgVFpWRVJTSU9OW109IiQoVkVSU0lPTikiOycgJiYgXAoJCSBlY2hv
ICdzdGF0aWMgY2hhciBjb25zdCBSRVBPUlRfQlVHU19UT1tdPSIkKEJVR0VNQUlMKSI7JykgPiRA
Cgp6ZHVtcCQoRVhFRVhUKToJJChUWkRPQkpTKSAkKFRPUERJUikvbGliL2NydDAubyAkKFRPUERJ
UikvbGliL2xpYmMuYQoJCSQoQ1JPU1NfTEQpIC1zICQoTERGTEFHUykgJChUT1BESVIpL2xpYi9j
cnQwLm8gJChUWkRPQkpTKSAtbyAkQCAkKFRPUERJUikvbGliL2xpYmMuYSAkKExJQkdDQ0EpIC1U
ICQoREpHUFBfREpMKQoJCSQoVE9QRElSKS9ob3N0YmluL3N0dWJpZnkuZXhlICRACgokKEhPU1Rf
WklDKToJJChUWkNTUkNTKSB5ZWFyaXN0eXBlIHZlcnNpb24uaAoJCSQoR0NDKSAtRFRaRElSPVwi
L2Rldi9lbnYvREpESVJ+YzovZGpncHB+L3pvbmVpbmZvXCIgXAoJCSQoR0NDRkxBR1MpICQoTERG
TEFHUykgJChUWkNTUkNTKSAkKExETElCUykgLW8gJEAKCQkkKFNUUklQKSAkQAoKemljJChFWEVF
WFQpOgkkKFRaQ09CSlMpICQoVE9QRElSKS9saWIvY3J0MC5vICQoVE9QRElSKS9saWIvbGliYy5h
IHllYXJpc3R5cGUKCQkkKENST1NTX0xEKSAtcyAkKExERkxBR1MpICQoVE9QRElSKS9saWIvY3J0
MC5vICQoVFpDT0JKUykgLW8gJEAgJChUT1BESVIpL2xpYi9saWJjLmEgJChMSUJHQ0NBKSAtVCAk
KERKR1BQX0RKTCkKCQkkKFRPUERJUikvaG9zdGJpbi9zdHViaWZ5LmV4ZSAkQAoKeWVhcmlzdHlw
ZToJeWVhcmlzdHlwZS5zaAoJCSQoVVRJTCkgY3AgeWVhcmlzdHlwZS5zaCB5ZWFyaXN0eXBlCgpw
b3NpeF9vbmx5OgkkKHppYykgJChUREFUQSkgVERBVEFfbGlzdAppZmVxICgkKENST1NTX0JVSUxE
KSwxKQoJCSQoWklDKSAteSAkKFlFQVJJU1RZUEUpIC1kICQoVFpESVIpIC1MIC9kZXYvbnVsbCAk
KFREQVRBKQplbHNlCgkJJChaSUMpIC15ICQoWUVBUklTVFlQRSkgLWQgJChUWkRJUikgLUwgL2Rl
di9udWxsIEBUREFUQV9saXN0CmVuZGlmCgpyaWdodF9vbmx5OgkkKHppYykgbGVhcHNlY29uZHMg
JChUREFUQSkgVERBVEFfbGlzdAppZmVxICgkKENST1NTX0JVSUxEKSwxKQoJCSQoWklDKSAteSAk
KFlFQVJJU1RZUEUpIC1kICQoVFpESVIpIC1MIGxlYXBzZWNvbmRzICQoVERBVEEpCmVsc2UKCQkk
KFpJQykgLXkgJChZRUFSSVNUWVBFKSAtZCAkKFRaRElSKSAtTCBsZWFwc2Vjb25kcyBAVERBVEFf
bGlzdAplbmRpZgoKIyBJbiBlYXJsaWVyIHZlcnNpb25zIG9mIHRoaXMgbWFrZWZpbGUsIHRoZSBv
dGhlciB0d28gZGlyZWN0b3JpZXMgd2VyZQojIHN1YmRpcmVjdG9yaWVzIG9mICQoVFpESVIpLiAg
SG93ZXZlciwgdGhpcyBsZWQgdG8gY29uZmlndXJhdGlvbiBlcnJvcnMuCiMgRm9yIGV4YW1wbGUs
IHdpdGggcG9zaXhfcmlnaHQgdW5kZXIgdGhlIGVhcmxpZXIgc2NoZW1lLAojIFRaPSdyaWdodC9B
dXN0cmFsaWEvQWRlbGFpZGUnIGdvdCB5b3UgbG9jYWx0aW1lIHdpdGggbGVhcCBzZWNvbmRzLAoj
IGJ1dCBnbXRpbWUgd2l0aG91dCBsZWFwIHNlY29uZHMsIHdoaWNoIGxlZCB0byBwcm9ibGVtcyB3
aXRoIGFwcGxpY2F0aW9ucwojIGxpa2Ugc2VuZG1haWwgdGhhdCBzdWJ0cmFjdCBnbXRpbWUgZnJv
bSBsb2NhbHRpbWUuCiMgVGhlcmVmb3JlLCB0aGUgb3RoZXIgdHdvIGRpcmVjdG9yaWVzIGFyZSBu
b3cgc2libGluZ3Mgb2YgJChUWkRJUikuCiMgWW91IG11c3QgcmVwbGFjZSBhbGwgb2YgJChUWkRJ
UikgdG8gc3dpdGNoIGZyb20gbm90IHVzaW5nIGxlYXAgc2Vjb25kcwojIHRvIHVzaW5nIHRoZW0s
IG9yIHZpY2UgdmVyc2EuCm90aGVyX3R3bzoJJCh6aWMpIGxlYXBzZWNvbmRzICQoVERBVEEpIFRE
QVRBX2xpc3QKaWZlcSAoJChDUk9TU19CVUlMRCksMSkKCQkkKFpJQykgLXkgJChZRUFSSVNUWVBF
KSAtZCAkKFRaRElSKS1wb3NpeCAtTCAvZGV2L251bGwgJChUREFUQSkKCQkkKFpJQykgLXkgJChZ
RUFSSVNUWVBFKSBcCgkJCS1kICQoVFpESVIpLWxlYXBzIC1MIGxlYXBzZWNvbmRzICQoVERBVEEp
CmVsc2UKCQkkKFpJQykgLXkgJChZRUFSSVNUWVBFKSAtZCAkKFRaRElSKS1wb3NpeCAtTCAvZGV2
L251bGwgQFREQVRBX2xpc3QKCQkkKFpJQykgLXkgJChZRUFSSVNUWVBFKSBcCgkJCS1kICQoVFpE
SVIpLWxlYXBzIC1MIGxlYXBzZWNvbmRzIEBUREFUQV9saXN0CmVuZGlmCgpwb3NpeF9yaWdodDoJ
cG9zaXhfb25seSBvdGhlcl90d28KCnJpZ2h0X3Bvc2l4OglyaWdodF9vbmx5IG90aGVyX3R3bwoK
em9uZXM6CQkkKFJFRE8pCgokKFRaTElCKToJJChMSUJPQkpTKQoJCS0kKFVUSUwpIG1rZGlyICQo
VE9QRElSKQoJCS0kKFVUSUwpIG1rZGlyICQoTElCRElSKQoJCSQoQ1JPU1NfQVIpIHJ1cyAkQCAk
KExJQk9CSlMpCgpkYXRlJChFWEVFWFQpOgkkKERBVEVPQkpTKSAkKFRPUERJUikvbGliL2NydDAu
byAkKFRPUERJUikvbGliL2xpYmMuYQoJCSQoQ1JPU1NfTEQpIC1zICQoTERGTEFHUykgJChUT1BE
SVIpL2xpYi9jcnQwLm8gJChEQVRFT0JKUykgLW8gJEAgJChUT1BESVIpL2xpYi9saWJjLmEgJChM
SUJHQ0NBKSAtVCAkKERKR1BQX0RKTCkKCQkkKFRPUERJUikvaG9zdGJpbi9zdHViaWZ5LmV4ZSAk
QAoKdHpzZWxlY3Q6CXR6c2VsZWN0LmtzaAoJCXNlZCBcCgkJCS1lICdzfEFXSz1bXn1dKnxBV0s9
JChBV0spfGcnIFwKCQkJLWUgJ3N8XChQS0dWRVJTSU9OXCk9Lip8XDE9J1wnJygkKFBBQ0tBR0Up
KSAnXCcnfCcgXAoJCQktZSAnc3xcKFJFUE9SVF9CVUdTX1RPXCk9Lip8XDE9JChCVUdFTUFJTCl8
JyBcCgkJCS1lICdzfFRaRElSPVtefV0qfFRaRElSPS9kZXYvZW52L0RKRElSL3pvbmVpbmZvfCcg
XAoJCQktZSAnc3xcKFRaVkVSU0lPTlwpPS4qfFwxPSQoVkVSU0lPTil8JyBcCgkJCTwkPyA+JEAK
CQljaG1vZCAreCAkQAoKY2hlY2s6CQljaGVja19jaGFyYWN0ZXJfc2V0IGNoZWNrX3RhYmxlcyBj
aGVja193ZWIKCmNoZWNrX2NoYXJhY3Rlcl9zZXQ6ICQoRU5DSElMQURBKQoJCXNoYXJwPScjJzsg
ISBncmVwIC1uICQoSU5WQUxJRF9DSEFSKSAkKEVOQ0hJTEFEQSkKCmNoZWNrX3RhYmxlczoJY2hl
Y2t0YWIuYXdrICQoUFJJTUFSWV9ZREFUQSkKCQkkKEFXSykgLWYgY2hlY2t0YWIuYXdrICQoUFJJ
TUFSWV9ZREFUQSkKCmNoZWNrX3dlYjoJJChXRUJfUEFHRVMpCgkJJChWQUxJREFURV9FTlYpICQo
VkFMSURBVEUpICQoVkFMSURBVEVfRkxBR1MpICQoV0VCX1BBR0VTKQoKY2xlYW5fbWlzYzoKCQkk
KFVUSUwpIHJtIGNvcmUgKi5vICoub3V0IHR6c2VsZWN0IHpkdW1wJChFWEVFWFQpIHppYyQoRVhF
RVhUKSBcCgkJCXllYXJpc3R5cGUgZGF0ZSQoRVhFRVhUKSBsb2d3dG1wbCogKi50YXIuZ3ogJChI
T1NUX1pJQykgKi5leGUgKi5tYW4gXAoJCQlUREFUQV9saXN0CmNsZWFuOgkJY2xlYW5fbWlzYwoJ
CSQoVVRJTCkgcm0gLWYgLXIgdHpwdWJsaWMKCm1haW50YWluZXItY2xlYW46IGNsZWFuCgkJQGVj
aG8gJ1RoaXMgY29tbWFuZCBpcyBpbnRlbmRlZCBmb3IgbWFpbnRhaW5lcnMgdG8gdXNlOyBpdCcK
CQlAZWNobyAnZGVsZXRlcyBmaWxlcyB0aGF0IG1heSBuZWVkIHNwZWNpYWwgdG9vbHMgdG8gcmVi
dWlsZC4nCgkJcm0gLWYgKi5bMS04XS50eHQgKi5hc2MgKi50YXIuZ3oKCm5hbWVzOgoJCUAkKFVU
SUwpIGVjaG8gJChFTkNISUxBREEpCgpwdWJsaWM6CQljaGVjayBjaGVja19wdWJsaWMgY2hlY2tf
dGltZV90X2FsdGVybmF0aXZlcyBcCgkJc2V0LXRpbWVzdGFtcHMgdGFyYmFsbHMgc2lnbmF0dXJl
cwoKIyBTZXQgdGhlIHRpbWUgc3RhbXBzIHRvIHRob3NlIG9mIHRoZSBnaXQgcmVwb3NpdG9yeSwg
aWYgYXZhaWxhYmxlLAojIGFuZCBpZiB0aGUgZmlsZXMgaGF2ZSBub3QgY2hhbmdlZCBzaW5jZSB0
aGVuLgojIFRoaXMgdXNlcyBHTlUgJ3RvdWNoJyBzeW50YXggJ3RvdWNoIC1kQE4gRklMRScsCiMg
d2hlcmUgTiBpcyB0aGUgbnVtYmVyIG9mIHNlY29uZHMgc2luY2UgMTk3MC4KIyBJZiBnaXQgb3Ig
R05VICd0b3VjaCcgaXMgYWJzZW50LCBkbyBub3RoaW5nLgpzZXQtdGltZXN0YW1wczoKCQktVFo9
VVRDMCAmJiBleHBvcnQgVFogJiYgZmlsZXM9YGdpdCBscy1maWxlc2AgJiYgXAoJCXRvdWNoIC1k
IEAxIHRlc3Qub3V0ICYmIHJtIC1mIHRlc3Qub3V0ICYmIFwKCQlmb3IgZmlsZSBpbiAkJGZpbGVz
OyBkbyBcCgkJICB0ZXN0IC16ICJgZ2l0IGRpZmYgLS1uYW1lLW9ubHkgJCRmaWxlYCIgfHwgY29u
dGludWU7IFwKCQkgIGNtZD0idG91Y2ggLWQgQGBnaXQgbG9nIC0xIC0tZm9ybWF0PSdmb3JtYXQ6
JWN0JyAkJGZpbGUgXAoJCQlgICQkZmlsZSIgJiYgXAoJCSAgZWNobyAiJCRjbWQiICYmIFwKCQkg
ICQkY21kIHx8IGV4aXQ7IFwKCQlkb25lCgojIFRoZSB6aWNzIGJlbG93IGVuc3VyZSB0aGF0IGVh
Y2ggZGF0YSBmaWxlIGNhbiBzdGFuZCBvbiBpdHMgb3duLgojIFdlIGFsc28gZG8gYW4gYWxsLWZp
bGVzIHJ1biB0byBjYXRjaCBsaW5rcyB0byBsaW5rcy4KCmNoZWNrX3B1YmxpYzoJJChFTkNISUxB
REEpCgkJbWFrZSBtYWludGFpbmVyLWNsZWFuCgkJbWFrZSAiQ0ZMQUdTPSQoQ1JPU1NfR0NDX0RF
QlVHX0ZMQUdTKSIKCQlta2RpciB0enB1YmxpYwoJCWZvciBpIGluICQoVERBVEEpIDsgZG8gXAoJ
CSAgJCh6aWMpIC12IC1kIHR6cHVibGljICQkaSAyPiYxIHx8IGV4aXQ7IFwKCQlkb25lCgkJJCh6
aWMpIC12IC1kIHR6cHVibGljICQoVERBVEEpCgkJcm0gLWYgLXIgdHpwdWJsaWMKCiMgQ2hlY2sg
dGhhdCB0aGUgY29kZSB3b3JrcyB1bmRlciB2YXJpb3VzIGFsdGVybmF0aXZlCiMgaW1wbGVtZW50
YXRpb25zIG9mIHRpbWVfdC4KY2hlY2tfdGltZV90X2FsdGVybmF0aXZlczoKCQlta2RpciB0enB1
YmxpYwoJCXpvbmVzPWAkKEFXSykgJy9eW14jXS8geyBwcmludCAkJDMgfScgPHpvbmUudGFiYCAm
JiBcCgkJZm9yIHR5cGUgaW4gJChUSU1FX1RfQUxURVJOQVRJVkVTKTsgZG8gXAoJCSAgbWtkaXIg
dHpwdWJsaWMvJCR0eXBlICYmIFwKCQkgIG1ha2UgY2xlYW5fbWlzYyAmJiBcCgkJICBtYWtlIFRP
UERJUj1gcHdkYC90enB1YmxpYy8kJHR5cGUgXAoJCSAgICBDRkxBR1M9JyQoQ0ZMQUdTKSAtRHRp
bWVfdHo9JyInJCR0eXBlJyIgXAoJCSAgICBpbnN0YWxsICYmIFwKCQkgIGRpZmYgLXFyIHR6cHVi
bGljL2ludDY0X3QvZXRjL3pvbmVpbmZvIHR6cHVibGljLyQkdHlwZS9ldGMvem9uZWluZm8gJiYg
XAoJCSAgY2FzZSAkJHR5cGUgaW4gXAoJCSAgaW50MzJfdCkgcmFuZ2U9LTIxNDc0ODM2NDgsMjE0
NzQ4MzY0Nzs7IFwKCQkgIHVpbnQzMl90KSByYW5nZT0wLDQyOTQ5NjcyOTY7OyBcCgkJICBpbnQ2
NF90KSBjb250aW51ZTs7IFwKCQkgICp1KikgcmFuZ2U9MCwxMDAwMDAwMDAwMDs7IFwKCQkgICop
IHJhbmdlPS0xMDAwMDAwMDAwMCwxMDAwMDAwMDAwMDs7IFwKCQkgIGVzYWMgJiYgXAoJCSAgZWNo
byBjaGVja2luZyAkJHR5cGUgem9uZXMgLi4uICYmIFwKCQkgIHR6cHVibGljL2ludDY0X3QvZXRj
L3pkdW1wIC1WIC10ICQkcmFuZ2UgJCR6b25lcyBcCgkJICAgICAgPnR6cHVibGljL2ludDY0X3Qu
b3V0ICYmIFwKCQkgIHR6cHVibGljLyQkdHlwZS9ldGMvemR1bXAgLVYgLXQgJCRyYW5nZSAkJHpv
bmVzIFwKCQkgICAgICA+dHpwdWJsaWMvJCR0eXBlLm91dCAmJiBcCgkJICBkaWZmIC11IHR6cHVi
bGljL2ludDY0X3Qub3V0IHR6cHVibGljLyQkdHlwZS5vdXQgXAoJCSAgICB8fCBleGl0OyBcCgkJ
ZG9uZQoJCXJtIC1mIC1yIHR6cHVibGljCgp0YXJiYWxsczoJdHpjb2RlJChWRVJTSU9OKS50YXIu
Z3ogdHpkYXRhJChWRVJTSU9OKS50YXIuZ3oKCnR6Y29kZSQoVkVSU0lPTikudGFyLmd6OiAkKENP
TU1PTikgJChET0NTKSAkKFNPVVJDRVMpICQoTUlTQykKCQlmb3IgaSBpbiAqLlsxLThdIDsgZG8g
XAoJCSAgTENfQUxMPUMgc2ggd29ya21hbi5zaCAkJGkgPiAkJGkudHh0ICYmIFwKCQkgIHRvdWNo
IC1yICQkaSAkJGkudHh0IHx8IGV4aXQ7IFwKCQlkb25lCgkJTENfQUxMPUMgJiYgZXhwb3J0IExD
X0FMTCAmJiBcCgkJdGFyICQoVEFSRkxBR1MpIC1jZiAtIFwKCQkgICAgJChDT01NT04pICQoRE9D
UykgJChTT1VSQ0VTKSAkKE1JU0MpICouWzEtOF0udHh0IHwgXAoJCSAgZ3ppcCAkKEdaSVBGTEFH
UykgPiAkQAoKdHpkYXRhJChWRVJTSU9OKS50YXIuZ3o6ICQoQ09NTU9OKSAkKERBVEEpCgkJTENf
QUxMPUMgJiYgZXhwb3J0IExDX0FMTCAmJiBcCgkJdGFyICQoVEFSRkxBR1MpIC1jZiAtICQoQ09N
TU9OKSAkKERBVEEpIHwgXAoJCSAgZ3ppcCAkKEdaSVBGTEFHUykgPiAkQAoKc2lnbmF0dXJlczoJ
dHpjb2RlJChWRVJTSU9OKS50YXIuZ3ouYXNjIHR6ZGF0YSQoVkVSU0lPTikudGFyLmd6LmFzYwoK
dHpjb2RlJChWRVJTSU9OKS50YXIuZ3ouYXNjOiB0emNvZGUkKFZFUlNJT04pLnRhci5negoJCWdw
ZyAtLWFybW9yIC0tZGV0YWNoLXNpZ24gJD8KCnR6ZGF0YSQoVkVSU0lPTikudGFyLmd6LmFzYzog
dHpkYXRhJChWRVJTSU9OKS50YXIuZ3oKCQlncGcgLS1hcm1vciAtLWRldGFjaC1zaWduICQ/Cgp0
eXBlY2hlY2s6CgkJbWFrZSBjbGVhbgoJCWZvciBpIGluICJsb25nIGxvbmciIHVuc2lnbmVkIGRv
dWJsZTsgXAoJCWRvIFwKCQkJbWFrZSBDRkxBR1M9Ii1EVFlQRUNIRUNLIC1EX190aW1lX3RfZGVm
aW5lZCAtRF9USU1FX1QgXCItRHRpbWVfdD0kJGlcIiIgOyBcCgkJCS4vemR1bXAgLXYgRXVyb3Bl
L1JvbWUgOyBcCgkJCW1ha2UgY2xlYW4gOyBcCgkJZG9uZQoKem9uZW5hbWVzOgkkKFREQVRBKQoJ
CUAkKEFXSykgJy9eWm9uZS8geyBwcmludCAkJDIgfSAvXkxpbmsvIHsgcHJpbnQgJCQzIH0nICQo
VERBVEEpCgpUREFUQV9saXN0OgkkKFREQVRBKQoJCWVjaG8gJChUREFUQSkgPiBUREFUQV9saXN0
Cgphc2N0aW1lLm86CXByaXZhdGUuaCB0emZpbGUuaApkYXRlLm86CQlwcml2YXRlLmgKZGlmZnRp
bWUubzoJcHJpdmF0ZS5oCmlhbGxvYy5vOglwcml2YXRlLmgKbG9jYWx0aW1lLm86CXByaXZhdGUu
aCB0emZpbGUuaApzY2hlY2subzoJcHJpdmF0ZS5oCnN0cmZ0aW1lLm86CXR6ZmlsZS5oCnpkdW1w
Lm86CXZlcnNpb24uaAp6aWMubzoJCXByaXZhdGUuaCB0emZpbGUuaCB2ZXJzaW9uLmgKCi5LRUVQ
X1NUQVRFOgo=
--001a11354e16b385c8051684e5f1--
0
Ozkan
5/20/2015 3:15:28 PM
> You can't legitimately expect others to know or respect the aberrant
> capitalization of your name.

Sure I can.  It's on every email I've sent out to the djgpp list:

> From: DJ Delorie <dj@delorie.com>

All you had to do is copy what you saw, but you chose to change it.
0
DJ
5/20/2015 5:16:59 PM
> How is that any different from my reply to Eli?

The difference is that I kept my opinion to myself, whereas you chose
to dictate it to others as if it were fact.
0
DJ
5/20/2015 5:18:22 PM
On 05/21/2015 12:41 AM, Juan Manuel Guerrero (juan.guerrero@gmx.de) wrote:
>
> Today I have ported and compiled gdb-7.9.1.tar.gz.  The COFF/dwarf support is
> as broken as with gdb-7.8. and later versions.  The last gdb version with working
> djgpp support is gdb-7.7.1.tar.gz.  I do not think that they have intentionally
> removed or brocken djgpp support.  But an inspection of the changelog file shows
> that they have modified go32-nat.c but not only this one.  This change seems to be
> part of a major modification or rewrite of that particular code segments.
>
> From Changelog-2014:
>
> 2014-03-07  Pedro Alves  <palves@redhat.com>
>
>     * go32-nat.c: Include inf-child.h.
>     (go32_ops): Delete global.
>     (go32_close, go32_detach, go32_prepare_to_store, go32_can_run):
>     Delete methods.
>     (go32_create_inferior): Push the passed in target pointer instead
>     of referencing go32_ops.
>     (init_go32_ops): Delete function.  Moved parts to _initialize_go32_nat.
>     (go32_target): New function, based on init_go32_ops, but inherit
>     inf_child_target.
>     (_initialize_go32_nat): Use go32_target.  Move parts of
>     init_go32_ops here.
>
> I have inspected those changes and they seem to have been well done.  So it is
> not clear what has been brocken.
> Unfortunately I have absolute no knowledge about DWARF and especially I do not
> understand how the djgpp support of gdb works.  So I cannot debug nor figure out
> this issue.

This change is most likely only a result of other changes. So if we do not know these other changes 
it would be very difficult to see whether that go32-nat.c change is actually OK or some detail is 
accidentally left out.

Perhaps it is necessary to look for in GDB GIT repository to see which change actually broke DJGPP 
support between creating gdb_7_7_branch and gdb-7.8 release. 'git bisect' could perhaps help. Then 
it could be more clear what went wrong

Andris



0
Andris
5/21/2015 4:25:20 AM
> Date: Thu, 21 May 2015 07:25:20 +0300
> From: "Andris Pavenis (andris.pavenis@iki.fi)" <djgpp@delorie.com>
> 
> This change is most likely only a result of other changes. So if we do not know these other changes
> it would be very difficult to see whether that go32-nat.c change is actually OK or some detail is
> accidentally left out.

Juan quoted a discussion from a year ago, which ended with this
conclusion:

> >> (gdb) r
> >> Starting program: h:/l/bins/bin/a.exe
> >> Warning:
> >> Cannot insert breakpoint 1.
> >> Cannot access memory at address 0x1e04
> > This means inserting a breakpoint at 0x1e04 returned EIO.  I suggest
> > to take a good look at the code that's involved in this.  I see that
> > in GDB-7.7.1, we had these 2 lines in go32-nat.c:
> >
> >    go32_ops.to_insert_breakpoint = memory_insert_breakpoint;
> >    go32_ops.to_remove_breakpoint = memory_remove_breakpoint;
> >
> > but these lines are no longer there, and instead the go32 target
> > inherits from inf_child_target.  Perhaps that's the cause of the
> > problem.
> 
> Thank you for the pointer.  The change from the old way to handle the
> native support to the new way of initializing struct target_ops inf_child_ops
> by inf_child_target and go32_target seems to be the source of the difficulties.
> At least go32_ops.to_insert_breakpoint and go32_ops.to_remove_breakpoint are
> not set to the corresponding equivalent new variables for DJGPP.

Can we pick up where this was left off?

FWIW, I don't understand what Juan wrote back then: go32_ops no longer
exists in the current sources.  Instead, the initialization calls
go32_target, which does this:

  static struct target_ops *
  go32_target (void)
  {
    struct target_ops *t = inf_child_target ();

In inf_child_target, I see that to_insert_breakpoint and
to_remove_breakpoint are correctly assigned:

  struct target_ops *
  inf_child_target (void)
  {
    struct target_ops *t = XCNEW (struct target_ops);

  [...]
    t->to_insert_breakpoint = memory_insert_breakpoint;
    t->to_remove_breakpoint = memory_remove_breakpoint;

Back in the go32-nat initialization function, we have this call, after
all the members of target_ops were initialized:

  add_target (t);

where before GDB 7.8 it did this instead:

  add_target (&go32_ops);

This all looks OK to me, and I just stepped through the corresponding
code for the MinGW native target and saw that it does the same (and
certainly works, as I use it every day).

So what and how goes wrong in the DJGPP build of GDB?  Can someone
with enough free time step through the go32 initialization, and see
what's wrong there?

TIA
0
Eli
5/21/2015 4:01:58 PM
Pushed the following for src/libm/math/w[f]_cabs.c:

    use __complex__ instead of _Complex so that it compiles with gcc2 too

Index: src/libm/math/w_cabs.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libm/math/w_cabs.c,v
retrieving revision 1.4
diff -u -r1.4 w_cabs.c
--- src/libm/math/w_cabs.c	20 Aug 2011 12:41:02 -0000	1.4
+++ src/libm/math/w_cabs.c	23 May 2015 00:12:27 -0000
@@ -11,11 +11,11 @@
 #include "fdlibm.h"

 #ifdef __STDC__
-double cabs(_Complex double);
-double cabs(_Complex double z)
+double cabs(__complex__ double);
+double cabs(__complex__ double z)
 #else
 double cabs(z)
-     _Complex double z;
+     __complex__ double z;
 #endif
 {
 	return hypot(__real__ z, __imag__ z);
Index: src/libm/math/wf_cabs.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libm/math/wf_cabs.c,v
retrieving revision 1.4
diff -u -r1.4 wf_cabs.c
--- src/libm/math/wf_cabs.c	20 Aug 2011 12:41:02 -0000	1.4
+++ src/libm/math/wf_cabs.c	23 May 2015 00:12:27 -0000
@@ -11,11 +11,11 @@
 #include "fdlibm.h"

 #ifdef __STDC__
-float cabsf(_Complex float);
-float cabsf(_Complex float z)
+float cabsf(__complex__ float);
+float cabsf(__complex__ float z)
 #else
 float cabsf(z)
-	_Complex float z;
+    __complex__ float z;
 #endif
 {
 	return hypotf(__real__ z, __imag__ z);
0
Ozkan
5/23/2015 8:11:50 AM
Applied the following to dxe3.gen.c so that it compiles with gcc2:

* dxe3gen.c: change the variable length array from [] to [0] so that
it compiles using gcc2

Index: src/dxe/dxe3gen.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/dxe/dxe3gen.c,v
retrieving revision 1.19
diff -u -r1.19 dxe3gen.c
--- src/dxe/dxe3gen.c	17 May 2015 12:55:18 -0000	1.19
+++ src/dxe/dxe3gen.c	22 May 2015 22:08:42 -0000
@@ -168,8 +168,9 @@
 #ifndef DXE_LD
 /* Cross compile ld name/location */
 #define DXE_LD  "ld"
-#else
-/* Linux violates POSIX.1 and defines this, but it shouldn't.  We fix it. */
+#endif
+#ifdef _POSIX_SOURCE
+/* Linux violates POSIX.1 and defines this, but it shouldn't.. */
 #undef _POSIX_SOURCE
 #endif

@@ -684,7 +685,7 @@
                 uword length;
                 sword CIE_id;
                 ubyte version;
-                unsigned char augmentation[];
+                unsigned char augmentation[0];
               } __attribute__ ((packed, aligned (__alignof__ (void *))));
0
Ozkan
5/23/2015 8:20:25 AM
Applied the following to sys/dxe.h:

* sys/dxe.h: change intptr_t usage with size_t so we can compile using
2.03-based toolchains

Index: include/sys/dxe.h
===================================================================
RCS file: /cvs/djgpp/djgpp/include/sys/dxe.h,v
retrieving revision 1.9
diff -u -r1.9 dxe.h
--- include/sys/dxe.h	17 May 2015 12:55:18 -0000	1.9
+++ include/sys/dxe.h	22 May 2015 22:08:41 -0000
@@ -10,7 +10,7 @@
 #ifndef __dj_include_dxe_h_
 #define __dj_include_dxe_h_

-#include <stdint.h>  /* for intptr_t */
+#include <stddef.h>  /* for size_t */

 /* the following are needed when cross compiling hostbin exes */
 #ifndef _DJ_DEFINED_NATIVE_TYPES
@@ -217,7 +217,7 @@
    dlregsym ((void *)&__alias__##name); \
   } \
   static __attribute_used dxe_symbol_table name [] = {
-#define DXE_EXPORT(symbol)	{ "_" #symbol, (void *)(intptr_t)&symbol },
+#define DXE_EXPORT(symbol)	{ "_" #symbol, (void *)(size_t)&symbol },
 #define DXE_EXPORT_END		{ 0, 0 }};

 /*
0
Ozkan
5/23/2015 8:24:30 AM
Applied the following to doprnt.c:

doprnt.c: removed the CHARINT case from the ARG macro.
  (char basetype) seems wrong and the case is handled
  with the generic case already.

Index: src/libc/ansi/stdio/doprnt.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/ansi/stdio/doprnt.c,v
retrieving revision 1.36
diff -u -r1.36 doprnt.c
--- src/libc/ansi/stdio/doprnt.c	10 Jan 2014 18:21:56 -0000	1.36
+++ src/libc/ansi/stdio/doprnt.c	23 May 2015 00:21:23 -0000
@@ -48,7 +48,6 @@
   flags & LONGDBL  ? va_arg(argp, long long basetype) :   \
   flags & LONGINT  ? va_arg(argp, long basetype) :        \
   flags & SHORTINT ? (short basetype)va_arg(argp, int) :  \
-  flags & CHARINT  ? (char basetype)va_arg(argp, int) :   \
   (basetype)va_arg(argp, int)

 #define CONVERT(type, value, base, string, case)               \
0
Ozkan
5/23/2015 8:35:37 AM
Applied the following to doprnt.c:

* doprnt.c: avoid unused warnings from gcc2

Index: doprnt.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/ansi/stdio/doprnt.c,v
retrieving revision 1.37
diff -u -r1.37 doprnt.c
--- doprnt.c	23 May 2015 08:35:29 -0000	1.37
+++ doprnt.c	23 May 2015 08:37:04 -0000
@@ -1374,7 +1374,7 @@
         return argp;
       if (prec_index == list_index)
       {
-        va_arg(argp, int);  /* discard */
+        _ulonglong = va_arg(argp, int);  /* discard */
         list_index++;
       }
       goto rflag;
@@ -1387,7 +1387,7 @@
           return argp;
         if (prec_index == list_index)
         {
-          va_arg(argp, int);  /* discard */
+          _ulonglong = va_arg(argp, int);  /* discard */
           list_index++;
         }
       }
@@ -1422,7 +1422,7 @@
         return argp;
       if (arg_index == list_index)
       {
-        va_arg(argp, int);  /* discard */
+        _ulonglong = va_arg(argp, int);  /* discard */
         list_index++;
       }
       break;
@@ -1445,9 +1445,9 @@
       if (arg_index == list_index)
       {
         if (flags & LONGDBL)
-          va_arg(argp, long double);  /* discard */
+          _ulonglong = va_arg(argp, long double);  /* discard */
         else
-          va_arg(argp, double);  /* discard */
+          _ulonglong = va_arg(argp, double);  /* discard */
         list_index++;
       }
       break;
@@ -1468,7 +1468,7 @@
         return argp;
       if (arg_index == list_index)
       {
-        va_arg(argp, void *);  /* discard */
+        _ulonglong = (size_t) va_arg(argp, void *);  /* discard */
         list_index++;
       }
       break;
0
Ozkan
5/23/2015 8:38:15 AM
Applied the following in order to avoid stdbool.h usage:
As I stated earlier in this thread our stdbool.h is broken
(and gcc provides its stdbool.h) and it leads to failures
such as:

cc1.exe: warnings being treated as errors
doscan.c:38: warning: type defaults to `int' in declaration of `_Bool'
doscan.c:38: parse error before `allocate_char_buffer'
doscan.c:38: warning: function declaration isn't a prototype
doscan.c:41: warning: type defaults to `int' in declaration of `_Bool'
doscan.c:41: parse error before `allocate_char_buffer'
doscan.c:41: warning: function declaration isn't a prototype
doscan.c: In function `_doscan_low':
doscan.c:71: `_Bool' undeclared (first use in this function)

---

* doprnt.c, doscan.c: locally define bool/false/true and remove the
  stdbool.h usage.

* libc/ansi/time/strftime.c: revert parts of r1.8 and simply use 0
  and 1 instead of true and false again.

* djtar/unbzip2.c: revert parts of r1.4 and go back to the original
  TRUE and FALSE usage.

* tests/libc/c99/math/t-ismac.c: locally define bool/false/true and
  remove stdbool.h usage.

Index: src/libc/ansi/stdio/doprnt.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/ansi/stdio/doprnt.c,v
retrieving revision 1.36
diff -u -p -r1.36 doprnt.c
--- src/libc/ansi/stdio/doprnt.c	10 Jan 2014 18:21:56 -0000	1.36
+++ src/libc/ansi/stdio/doprnt.c	13 May 2015 08:02:10 -0000
@@ -21,12 +21,15 @@
 #include <string.h>
 #include <math.h>
 #include <limits.h>
-#include <stdbool.h>
 #include <libc/file.h>
 #include <libc/local.h>
 #include <libc/ieee.h>
 #include <sys/cdefs.h>

+typedef enum {
+  false = 0, true = 1
+} bool;
+
 static char decimal_point;
 static char thousands_sep;
 static char *grouping;
Index: src/libc/ansi/stdio/doscan.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/ansi/stdio/doscan.c,v
retrieving revision 1.24
diff -u -p -r1.24 doscan.c
--- src/libc/ansi/stdio/doscan.c	2 May 2015 07:32:04 -0000	1.24
+++ src/libc/ansi/stdio/doscan.c	13 May 2015 08:02:10 -0000
@@ -12,12 +12,15 @@
 #include <stdlib.h>
 #include <ctype.h>
 #include <locale.h>
-#include <stdbool.h>
 #include <stddef.h>
 #include <errno.h>
 #include <libc/file.h>
 #include <libc/local.h>

+typedef enum {
+  false = 0, true = 1
+} bool;
+
 #define SPC               01
 #define STP               02


Index: src/libc/ansi/time/strftime.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/ansi/time/strftime.c,v
retrieving revision 1.10
diff -u -p -r1.10 strftime.c
--- src/libc/ansi/time/strftime.c	2 May 2015 07:32:14 -0000	1.10
+++ src/libc/ansi/time/strftime.c	13 May 2015 08:03:02 -0000
@@ -9,7 +9,6 @@
 #include <string.h>
 #include <time.h>
 #include <ctype.h>
-#include <stdbool.h>


 #define THURSDAY       4
@@ -164,21 +163,21 @@ _fmt(const char *format, const struct tm
   {
     if (*format == '%')
     {
-      int flag_seen, pad = '0', space=' ', swap_case = false;
+      int flag_seen, pad = '0', space=' ', swap_case = 0;

       /*  Parse flags.  */
       do {
-        flag_seen = false;
+        flag_seen = 0;
         if (format[1] == '_')
-          flag_seen = true, pad = space = ' ', format++;
+          flag_seen = 1, pad = space = ' ', format++;
         if (format[1] == '-')
-          flag_seen = true, pad = space = 0, format++;
+          flag_seen = 1, pad = space = 0, format++;
         if (format[1] == '0')
-          flag_seen = true, pad = space = '0', format++;
+          flag_seen = 1, pad = space = '0', format++;
         if (format[1] == '^')
-          flag_seen = true, upcase = true, format++;
+          flag_seen = 1, upcase = 1, format++;
         if (format[1] == '#')
-          flag_seen = true, swap_case = true, format++;
+          flag_seen = 1, swap_case = 1, format++;
       } while (flag_seen);

       /*  Parse modifiers.  */
@@ -192,7 +191,7 @@ _fmt(const char *format, const struct tm
 	break;
       case 'A':
 	if (swap_case)
-	  upcase = true;
+	  upcase = 1;
 	if (t->tm_wday < 0 || t->tm_wday > 6)
 	  return 0;
 	if (!_add(Afmt[t->tm_wday], upcase))
@@ -200,7 +199,7 @@ _fmt(const char *format, const struct tm
 	continue;
       case 'a':
 	if (swap_case)
-	  upcase = true;
+	  upcase = 1;
 	if (t->tm_wday < 0 || t->tm_wday > 6)
 	  return 0;
 	if (!_add(afmt[t->tm_wday], upcase))
@@ -208,7 +207,7 @@ _fmt(const char *format, const struct tm
 	continue;
       case 'B':
 	if (swap_case)
-	  upcase = true;
+	  upcase = 1;
 	if (t->tm_mon < 0 || t->tm_mon > 11)
 	  return 0;
 	if (!_add(Bfmt[t->tm_mon], upcase))
@@ -217,7 +216,7 @@ _fmt(const char *format, const struct tm
       case 'b':
       case 'h':
 	if (swap_case)
-	  upcase = true;
+	  upcase = 1;
 	if (t->tm_mon < 0 || t->tm_mon > 11)
 	  return 0;
 	if (!_add(bfmt[t->tm_mon], upcase))
@@ -294,7 +293,7 @@ _fmt(const char *format, const struct tm
 	  return 0;
 	continue;
       case 'p':
-	upcase = swap_case ? false : true;
+	upcase = swap_case ? 0 : 1;
 	if (!_add(t->tm_hour >= 12 ? "pm" : "am", upcase))
 	  return 0;
 	continue;
@@ -381,7 +380,7 @@ _fmt(const char *format, const struct tm
 	  strcpy(tm_zone, t->tm_zone);
 	  if (swap_case)
 	  {
-	    upcase = false;
+	    upcase = 0;
 	    strlwr(tm_zone);
 	  }
 	  if (!_add(tm_zone, upcase))
@@ -418,7 +417,7 @@ strftime(char *s, size_t maxsize, const
   pt = s;
   if ((gsize = maxsize) < 1)
     return 0;
-  if (_fmt(format, t, false))
+  if (_fmt(format, t, 0))
   {
     *pt = '\0';
     return maxsize - gsize;

Index: src/utils/djtar/unbzip2.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/utils/djtar/unbzip2.c,v
retrieving revision 1.5
diff -u -p -r1.5 unbzip2.c
--- src/utils/djtar/unbzip2.c	9 Jan 2011 14:19:57 -0000	1.5
+++ src/utils/djtar/unbzip2.c	13 May 2015 08:03:28 -0000
@@ -2,17 +2,19 @@
 /* Copyright (C) 2001 DJ Delorie, see COPYING.DJ for details */
 /* Copyright (C) 2000 DJ Delorie, see COPYING.DJ for details */

-/*
+/*
  * This file provides bzip2 support for DJTAR.
  */


 #include <stdlib.h>
-#include <stdbool.h>
 #include "oread.h"
 #include "zread.h"
 #include "unbzip2.h"

+#define FALSE 0
+#define TRUE  1
+
 local int read_stream (void)
 {
   int bytes_in, bytes_read;
@@ -39,21 +41,21 @@ local int read_stream (void)
     if ((bzip_status) == BZ_OK && nbytes == EOF &&                \
         data->avail_in == 0 && data->avail_out > 0)               \
       goto error_handler;                                         \
-  } while (false)
+  } while (FALSE)

 #define CHECK_IF_BZ_STREAM_END_IS_EOF(buf)                        \
   do {                                                            \
     if ((buf)[0] == 'B' && (buf)[1] == 'Z' && (buf)[2] == 'h')    \
-      EOF_reached = false;                                        \
+      EOF_reached = FALSE;                                        \
     else                                                          \
-      EOF_reached = true;                                         \
-  } while (false)
+      EOF_reached = TRUE;                                         \
+  } while (FALSE)

 int unbzip2 (void *f)
 {
   bz_stream* data = NULL;
   int        bzip_status;
-  int        EOF_reached = true;
+  int        EOF_reached = TRUE;
   int        small = 0;      /* Use fast decompressing algorithm. */
   int        verbosity = 0;  /* No verbose output at all. */
   int        nbytes = 0;
@@ -79,7 +81,7 @@ int unbzip2 (void *f)
     goto error_handler;

   /* Decompress every stream (.bz2 file) contained in this file. */
-  while (true)
+  while (TRUE)
   {
     /* Decompress the actual stream (.bz2 file) contained in this file. */
     while (bzip_status == BZ_OK)

Index: tests/libc/c99/math/t-ismac.c
===================================================================
RCS file: /cvs/djgpp/djgpp/tests/libc/c99/math/t-ismac.c,v
retrieving revision 1.1
diff -u -p -r1.1 t-ismac.c
--- tests/libc/c99/math/t-ismac.c	23 Mar 2013 11:58:58 -0000	1.1
+++ tests/libc/c99/math/t-ismac.c	13 May 2015 08:04:50 -0000
@@ -1,10 +1,12 @@
 #include "../../../../include/stdio.h"
 #include "../../../../include/math.h"
 #include "../../../../include/libc/ieee.h"
-#include <stdbool.h>

 #define TEST_TYPE  0  /* Allowed 0 or 1 */

+typedef enum {
+  false = 0, true = 1
+} bool;

 typedef union
 {
0
Ozkan
5/23/2015 8:50:16 AM
Using an unmodified 2.03-based toolchain/djgpp environment,
current cvs fails like the following:

../../../lib/libc.a(crt1.o)(.text+0x25d):crt1.c: undefined reference
to `_environ'
../../../lib/libc.a(crt1.o)(.text+0x2c4):crt1.c: undefined reference
to `_environ'
../../../lib/libc.a(crt1.o)(.text+0x2d0):crt1.c: undefined reference
to `_environ'
../../../lib/libc.a(crt1.o)(.text+0x2f7):crt1.c: undefined reference
to `_environ'
../../../lib/libc.a(crt1.o)(.text+0x516):crt1.c: undefined reference
to `_environ'
../../../lib/libc.a(spawnvp.o)(.text+0x11):spawnvp.c: more undefined
references to `_environ' follow
make.exe[3]: *** [../../../bin/symify.exe] Error 1

However, if I specify djgpp.djl on the make line, like:
  make DJGPP_DJL=c:/v205/lib/djgpp.djl
... then build happily succeeds.

Why are we using the toolchain-provided linker script instead
of source tree-provided one?  If this was an oversight, I can
easily change this.

--
O.S.
0
Ozkan
5/23/2015 9:24:08 AM
> Date: Sat, 23 May 2015 12:24:08 +0300
> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
> 
> Using an unmodified 2.03-based toolchain/djgpp environment,
> current cvs fails like the following:
> 
> ../../../lib/libc.a(crt1.o)(.text+0x25d):crt1.c: undefined reference
> to `_environ'
> ../../../lib/libc.a(crt1.o)(.text+0x2c4):crt1.c: undefined reference
> to `_environ'
> ../../../lib/libc.a(crt1.o)(.text+0x2d0):crt1.c: undefined reference
> to `_environ'
> ../../../lib/libc.a(crt1.o)(.text+0x2f7):crt1.c: undefined reference
> to `_environ'
> ../../../lib/libc.a(crt1.o)(.text+0x516):crt1.c: undefined reference
> to `_environ'
> ../../../lib/libc.a(spawnvp.o)(.text+0x11):spawnvp.c: more undefined
> references to `_environ' follow
> make.exe[3]: *** [../../../bin/symify.exe] Error 1
> 
> However, if I specify djgpp.djl on the make line, like:
>   make DJGPP_DJL=c:/v205/lib/djgpp.djl
> ... then build happily succeeds.
> 
> Why are we using the toolchain-provided linker script instead
> of source tree-provided one?  If this was an oversight, I can
> easily change this.

I'm guessing that no one envisioned the linker script will be ever
modified.

Using the script from the source tree is TRT, IMO.

Thanks.
0
Eli
5/23/2015 9:48:51 AM
Applied the following to zoneinfo/src/private.h (and updated djdiffs afterwards)

private.h: add missing INT64_MAX, INT_FAST32_MAX, INT_FAST32_MAX,
and the corresponding *_MIN macros, in case one wants to compile
without -DHAVE_STDINT_H=1 (otherwise compilation fails.)

Index: private.h
===================================================================
RCS file: /cvs/djgpp/djgpp/zoneinfo/src/private.h,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- private.h	17 Aug 2013 21:04:16 -0000	1.7
+++ private.h	23 May 2015 12:32:51 -0000	1.8
@@ -155,11 +155,20 @@
 #endif /* ! (defined LLONG_MAX || defined __LONG_LONG_MAX__) */
 #endif /* !defined INT_FAST64_MAX */

+#ifndef INT64_MAX
+# define INT64_MAX INT_FAST64_MAX
+# define INT64_MIN INT_FAST64_MIN
+#endif
+
 #ifndef INT_FAST32_MAX
 # if INT_MAX >> 31 == 0
 typedef long int_fast32_t;
+#  define INT_FAST32_MAX LONG_MAX
+#  define INT_FAST32_MIN LONG_MIN
 # else
 typedef int int_fast32_t;
+#  define INT_FAST32_MAX INT_MAX
+#  define INT_FAST32_MIN INT_MIN
 # endif
 #endif
0
Ozkan
5/23/2015 12:41:59 PM
On 5/23/15, Eli Zaretskii (eliz@gnu.org) <djgpp@delorie.com> wrote:
>> Date: Sat, 23 May 2015 12:24:08 +0300
>> From: "Ozkan Sezer (sezeroz@gmail.com)" <djgpp@delorie.com>
>>
>> Using an unmodified 2.03-based toolchain/djgpp environment,
>> current cvs fails like the following:
>>
>> ../../../lib/libc.a(crt1.o)(.text+0x25d):crt1.c: undefined reference
>> to `_environ'
>> ../../../lib/libc.a(crt1.o)(.text+0x2c4):crt1.c: undefined reference
>> to `_environ'
>> ../../../lib/libc.a(crt1.o)(.text+0x2d0):crt1.c: undefined reference
>> to `_environ'
>> ../../../lib/libc.a(crt1.o)(.text+0x2f7):crt1.c: undefined reference
>> to `_environ'
>> ../../../lib/libc.a(crt1.o)(.text+0x516):crt1.c: undefined reference
>> to `_environ'
>> ../../../lib/libc.a(spawnvp.o)(.text+0x11):spawnvp.c: more undefined
>> references to `_environ' follow
>> make.exe[3]: *** [../../../bin/symify.exe] Error 1
>>
>> However, if I specify djgpp.djl on the make line, like:
>>   make DJGPP_DJL=c:/v205/lib/djgpp.djl
>> ... then build happily succeeds.
>>
>> Why are we using the toolchain-provided linker script instead
>> of source tree-provided one?  If this was an oversight, I can
>> easily change this.
>
> I'm guessing that no one envisioned the linker script will be ever
> modified.
>
> Using the script from the source tree is TRT, IMO.
>
> Thanks.
>

OK then, applied the following:

* src/makefile.inc: use source tree-provided djgpp.djl, instead of
  toolchain-provided one. (and do not export DJGPP_DJL so that this
  actually works.)

Index: src/makefile.inc
===================================================================
RCS file: /cvs/djgpp/djgpp/src/makefile.inc,v
retrieving revision 1.16
diff -u -r1.16 makefile.inc
--- src/makefile.inc	30 Apr 2015 18:50:42 -0000	1.16
+++ src/makefile.inc	23 May 2015 11:01:32 -0000
@@ -131,12 +131,8 @@
 endif

 ifeq ($(DJGPP_DJL),)
-DJGPP_DJL := $(shell $(CROSS_GCC) $(GCC_OPT) -print-file-name=djgpp-x.djl)
-ifeq ($(DJGPP_DJL),djgpp-x.djl)
-DJGPP_DJL := $(shell $(CROSS_GCC) $(GCC_OPT) -print-file-name=djgpp.djl)
-endif
-DJGPP_DJL := $(subst \,/,$(DJGPP_DJL))
-export DJGPP_DJL
+DJGPP_DJL = $(LIB)/djgpp.djl
+#export DJGPP_DJL
 endif

 LINK = $(CROSS_LD) -s $(LDFLAGS) $(filter %.o,$^) $(filter-out
%.o,$^) -o $@ $(LIBGCCA) -T $(DJGPP_DJL)

--
0
Ozkan
5/23/2015 12:51:46 PM
--001a113f7e1c72d1c30516bf7f27
Content-Type: text/plain; charset=UTF-8

Updated patch for zoneinfo build system follows (also attached
as a patch file.) Bulid tested using 2.03 and 2.05 cross toolchains,
also successfully built under winxp using gcc-2.95 and djgpp-2.03
based environment. If no objections, I plan to apply this tomorrow.

* build tz binaries against source-tree, not against toolchain:
- zic: define as dos-zic.exe or host-zic.exe depending on cross
  or native build.
- host-zic: place in $(TOPDIR)/hostbin like other utils.
- HOST_ZIC: new var for 'host-zic' for cross-builds.
- HOST_ZIC: do not build if cross-compiling, copy over target-
  zic.exe to hostbin/ instead.
- LIBGCCA, DJGPP_DJL: copied defitinions from src/makefile.inc.
- CFLAGS: add -nostdinc -I$(TOPDIR)/include
- GCCFLAGS: (kept intact)
- zdump.exe, zic.exe, date.exe: change rules to link against
  freshly built crt0.o and libc.a.
- date.exe: remove logwtmpl.a building, because it was linking
  to locally built logwtmpl.a and logwtmp.o is simply an empty
  object for dos-targeting builds.
- debug flags: made them to work old compilers too, and cleaned
  and tidied a bit.

Index: zoneinfo/src/makefile
===================================================================
RCS file: /cvs/djgpp/djgpp/zoneinfo/src/makefile,v
retrieving revision 1.16
diff -u -r1.16 makefile
--- zoneinfo/src/makefile	26 Nov 2013 18:08:51 -0000	1.16
+++ zoneinfo/src/makefile	23 May 2015 12:55:50 -0000
@@ -87,6 +87,27 @@
 CROSS_GCC_MAJOR := $(word 3, $(shell ../../src/misc.exe |
$(CROSS_GCC) -E -dD -x c - | egrep 'define\ *__GNUC__'))
 CROSS_GCC_MINOR := $(word 3, $(shell ../../src/misc.exe |
$(CROSS_GCC) -E -dD -x c - | egrep 'define\ *__GNUC_MINOR__'))

+# very old gcc, e.g. gcc-2.95, fails the above, so we invent a default.
+ifeq ($(GCC_MAJOR),)
+GCC_MAJOR := 2
+GCC_MINOR := 7
+endif
+ifeq ($(CROSS_GCC_MAJOR),)
+CROSS_GCC_MAJOR := 2
+CROSS_GCC_MINOR := 7
+endif
+
+ifeq ($(LIBGCCA),)
+LIBGCCA := $(shell $(CROSS_GCC) $(GCC_OPT) -print-file-name=libgcc.a)
+LIBGCCA := $(subst \,/,$(LIBGCCA))
+export LIBGCCA
+endif
+
+ifeq ($(DJGPP_DJL),)
+DJGPP_DJL = $(TOPDIR)/lib/djgpp.djl
+#export DJGPP_DJL
+endif
+
 # A replacement for (possibly missing) Unix programs:

 UTIL=		$(TOPDIR)/src/misc.exe
@@ -162,97 +183,48 @@
 #	-Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines \
 #	-Wwrite-strings

+COMMON_DEBUG_FLAGS = -Dlint -g -fno-common -fstrict-aliasing \
+	-Wall -W -Wcast-align -Wcast-qual -Wpointer-arith \
+	-Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes \
+	-Wnested-externs -Wshadow -Wwrite-strings
+
 # Cross compiler debug flags.
-CROSS_GCC_DEBUG_FLAGS_FOR_ALL = -Dlint -g2 -fno-common -fstrict-aliasing \
-	-Wall -Wextra \
-	-Wbad-function-cast -Wcast-align -Wcast-qual \
-	-Wformat=2 -Winit-self \
-	-Wmissing-declarations -Wmissing-noreturn -Wmissing-prototypes \
-	-Wnested-externs -Wno-format-nonliteral -Wno-sign-compare \
-	-Wno-unused-parameter  -Wpointer-arith -Wshadow -Wstrict-prototypes \
-	-Wwrite-strings
-
-ifeq ($(CROSS_GCC_MAJOR),3)
-ifeq ($(CROSS_GCC_MINOR),4)
-CROSS_GCC_DEBUG_FLAGS = $(CROSS_GCC_DEBUG_FLAGS_FOR_ALL) -Wconversion
-Wtraditional
+ifeq ($(filter 2,$(CROSS_GCC_MAJOR)),)
+# gcc >= 3.x
+CROSS_GCC3_DFLAGS = -Wbad-function-cast -Wno-sign-compare -Wno-unused-parameter
+ifeq ($(filter 3,$(CROSS_GCC_MAJOR)),)
+ifeq ($(filter 4,$(CROSS_GCC_MAJOR)),)
+# gcc >= 5.x
+CROSS_GCC4_DFLAGS = -Wno-type-limits
+else
+# gcc >= 4.x
+ifeq ($(filter 0 1 2,$(CROSS_GCC_MINOR)),)
+# gcc >= 4.3
+CROSS_GCC4_DFLAGS = -Wno-type-limits
+endif
 endif
 endif
-
-ifeq ($(CROSS_GCC_MAJOR),4)
- ifeq ($(CROSS_GCC_MINOR),0)
-CROSS_GCC_DEBUG_FLAGS_SPECIAL =
- else
-  ifeq ($(CROSS_GCC_MINOR),1)
-CROSS_GCC_DEBUG_FLAGS_SPECIAL =
-  else
-   ifeq ($(CROSS_GCC_MINOR),2)
-CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
-   else
-    ifeq ($(CROSS_GCC_MINOR),3)
-CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
-Wno-sign-conversion -Wno-type-limits
-    else
-     ifeq ($(CROSS_GCC_MINOR),4)
-CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
-Wno-sign-conversion -Wno-type-limits
-     else
-      ifeq ($(CROSS_GCC_MINOR),5)
-CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
-Wno-sign-conversion -Wno-type-limits
-      else
-# gcc 4.6 and later works.
-CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
-Wno-sign-conversion -Wno-type-limits -Wsuggest-attribute=const
-Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines
-      endif
-     endif
-    endif
-   endif
-  endif
-CROSS_GCC_DEBUG_FLAGS = $(CROSS_GCC_DEBUG_FLAGS_FOR_ALL)
$(CROSS_GCC_DEBUG_FLAGS_SPECIAL)
- endif
 endif
+CROSS_GCC_DEBUG_FLAGS = $(COMMON_DEBUG_FLAGS) $(CROSS_GCC3_DFLAGS)
$(CROSS_GCC4_DFLAGS)

 # Native compiler debug flags.
-GCC_DEBUG_FLAGS_FOR_ALL = -Dlint -g2 -fno-common -fstrict-aliasing \
-	-Wall -Wextra \
-	-Wbad-function-cast -Wcast-align -Wcast-qual \
-	-Wformat=2 -Winit-self \
-	-Wmissing-declarations -Wmissing-noreturn -Wmissing-prototypes \
-	-Wnested-externs -Wno-format-nonliteral -Wno-sign-compare \
-	-Wno-unused-parameter  -Wpointer-arith -Wshadow -Wstrict-prototypes \
-	-Wwrite-strings
-
-ifeq ($(GCC_MAJOR),3)
-ifeq ($(GCC_MINOR),4)
-GCC_DEBUG_FLAGS = $(GCC_DEBUG_FLAGS_FOR_ALL) -Wconversion -Wtraditional
+ifeq ($(filter 2,$(GCC_MAJOR)),)
+# gcc >= 3.x
+GCC3_DEBUG_FLAGS = -Wbad-function-cast -Wno-sign-compare -Wno-unused-parameter
+ifeq ($(filter 3,$(GCC_MAJOR)),)
+ifeq ($(filter 4,$(GCC_MAJOR)),)
+# gcc >= 5.x
+GCC4_DEBUG_FLAGS = -Wno-type-limits
+else
+# gcc >= 4.x
+ifeq ($(filter 0 1 2,$(GCC_MINOR)),)
+# gcc >= 4.3
+GCC4_DEBUG_FLAGS = -Wno-type-limits
+endif
 endif
 endif
-
-ifeq ($(GCC_MAJOR),4)
- ifeq ($(GCC_MINOR),0)
-GCC_DEBUG_FLAGS_SPECIAL =
- else
-  ifeq ($(GCC_MINOR),1)
-GCC_DEBUG_FLAGS_SPECIAL =
-  else
-   ifeq ($(GCC_MINOR),2)
-GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
-   else
-    ifeq ($(GCC_MINOR),3)
-GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings -Wno-sign-conversion
-Wno-type-limits
-    else
-     ifeq ($(GCC_MINOR),4)
-GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings -Wno-sign-conversion
-Wno-type-limits
-     else
-      ifeq ($(GCC_MINOR),5)
-GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings -Wno-sign-conversion
-Wno-type-limits
-      else
-# gcc 4.6 and later works.
-GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings -Wno-sign-conversion
-Wno-type-limits -Wsuggest-attribute=const
-Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines
-      endif
-     endif
-    endif
-   endif
-  endif
-GCC_DEBUG_FLAGS = $(GCC_DEBUG_FLAGS_FOR_ALL) $(GCC_DEBUG_FLAGS_SPECIAL)
- endif
 endif
+GCC_DEBUG_FLAGS = $(COMMON_DEBUG_FLAGS) $(GCC3_DEBUG_FLAGS) $(GCC4_DEBUG_FLAGS)

 #
 # If you want to use System V compatibility code, add
@@ -349,7 +321,7 @@
 		-DHAVE_STRERROR=1 -DHAVE_SYMLINK=0 -DHAVE_STDINT_H=1\
 		-DSTD_INSPIRED \
 		-DLOCALE_HOME=\"/dev/env/DJDIR~c:/djgpp~/share/locale\" \
-		$(CROSS_GCC_DEBUG_FLAGS) -O2
+		$(CROSS_GCC_DEBUG_FLAGS) -O2 -nostdinc -I$(TOPDIR)/include

 # Flags for native compiler
 GCCFLAGS=	-DHAVE_ADJTIME=0 -DHAVE_LONG_DOUBLE=1 -DHAVE_SETTIMEOFDAY=1 \
@@ -368,7 +340,12 @@
 LDFLAGS=	$(LFLAGS)

 EXEEXT=		.exe
-zic=		./host-zic
+HOST_ZIC=	$(TOPDIR)/hostbin/zic$(EXEEXT)
+ifeq ($(CROSS_BUILD),1)
+zic=		$(HOST_ZIC)
+else
+zic=		zic$(EXEEXT)
+endif
 ZIC=		$(zic) $(ZFLAGS)

 # The name of a Posix-compliant `awk' on your system.
@@ -508,7 +485,7 @@
 		$(UTIL) cp zdump.man $(MANDIR)/cat8/zdump.8
 		$(UTIL) cp zic.man $(MANDIR)/cat8/zic.8

-all:		tzselect host-zic zic$(EXEEXT) zdump$(EXEEXT) $(LIBOBJS)
+all:		tzselect $(HOST_ZIC) zic$(EXEEXT) zdump$(EXEEXT) $(LIBOBJS)

 ALL:		all date$(EXEEXT)

@@ -517,18 +494,23 @@
 		 echo 'static char const TZVERSION[]="$(VERSION)";' && \
 		 echo 'static char const REPORT_BUGS_TO[]="$(BUGEMAIL)";') >$@

-zdump$(EXEEXT):	$(TZDOBJS)
-		$(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(TZDOBJS) $(LDLIBS)
-		$(CROSS_STRIP) $@
-
-host-zic:	$(TZCSRCS) yearistype version.h
+zdump$(EXEEXT):	$(TZDOBJS) $(TOPDIR)/lib/crt0.o $(TOPDIR)/lib/libc.a
+		$(CROSS_LD) -s $(LDFLAGS) $(TOPDIR)/lib/crt0.o $(TZDOBJS) -o $@
$(TOPDIR)/lib/libc.a $(LIBGCCA) -T $(DJGPP_DJL)
+		$(TOPDIR)/hostbin/stubify.exe $@
+
+ifneq ($(CROSS_BUILD),1)
+$(HOST_ZIC):	zic$(EXEEXT)
+		$(UTIL) cp zic$(EXEEXT) $(HOST_ZIC)
+else
+$(HOST_ZIC):	$(TZCSRCS) yearistype version.h
 		$(GCC) -DTZDIR=\"/dev/env/DJDIR~c:/djgpp~/zoneinfo\" \
 		$(GCCFLAGS) $(LDFLAGS) $(TZCSRCS) $(LDLIBS) -o $@
 		$(STRIP) $@
+endif

-zic$(EXEEXT):	$(TZCOBJS) yearistype
-		$(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(TZCOBJS) $(LDLIBS)
-		$(CROSS_STRIP) $@
+zic$(EXEEXT):	$(TZCOBJS) $(TOPDIR)/lib/crt0.o $(TOPDIR)/lib/libc.a yearistype
+		$(CROSS_LD) -s $(LDFLAGS) $(TOPDIR)/lib/crt0.o $(TZCOBJS) -o $@
$(TOPDIR)/lib/libc.a $(LIBGCCA) -T $(DJGPP_DJL)
+		$(TOPDIR)/hostbin/stubify.exe $@

 yearistype:	yearistype.sh
 		$(UTIL) cp yearistype.sh yearistype
@@ -578,15 +560,9 @@
 		-$(UTIL) mkdir $(LIBDIR)
 		$(CROSS_AR) rus $@ $(LIBOBJS)

-# We use the system's logwtmp in preference to ours if available.
-
-date$(EXEEXT):	$(DATEOBJS)
-		$(CROSS_AR) rs logwtmpl.a logwtmp.o
-		$(CC) $(CFLAGS) date.o localtime.o asctime.o strftime.o \
-			$(LDLIBS) -lc logwtmpl.a -o $@
-		$(CROSS_STRIP) $@
-		$(UTIL) rm logwtmpl.a
-		$(CROSS_STRIP) $@
+date$(EXEEXT):	$(DATEOBJS) $(TOPDIR)/lib/crt0.o $(TOPDIR)/lib/libc.a
+		$(CROSS_LD) -s $(LDFLAGS) $(TOPDIR)/lib/crt0.o $(DATEOBJS) -o $@
$(TOPDIR)/lib/libc.a $(LIBGCCA) -T $(DJGPP_DJL)
+		$(TOPDIR)/hostbin/stubify.exe $@

 tzselect:	tzselect.ksh
 		sed \
@@ -611,7 +587,7 @@

 clean_misc:
 		$(UTIL) rm core *.o *.out tzselect zdump$(EXEEXT) zic$(EXEEXT) \
-			yearistype date$(EXEEXT) logwtmpl* *.tar.gz host-zic *.exe *.man \
+			yearistype date$(EXEEXT) logwtmpl* *.tar.gz $(HOST_ZIC) *.exe *.man \
 			TDATA_list
 clean:		clean_misc
 		$(UTIL) rm -f -r tzpublic

--
O.S.

--001a113f7e1c72d1c30516bf7f27
Content-Type: text/plain; charset=US-ASCII; name="z4.diff"
Content-Disposition: attachment; filename="z4.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: file0

KiBidWlsZCB0eiBiaW5hcmllcyBhZ2FpbnN0IHNvdXJjZS10cmVlLCBub3QgYWdhaW5zdCB0b29s
Y2hhaW46Ci0gemljOiBkZWZpbmUgYXMgZG9zLXppYy5leGUgb3IgaG9zdC16aWMuZXhlIGRlcGVu
ZGluZyBvbiBjcm9zcwogIG9yIG5hdGl2ZSBidWlsZC4KLSBob3N0LXppYzogcGxhY2UgaW4gJChU
T1BESVIpL2hvc3RiaW4gbGlrZSBvdGhlciB1dGlscy4KLSBIT1NUX1pJQzogbmV3IHZhciBmb3Ig
J2hvc3QtemljJyBmb3IgY3Jvc3MtYnVpbGRzLgotIEhPU1RfWklDOiBkbyBub3QgYnVpbGQgaWYg
Y3Jvc3MtY29tcGlsaW5nLCBjb3B5IG92ZXIgdGFyZ2V0LQogIHppYy5leGUgdG8gaG9zdGJpbi8g
aW5zdGVhZC4KLSBMSUJHQ0NBLCBESkdQUF9ESkw6IGNvcGllZCBkZWZpdGluaW9ucyBmcm9tIHNy
Yy9tYWtlZmlsZS5pbmMuCi0gQ0ZMQUdTOiBhZGQgLW5vc3RkaW5jIC1JJChUT1BESVIpL2luY2x1
ZGUKLSBHQ0NGTEFHUzogKGtlcHQgaW50YWN0KQotIHpkdW1wLmV4ZSwgemljLmV4ZSwgZGF0ZS5l
eGU6IGNoYW5nZSBydWxlcyB0byBsaW5rIGFnYWluc3QKICBmcmVzaGx5IGJ1aWx0IGNydDAubyBh
bmQgbGliYy5hLgotIGRhdGUuZXhlOiByZW1vdmUgbG9nd3RtcGwuYSBidWlsZGluZywgYmVjYXVz
ZSBpdCB3YXMgbGlua2luZwogIHRvIGxvY2FsbHkgYnVpbHQgbG9nd3RtcGwuYSBhbmQgbG9nd3Rt
cC5vIGlzIHNpbXBseSBhbiBlbXB0eQogIG9iamVjdCBmb3IgZG9zLXRhcmdldGluZyBidWlsZHMu
Ci0gZGVidWcgZmxhZ3M6IG1hZGUgdGhlbSB0byB3b3JrIG9sZCBjb21waWxlcnMgdG9vLCBhbmQg
Y2xlYW5lZAogIGFuZCB0aWRpZWQgYSBiaXQuCgpJbmRleDogem9uZWluZm8vc3JjL21ha2VmaWxl
Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvZGpncHAvZGpncHAvem9uZWluZm8vc3JjL21ha2Vm
aWxlLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjE2CmRpZmYgLXUgLXIxLjE2IG1ha2VmaWxlCi0t
LSB6b25laW5mby9zcmMvbWFrZWZpbGUJMjYgTm92IDIwMTMgMTg6MDg6NTEgLTAwMDAJMS4xNgor
Kysgem9uZWluZm8vc3JjL21ha2VmaWxlCTIzIE1heSAyMDE1IDEyOjU1OjUwIC0wMDAwCkBAIC04
Nyw2ICs4NywyNyBAQAogQ1JPU1NfR0NDX01BSk9SIDo9ICQod29yZCAzLCAkKHNoZWxsIC4uLy4u
L3NyYy9taXNjLmV4ZSB8ICQoQ1JPU1NfR0NDKSAtRSAtZEQgLXggYyAtIHwgZWdyZXAgJ2RlZmlu
ZVwgKl9fR05VQ19fJykpCiBDUk9TU19HQ0NfTUlOT1IgOj0gJCh3b3JkIDMsICQoc2hlbGwgLi4v
Li4vc3JjL21pc2MuZXhlIHwgJChDUk9TU19HQ0MpIC1FIC1kRCAteCBjIC0gfCBlZ3JlcCAnZGVm
aW5lXCAqX19HTlVDX01JTk9SX18nKSkKIAorIyB2ZXJ5IG9sZCBnY2MsIGUuZy4gZ2NjLTIuOTUs
IGZhaWxzIHRoZSBhYm92ZSwgc28gd2UgaW52ZW50IGEgZGVmYXVsdC4KK2lmZXEgKCQoR0NDX01B
Sk9SKSwpCitHQ0NfTUFKT1IgOj0gMgorR0NDX01JTk9SIDo9IDcKK2VuZGlmCitpZmVxICgkKENS
T1NTX0dDQ19NQUpPUiksKQorQ1JPU1NfR0NDX01BSk9SIDo9IDIKK0NST1NTX0dDQ19NSU5PUiA6
PSA3CitlbmRpZgorCitpZmVxICgkKExJQkdDQ0EpLCkKK0xJQkdDQ0EgOj0gJChzaGVsbCAkKENS
T1NTX0dDQykgJChHQ0NfT1BUKSAtcHJpbnQtZmlsZS1uYW1lPWxpYmdjYy5hKQorTElCR0NDQSA6
PSAkKHN1YnN0IFwsLywkKExJQkdDQ0EpKQorZXhwb3J0IExJQkdDQ0EKK2VuZGlmCisKK2lmZXEg
KCQoREpHUFBfREpMKSwpCitESkdQUF9ESkwgPSAkKFRPUERJUikvbGliL2RqZ3BwLmRqbAorI2V4
cG9ydCBESkdQUF9ESkwKK2VuZGlmCisKICMgQSByZXBsYWNlbWVudCBmb3IgKHBvc3NpYmx5IG1p
c3NpbmcpIFVuaXggcHJvZ3JhbXM6CiAKIFVUSUw9CQkkKFRPUERJUikvc3JjL21pc2MuZXhlCkBA
IC0xNjIsOTcgKzE4Myw0OCBAQAogIwktV3N1Z2dlc3QtYXR0cmlidXRlPW5vcmV0dXJuIC1Xc3Vn
Z2VzdC1hdHRyaWJ1dGU9cHVyZSAtV3RyYW1wb2xpbmVzIFwKICMJLVd3cml0ZS1zdHJpbmdzCiAK
K0NPTU1PTl9ERUJVR19GTEFHUyA9IC1EbGludCAtZyAtZm5vLWNvbW1vbiAtZnN0cmljdC1hbGlh
c2luZyBcCisJLVdhbGwgLVcgLVdjYXN0LWFsaWduIC1XY2FzdC1xdWFsIC1XcG9pbnRlci1hcml0
aCBcCisJLVdtaXNzaW5nLWRlY2xhcmF0aW9ucyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3N0cmlj
dC1wcm90b3R5cGVzIFwKKwktV25lc3RlZC1leHRlcm5zIC1Xc2hhZG93IC1Xd3JpdGUtc3RyaW5n
cworCiAjIENyb3NzIGNvbXBpbGVyIGRlYnVnIGZsYWdzLgotQ1JPU1NfR0NDX0RFQlVHX0ZMQUdT
X0ZPUl9BTEwgPSAtRGxpbnQgLWcyIC1mbm8tY29tbW9uIC1mc3RyaWN0LWFsaWFzaW5nIFwKLQkt
V2FsbCAtV2V4dHJhIFwKLQktV2JhZC1mdW5jdGlvbi1jYXN0IC1XY2FzdC1hbGlnbiAtV2Nhc3Qt
cXVhbCBcCi0JLVdmb3JtYXQ9MiAtV2luaXQtc2VsZiBcCi0JLVdtaXNzaW5nLWRlY2xhcmF0aW9u
cyAtV21pc3Npbmctbm9yZXR1cm4gLVdtaXNzaW5nLXByb3RvdHlwZXMgXAotCS1XbmVzdGVkLWV4
dGVybnMgLVduby1mb3JtYXQtbm9ubGl0ZXJhbCAtV25vLXNpZ24tY29tcGFyZSBcCi0JLVduby11
bnVzZWQtcGFyYW1ldGVyICAtV3BvaW50ZXItYXJpdGggLVdzaGFkb3cgLVdzdHJpY3QtcHJvdG90
eXBlcyBcCi0JLVd3cml0ZS1zdHJpbmdzCi0KLWlmZXEgKCQoQ1JPU1NfR0NDX01BSk9SKSwzKQot
aWZlcSAoJChDUk9TU19HQ0NfTUlOT1IpLDQpCi1DUk9TU19HQ0NfREVCVUdfRkxBR1MgPSAkKENS
T1NTX0dDQ19ERUJVR19GTEFHU19GT1JfQUxMKSAtV2NvbnZlcnNpb24gLVd0cmFkaXRpb25hbAor
aWZlcSAoJChmaWx0ZXIgMiwkKENST1NTX0dDQ19NQUpPUikpLCkKKyMgZ2NjID49IDMueAorQ1JP
U1NfR0NDM19ERkxBR1MgPSAtV2JhZC1mdW5jdGlvbi1jYXN0IC1Xbm8tc2lnbi1jb21wYXJlIC1X
bm8tdW51c2VkLXBhcmFtZXRlcgoraWZlcSAoJChmaWx0ZXIgMywkKENST1NTX0dDQ19NQUpPUikp
LCkKK2lmZXEgKCQoZmlsdGVyIDQsJChDUk9TU19HQ0NfTUFKT1IpKSwpCisjIGdjYyA+PSA1LngK
K0NST1NTX0dDQzRfREZMQUdTID0gLVduby10eXBlLWxpbWl0cworZWxzZQorIyBnY2MgPj0gNC54
CitpZmVxICgkKGZpbHRlciAwIDEgMiwkKENST1NTX0dDQ19NSU5PUikpLCkKKyMgZ2NjID49IDQu
MworQ1JPU1NfR0NDNF9ERkxBR1MgPSAtV25vLXR5cGUtbGltaXRzCitlbmRpZgogZW5kaWYKIGVu
ZGlmCi0KLWlmZXEgKCQoQ1JPU1NfR0NDX01BSk9SKSw0KQotIGlmZXEgKCQoQ1JPU1NfR0NDX01J
Tk9SKSwwKQotQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTX1NQRUNJQUwgPSAKLSBlbHNlCi0gIGlmZXEg
KCQoQ1JPU1NfR0NDX01JTk9SKSwxKQotQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTX1NQRUNJQUwgPSAK
LSAgZWxzZQotICAgaWZlcSAoJChDUk9TU19HQ0NfTUlOT1IpLDIpCi1DUk9TU19HQ0NfREVCVUdf
RkxBR1NfU1BFQ0lBTCA9IC1Xb3Zlcmxlbmd0aC1zdHJpbmdzCi0gICBlbHNlCi0gICAgaWZlcSAo
JChDUk9TU19HQ0NfTUlOT1IpLDMpCi1DUk9TU19HQ0NfREVCVUdfRkxBR1NfU1BFQ0lBTCA9IC1X
b3Zlcmxlbmd0aC1zdHJpbmdzIC1Xbm8tc2lnbi1jb252ZXJzaW9uIC1Xbm8tdHlwZS1saW1pdHMK
LSAgICBlbHNlCi0gICAgIGlmZXEgKCQoQ1JPU1NfR0NDX01JTk9SKSw0KQotQ1JPU1NfR0NDX0RF
QlVHX0ZMQUdTX1NQRUNJQUwgPSAtV292ZXJsZW5ndGgtc3RyaW5ncyAtV25vLXNpZ24tY29udmVy
c2lvbiAtV25vLXR5cGUtbGltaXRzCi0gICAgIGVsc2UKLSAgICAgIGlmZXEgKCQoQ1JPU1NfR0ND
X01JTk9SKSw1KQotQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTX1NQRUNJQUwgPSAtV292ZXJsZW5ndGgt
c3RyaW5ncyAtV25vLXNpZ24tY29udmVyc2lvbiAtV25vLXR5cGUtbGltaXRzCi0gICAgICBlbHNl
Ci0jIGdjYyA0LjYgYW5kIGxhdGVyIHdvcmtzLgotQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTX1NQRUNJ
QUwgPSAtV292ZXJsZW5ndGgtc3RyaW5ncyAtV25vLXNpZ24tY29udmVyc2lvbiAtV25vLXR5cGUt
bGltaXRzIC1Xc3VnZ2VzdC1hdHRyaWJ1dGU9Y29uc3QgLVdzdWdnZXN0LWF0dHJpYnV0ZT1ub3Jl
dHVybiAtV3N1Z2dlc3QtYXR0cmlidXRlPXB1cmUgLVd0cmFtcG9saW5lcwotICAgICAgZW5kaWYK
LSAgICAgZW5kaWYKLSAgICBlbmRpZgotICAgZW5kaWYKLSAgZW5kaWYKLUNST1NTX0dDQ19ERUJV
R19GTEFHUyA9ICQoQ1JPU1NfR0NDX0RFQlVHX0ZMQUdTX0ZPUl9BTEwpICQoQ1JPU1NfR0NDX0RF
QlVHX0ZMQUdTX1NQRUNJQUwpCi0gZW5kaWYKIGVuZGlmCitDUk9TU19HQ0NfREVCVUdfRkxBR1Mg
PSAkKENPTU1PTl9ERUJVR19GTEFHUykgJChDUk9TU19HQ0MzX0RGTEFHUykgJChDUk9TU19HQ0M0
X0RGTEFHUykKIAogIyBOYXRpdmUgY29tcGlsZXIgZGVidWcgZmxhZ3MuCi1HQ0NfREVCVUdfRkxB
R1NfRk9SX0FMTCA9IC1EbGludCAtZzIgLWZuby1jb21tb24gLWZzdHJpY3QtYWxpYXNpbmcgXAot
CS1XYWxsIC1XZXh0cmEgXAotCS1XYmFkLWZ1bmN0aW9uLWNhc3QgLVdjYXN0LWFsaWduIC1XY2Fz
dC1xdWFsIFwKLQktV2Zvcm1hdD0yIC1XaW5pdC1zZWxmIFwKLQktV21pc3NpbmctZGVjbGFyYXRp
b25zIC1XbWlzc2luZy1ub3JldHVybiAtV21pc3NpbmctcHJvdG90eXBlcyBcCi0JLVduZXN0ZWQt
ZXh0ZXJucyAtV25vLWZvcm1hdC1ub25saXRlcmFsIC1Xbm8tc2lnbi1jb21wYXJlIFwKLQktV25v
LXVudXNlZC1wYXJhbWV0ZXIgIC1XcG9pbnRlci1hcml0aCAtV3NoYWRvdyAtV3N0cmljdC1wcm90
b3R5cGVzIFwKLQktV3dyaXRlLXN0cmluZ3MKLQotaWZlcSAoJChHQ0NfTUFKT1IpLDMpCi1pZmVx
ICgkKEdDQ19NSU5PUiksNCkKLUdDQ19ERUJVR19GTEFHUyA9ICQoR0NDX0RFQlVHX0ZMQUdTX0ZP
Ul9BTEwpIC1XY29udmVyc2lvbiAtV3RyYWRpdGlvbmFsCitpZmVxICgkKGZpbHRlciAyLCQoR0ND
X01BSk9SKSksKQorIyBnY2MgPj0gMy54CitHQ0MzX0RFQlVHX0ZMQUdTID0gLVdiYWQtZnVuY3Rp
b24tY2FzdCAtV25vLXNpZ24tY29tcGFyZSAtV25vLXVudXNlZC1wYXJhbWV0ZXIKK2lmZXEgKCQo
ZmlsdGVyIDMsJChHQ0NfTUFKT1IpKSwpCitpZmVxICgkKGZpbHRlciA0LCQoR0NDX01BSk9SKSks
KQorIyBnY2MgPj0gNS54CitHQ0M0X0RFQlVHX0ZMQUdTID0gLVduby10eXBlLWxpbWl0cworZWxz
ZQorIyBnY2MgPj0gNC54CitpZmVxICgkKGZpbHRlciAwIDEgMiwkKEdDQ19NSU5PUikpLCkKKyMg
Z2NjID49IDQuMworR0NDNF9ERUJVR19GTEFHUyA9IC1Xbm8tdHlwZS1saW1pdHMKK2VuZGlmCiBl
bmRpZgogZW5kaWYKLQotaWZlcSAoJChHQ0NfTUFKT1IpLDQpCi0gaWZlcSAoJChHQ0NfTUlOT1Ip
LDApCi1HQ0NfREVCVUdfRkxBR1NfU1BFQ0lBTCA9IAotIGVsc2UKLSAgaWZlcSAoJChHQ0NfTUlO
T1IpLDEpCi1HQ0NfREVCVUdfRkxBR1NfU1BFQ0lBTCA9IAotICBlbHNlCi0gICBpZmVxICgkKEdD
Q19NSU5PUiksMikKLUdDQ19ERUJVR19GTEFHU19TUEVDSUFMID0gLVdvdmVybGVuZ3RoLXN0cmlu
Z3MKLSAgIGVsc2UKLSAgICBpZmVxICgkKEdDQ19NSU5PUiksMykKLUdDQ19ERUJVR19GTEFHU19T
UEVDSUFMID0gLVdvdmVybGVuZ3RoLXN0cmluZ3MgLVduby1zaWduLWNvbnZlcnNpb24gLVduby10
eXBlLWxpbWl0cwotICAgIGVsc2UKLSAgICAgaWZlcSAoJChHQ0NfTUlOT1IpLDQpCi1HQ0NfREVC
VUdfRkxBR1NfU1BFQ0lBTCA9IC1Xb3Zlcmxlbmd0aC1zdHJpbmdzIC1Xbm8tc2lnbi1jb252ZXJz
aW9uIC1Xbm8tdHlwZS1saW1pdHMKLSAgICAgZWxzZQotICAgICAgaWZlcSAoJChHQ0NfTUlOT1Ip
LDUpCi1HQ0NfREVCVUdfRkxBR1NfU1BFQ0lBTCA9IC1Xb3Zlcmxlbmd0aC1zdHJpbmdzIC1Xbm8t
c2lnbi1jb252ZXJzaW9uIC1Xbm8tdHlwZS1saW1pdHMKLSAgICAgIGVsc2UKLSMgZ2NjIDQuNiBh
bmQgbGF0ZXIgd29ya3MuCi1HQ0NfREVCVUdfRkxBR1NfU1BFQ0lBTCA9IC1Xb3Zlcmxlbmd0aC1z
dHJpbmdzIC1Xbm8tc2lnbi1jb252ZXJzaW9uIC1Xbm8tdHlwZS1saW1pdHMgLVdzdWdnZXN0LWF0
dHJpYnV0ZT1jb25zdCAtV3N1Z2dlc3QtYXR0cmlidXRlPW5vcmV0dXJuIC1Xc3VnZ2VzdC1hdHRy
aWJ1dGU9cHVyZSAtV3RyYW1wb2xpbmVzCi0gICAgICBlbmRpZgotICAgICBlbmRpZgotICAgIGVu
ZGlmCi0gICBlbmRpZgotICBlbmRpZgotR0NDX0RFQlVHX0ZMQUdTID0gJChHQ0NfREVCVUdfRkxB
R1NfRk9SX0FMTCkgJChHQ0NfREVCVUdfRkxBR1NfU1BFQ0lBTCkKLSBlbmRpZgogZW5kaWYKK0dD
Q19ERUJVR19GTEFHUyA9ICQoQ09NTU9OX0RFQlVHX0ZMQUdTKSAkKEdDQzNfREVCVUdfRkxBR1Mp
ICQoR0NDNF9ERUJVR19GTEFHUykKIAogIwogIyBJZiB5b3Ugd2FudCB0byB1c2UgU3lzdGVtIFYg
Y29tcGF0aWJpbGl0eSBjb2RlLCBhZGQKQEAgLTM0OSw3ICszMjEsNyBAQAogCQktREhBVkVfU1RS
RVJST1I9MSAtREhBVkVfU1lNTElOSz0wIC1ESEFWRV9TVERJTlRfSD0xXAogCQktRFNURF9JTlNQ
SVJFRCBcCiAJCS1ETE9DQUxFX0hPTUU9XCIvZGV2L2Vudi9ESkRJUn5jOi9kamdwcH4vc2hhcmUv
bG9jYWxlXCIgXAotCQkkKENST1NTX0dDQ19ERUJVR19GTEFHUykgLU8yCisJCSQoQ1JPU1NfR0ND
X0RFQlVHX0ZMQUdTKSAtTzIgLW5vc3RkaW5jIC1JJChUT1BESVIpL2luY2x1ZGUKIAogIyBGbGFn
cyBmb3IgbmF0aXZlIGNvbXBpbGVyCiBHQ0NGTEFHUz0JLURIQVZFX0FESlRJTUU9MCAtREhBVkVf
TE9OR19ET1VCTEU9MSAtREhBVkVfU0VUVElNRU9GREFZPTEgXApAQCAtMzY4LDcgKzM0MCwxMiBA
QAogTERGTEFHUz0JJChMRkxBR1MpCiAKIEVYRUVYVD0JCS5leGUKLXppYz0JCS4vaG9zdC16aWMK
K0hPU1RfWklDPQkkKFRPUERJUikvaG9zdGJpbi96aWMkKEVYRUVYVCkKK2lmZXEgKCQoQ1JPU1Nf
QlVJTEQpLDEpCit6aWM9CQkkKEhPU1RfWklDKQorZWxzZQoremljPQkJemljJChFWEVFWFQpCitl
bmRpZgogWklDPQkJJCh6aWMpICQoWkZMQUdTKQogCiAjIFRoZSBuYW1lIG9mIGEgUG9zaXgtY29t
cGxpYW50IGBhd2snIG9uIHlvdXIgc3lzdGVtLgpAQCAtNTA4LDcgKzQ4NSw3IEBACiAJCSQoVVRJ
TCkgY3AgemR1bXAubWFuICQoTUFORElSKS9jYXQ4L3pkdW1wLjgKIAkJJChVVElMKSBjcCB6aWMu
bWFuICQoTUFORElSKS9jYXQ4L3ppYy44CiAKLWFsbDoJCXR6c2VsZWN0IGhvc3QtemljIHppYyQo
RVhFRVhUKSB6ZHVtcCQoRVhFRVhUKSAkKExJQk9CSlMpCithbGw6CQl0enNlbGVjdCAkKEhPU1Rf
WklDKSB6aWMkKEVYRUVYVCkgemR1bXAkKEVYRUVYVCkgJChMSUJPQkpTKQogCiBBTEw6CQlhbGwg
ZGF0ZSQoRVhFRVhUKQogCkBAIC01MTcsMTggKzQ5NCwyMyBAQAogCQkgZWNobyAnc3RhdGljIGNo
YXIgY29uc3QgVFpWRVJTSU9OW109IiQoVkVSU0lPTikiOycgJiYgXAogCQkgZWNobyAnc3RhdGlj
IGNoYXIgY29uc3QgUkVQT1JUX0JVR1NfVE9bXT0iJChCVUdFTUFJTCkiOycpID4kQAogCi16ZHVt
cCQoRVhFRVhUKToJJChUWkRPQkpTKQotCQkkKENDKSAtbyAkQCAkKENGTEFHUykgJChMREZMQUdT
KSAkKFRaRE9CSlMpICQoTERMSUJTKQotCQkkKENST1NTX1NUUklQKSAkQAotCi1ob3N0LXppYzoJ
JChUWkNTUkNTKSB5ZWFyaXN0eXBlIHZlcnNpb24uaAoremR1bXAkKEVYRUVYVCk6CSQoVFpET0JK
UykgJChUT1BESVIpL2xpYi9jcnQwLm8gJChUT1BESVIpL2xpYi9saWJjLmEKKwkJJChDUk9TU19M
RCkgLXMgJChMREZMQUdTKSAkKFRPUERJUikvbGliL2NydDAubyAkKFRaRE9CSlMpIC1vICRAICQo
VE9QRElSKS9saWIvbGliYy5hICQoTElCR0NDQSkgLVQgJChESkdQUF9ESkwpCisJCSQoVE9QRElS
KS9ob3N0YmluL3N0dWJpZnkuZXhlICRACisKK2lmbmVxICgkKENST1NTX0JVSUxEKSwxKQorJChI
T1NUX1pJQyk6CXppYyQoRVhFRVhUKQorCQkkKFVUSUwpIGNwIHppYyQoRVhFRVhUKSAkKEhPU1Rf
WklDKQorZWxzZQorJChIT1NUX1pJQyk6CSQoVFpDU1JDUykgeWVhcmlzdHlwZSB2ZXJzaW9uLmgK
IAkJJChHQ0MpIC1EVFpESVI9XCIvZGV2L2Vudi9ESkRJUn5jOi9kamdwcH4vem9uZWluZm9cIiBc
CiAJCSQoR0NDRkxBR1MpICQoTERGTEFHUykgJChUWkNTUkNTKSAkKExETElCUykgLW8gJEAKIAkJ
JChTVFJJUCkgJEAKK2VuZGlmCiAKLXppYyQoRVhFRVhUKToJJChUWkNPQkpTKSB5ZWFyaXN0eXBl
Ci0JCSQoQ0MpIC1vICRAICQoQ0ZMQUdTKSAkKExERkxBR1MpICQoVFpDT0JKUykgJChMRExJQlMp
Ci0JCSQoQ1JPU1NfU1RSSVApICRACit6aWMkKEVYRUVYVCk6CSQoVFpDT0JKUykgJChUT1BESVIp
L2xpYi9jcnQwLm8gJChUT1BESVIpL2xpYi9saWJjLmEgeWVhcmlzdHlwZQorCQkkKENST1NTX0xE
KSAtcyAkKExERkxBR1MpICQoVE9QRElSKS9saWIvY3J0MC5vICQoVFpDT0JKUykgLW8gJEAgJChU
T1BESVIpL2xpYi9saWJjLmEgJChMSUJHQ0NBKSAtVCAkKERKR1BQX0RKTCkKKwkJJChUT1BESVIp
L2hvc3RiaW4vc3R1YmlmeS5leGUgJEAKIAogeWVhcmlzdHlwZToJeWVhcmlzdHlwZS5zaAogCQkk
KFVUSUwpIGNwIHllYXJpc3R5cGUuc2ggeWVhcmlzdHlwZQpAQCAtNTc4LDE1ICs1NjAsOSBAQAog
CQktJChVVElMKSBta2RpciAkKExJQkRJUikKIAkJJChDUk9TU19BUikgcnVzICRAICQoTElCT0JK
UykKIAotIyBXZSB1c2UgdGhlIHN5c3RlbSdzIGxvZ3d0bXAgaW4gcHJlZmVyZW5jZSB0byBvdXJz
IGlmIGF2YWlsYWJsZS4KLQotZGF0ZSQoRVhFRVhUKToJJChEQVRFT0JKUykKLQkJJChDUk9TU19B
UikgcnMgbG9nd3RtcGwuYSBsb2d3dG1wLm8KLQkJJChDQykgJChDRkxBR1MpIGRhdGUubyBsb2Nh
bHRpbWUubyBhc2N0aW1lLm8gc3RyZnRpbWUubyBcCi0JCQkkKExETElCUykgLWxjIGxvZ3d0bXBs
LmEgLW8gJEAKLQkJJChDUk9TU19TVFJJUCkgJEAKLQkJJChVVElMKSBybSBsb2d3dG1wbC5hCi0J
CSQoQ1JPU1NfU1RSSVApICRACitkYXRlJChFWEVFWFQpOgkkKERBVEVPQkpTKSAkKFRPUERJUikv
bGliL2NydDAubyAkKFRPUERJUikvbGliL2xpYmMuYQorCQkkKENST1NTX0xEKSAtcyAkKExERkxB
R1MpICQoVE9QRElSKS9saWIvY3J0MC5vICQoREFURU9CSlMpIC1vICRAICQoVE9QRElSKS9saWIv
bGliYy5hICQoTElCR0NDQSkgLVQgJChESkdQUF9ESkwpCisJCSQoVE9QRElSKS9ob3N0YmluL3N0
dWJpZnkuZXhlICRACiAKIHR6c2VsZWN0Ogl0enNlbGVjdC5rc2gKIAkJc2VkIFwKQEAgLTYxMSw3
ICs1ODcsNyBAQAogCiBjbGVhbl9taXNjOgogCQkkKFVUSUwpIHJtIGNvcmUgKi5vICoub3V0IHR6
c2VsZWN0IHpkdW1wJChFWEVFWFQpIHppYyQoRVhFRVhUKSBcCi0JCQl5ZWFyaXN0eXBlIGRhdGUk
KEVYRUVYVCkgbG9nd3RtcGwqICoudGFyLmd6IGhvc3QtemljICouZXhlICoubWFuIFwKKwkJCXll
YXJpc3R5cGUgZGF0ZSQoRVhFRVhUKSBsb2d3dG1wbCogKi50YXIuZ3ogJChIT1NUX1pJQykgKi5l
eGUgKi5tYW4gXAogCQkJVERBVEFfbGlzdAogY2xlYW46CQljbGVhbl9taXNjCiAJCSQoVVRJTCkg
cm0gLWYgLXIgdHpwdWJsaWMK
--001a113f7e1c72d1c30516bf7f27--
0
Ozkan
5/23/2015 1:10:16 PM
> * dxe3gen.c: change the variable length array from [] to [0] so that
> it compiles using gcc2

What happens if you turn array bounds checking on?  Granted, this
isn't a system header so we have control over that, just wondering...
0
DJ
5/23/2015 6:37:08 PM
> -        va_arg(argp, int);  /* discard */
> +        _ulonglong = va_arg(argp, int);  /* discard */

Can we use (void)va_arg(...) instead, so the compiler doesn't ever
warn about (or try to optimize) an unused value?  Or was the warning
about an uninitialized variable?

0
DJ
5/23/2015 6:39:00 PM
On 5/23/15, DJ Delorie <dj@delorie.com> wrote:
>
>> * dxe3gen.c: change the variable length array from [] to [0] so that
>> it compiles using gcc2
>
> What happens if you turn array bounds checking on?

The same thing that would happen with search.h:struct qelem
or sys/system.h:_v1_stubinfo.  Not ever tried though.

>  Granted, this
> isn't a system header so we have control over that, just wondering...
>
0
Ozkan
5/23/2015 6:41:48 PM
On 5/23/15, DJ Delorie <dj@delorie.com> wrote:
>
>> -        va_arg(argp, int);  /* discard */
>> +        _ulonglong = va_arg(argp, int);  /* discard */
>
> Can we use (void)va_arg(...) instead, so the compiler doesn't ever
> warn about (or try to optimize) an unused value?  Or was the warning
> about an uninitialized variable?
>

The warning was 'computed value not used' or something like it, which
happened with gcc2.95, not with gcc3.3+.

As far as I can follow, that _ulonglong thing exists only for this
purpose, i.e. to discard the value (see the ARG() macro in there).
I _think_ we can instead use (void), but didn't try it myself (I don't
know how it would behave with __builtin_va_arg) and only followed the
existing style.
0
Ozkan
5/23/2015 6:50:09 PM
Am 24.05.2015 11:24, schrieb Eli Zaretskii (eliz@gnu.org):
>> Date: Sun, 24 May 2015 11:17:27 +0300
>> From: "Andris Pavenis (andris.pavenis@iki.fi)"<djgpp@delorie.com>
>>
>>> So what and how goes wrong in the DJGPP build of GDB?  Can someone
>>> with enough free time step through the go32 initialization, and see
>>> what's wrong there?
>>
>> Perhaps at least some hint could give GDB commit which caused that DJGPP port stopped to work (with
>> symptoms described earlier)
>>
>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=9b409511d07fe375284701af34909fb539029caf
>
> Thanks!
>
> Actually, it seems bd265cd0bde9e045ab5946532449430b66fe91ad, which is
> a followup to the one you mentioned, is the bad commit.  It seems a
> simple case of misunderstanding the API conventions of our read_child
> and write_child.
>
> Can you try the patch below?  If it fixes the problem, I will push it.
>
> diff --git a/gdb/go32-nat.c b/gdb/go32-nat.c
> index f3966cd..852473b 100644
> --- a/gdb/go32-nat.c
> +++ b/gdb/go32-nat.c
> @@ -587,6 +587,13 @@
>     else
>       res = read_child (memaddr, readbuf, len);
>
> +  /* read_child and write_child return zero on success, non-zero on
> +     failure; adjust the result value to that.  */
> +  if (res == 0)
> +    res = len;
> +  else
> +    res = -1;
> +
>     if (res<= 0)
>       return TARGET_XFER_E_IO;
>

I have tried the patch with gdb 7.9.1 and djgpp support seems to work again.
Neitherless sometimes backtrace and finish behave strange.  Please give me
some time more to check.  Especially with djgpp 2.05.

Regards,
Juan M. Guerrero


0
Juan
5/24/2015 1:01:01 AM
On 5/23/15, Ozkan Sezer <sezeroz@gmail.com> wrote:
> Updated patch for zoneinfo build system follows (also attached
> as a patch file.) Bulid tested using 2.03 and 2.05 cross toolchains,
> also successfully built under winxp using gcc-2.95 and djgpp-2.03
> based environment. If no objections, I plan to apply this tomorrow.
>
> * build tz binaries against source-tree, not against toolchain:
> - zic: define as dos-zic.exe or host-zic.exe depending on cross
>   or native build.
> - host-zic: place in $(TOPDIR)/hostbin like other utils.
> - HOST_ZIC: new var for 'host-zic' for cross-builds.
> - HOST_ZIC: do not build if cross-compiling, copy over target-
>   zic.exe to hostbin/ instead.
> - LIBGCCA, DJGPP_DJL: copied defitinions from src/makefile.inc.
> - CFLAGS: add -nostdinc -I$(TOPDIR)/include
> - GCCFLAGS: (kept intact)
> - zdump.exe, zic.exe, date.exe: change rules to link against
>   freshly built crt0.o and libc.a.
> - date.exe: remove logwtmpl.a building, because it was linking
>   to locally built logwtmpl.a and logwtmp.o is simply an empty
>   object for dos-targeting builds.
> - debug flags: made them to work old compilers too, and cleaned
>   and tidied a bit.
>
> Index: zoneinfo/src/makefile
> ===================================================================
> RCS file: /cvs/djgpp/djgpp/zoneinfo/src/makefile,v
> retrieving revision 1.16
> diff -u -r1.16 makefile
> --- zoneinfo/src/makefile	26 Nov 2013 18:08:51 -0000	1.16
> +++ zoneinfo/src/makefile	23 May 2015 12:55:50 -0000
> @@ -87,6 +87,27 @@
>  CROSS_GCC_MAJOR := $(word 3, $(shell ../../src/misc.exe |
> $(CROSS_GCC) -E -dD -x c - | egrep 'define\ *__GNUC__'))
>  CROSS_GCC_MINOR := $(word 3, $(shell ../../src/misc.exe |
> $(CROSS_GCC) -E -dD -x c - | egrep 'define\ *__GNUC_MINOR__'))
>
> +# very old gcc, e.g. gcc-2.95, fails the above, so we invent a default.
> +ifeq ($(GCC_MAJOR),)
> +GCC_MAJOR := 2
> +GCC_MINOR := 7
> +endif
> +ifeq ($(CROSS_GCC_MAJOR),)
> +CROSS_GCC_MAJOR := 2
> +CROSS_GCC_MINOR := 7
> +endif
> +
> +ifeq ($(LIBGCCA),)
> +LIBGCCA := $(shell $(CROSS_GCC) $(GCC_OPT) -print-file-name=libgcc.a)
> +LIBGCCA := $(subst \,/,$(LIBGCCA))
> +export LIBGCCA
> +endif
> +
> +ifeq ($(DJGPP_DJL),)
> +DJGPP_DJL = $(TOPDIR)/lib/djgpp.djl
> +#export DJGPP_DJL
> +endif
> +
>  # A replacement for (possibly missing) Unix programs:
>
>  UTIL=		$(TOPDIR)/src/misc.exe
> @@ -162,97 +183,48 @@
>  #	-Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines \
>  #	-Wwrite-strings
>
> +COMMON_DEBUG_FLAGS = -Dlint -g -fno-common -fstrict-aliasing \
> +	-Wall -W -Wcast-align -Wcast-qual -Wpointer-arith \
> +	-Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes \
> +	-Wnested-externs -Wshadow -Wwrite-strings
> +
>  # Cross compiler debug flags.
> -CROSS_GCC_DEBUG_FLAGS_FOR_ALL = -Dlint -g2 -fno-common -fstrict-aliasing \
> -	-Wall -Wextra \
> -	-Wbad-function-cast -Wcast-align -Wcast-qual \
> -	-Wformat=2 -Winit-self \
> -	-Wmissing-declarations -Wmissing-noreturn -Wmissing-prototypes \
> -	-Wnested-externs -Wno-format-nonliteral -Wno-sign-compare \
> -	-Wno-unused-parameter  -Wpointer-arith -Wshadow -Wstrict-prototypes \
> -	-Wwrite-strings
> -
> -ifeq ($(CROSS_GCC_MAJOR),3)
> -ifeq ($(CROSS_GCC_MINOR),4)
> -CROSS_GCC_DEBUG_FLAGS = $(CROSS_GCC_DEBUG_FLAGS_FOR_ALL) -Wconversion
> -Wtraditional
> +ifeq ($(filter 2,$(CROSS_GCC_MAJOR)),)
> +# gcc >= 3.x
> +CROSS_GCC3_DFLAGS = -Wbad-function-cast -Wno-sign-compare
> -Wno-unused-parameter
> +ifeq ($(filter 3,$(CROSS_GCC_MAJOR)),)
> +ifeq ($(filter 4,$(CROSS_GCC_MAJOR)),)
> +# gcc >= 5.x
> +CROSS_GCC4_DFLAGS = -Wno-type-limits
> +else
> +# gcc >= 4.x
> +ifeq ($(filter 0 1 2,$(CROSS_GCC_MINOR)),)
> +# gcc >= 4.3
> +CROSS_GCC4_DFLAGS = -Wno-type-limits
> +endif
>  endif
>  endif
> -
> -ifeq ($(CROSS_GCC_MAJOR),4)
> - ifeq ($(CROSS_GCC_MINOR),0)
> -CROSS_GCC_DEBUG_FLAGS_SPECIAL =
> - else
> -  ifeq ($(CROSS_GCC_MINOR),1)
> -CROSS_GCC_DEBUG_FLAGS_SPECIAL =
> -  else
> -   ifeq ($(CROSS_GCC_MINOR),2)
> -CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
> -   else
> -    ifeq ($(CROSS_GCC_MINOR),3)
> -CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
> -Wno-sign-conversion -Wno-type-limits
> -    else
> -     ifeq ($(CROSS_GCC_MINOR),4)
> -CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
> -Wno-sign-conversion -Wno-type-limits
> -     else
> -      ifeq ($(CROSS_GCC_MINOR),5)
> -CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
> -Wno-sign-conversion -Wno-type-limits
> -      else
> -# gcc 4.6 and later works.
> -CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
> -Wno-sign-conversion -Wno-type-limits -Wsuggest-attribute=const
> -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines
> -      endif
> -     endif
> -    endif
> -   endif
> -  endif
> -CROSS_GCC_DEBUG_FLAGS = $(CROSS_GCC_DEBUG_FLAGS_FOR_ALL)
> $(CROSS_GCC_DEBUG_FLAGS_SPECIAL)
> - endif
>  endif
> +CROSS_GCC_DEBUG_FLAGS = $(COMMON_DEBUG_FLAGS) $(CROSS_GCC3_DFLAGS)
> $(CROSS_GCC4_DFLAGS)
>
>  # Native compiler debug flags.
> -GCC_DEBUG_FLAGS_FOR_ALL = -Dlint -g2 -fno-common -fstrict-aliasing \
> -	-Wall -Wextra \
> -	-Wbad-function-cast -Wcast-align -Wcast-qual \
> -	-Wformat=2 -Winit-self \
> -	-Wmissing-declarations -Wmissing-noreturn -Wmissing-prototypes \
> -	-Wnested-externs -Wno-format-nonliteral -Wno-sign-compare \
> -	-Wno-unused-parameter  -Wpointer-arith -Wshadow -Wstrict-prototypes \
> -	-Wwrite-strings
> -
> -ifeq ($(GCC_MAJOR),3)
> -ifeq ($(GCC_MINOR),4)
> -GCC_DEBUG_FLAGS = $(GCC_DEBUG_FLAGS_FOR_ALL) -Wconversion -Wtraditional
> +ifeq ($(filter 2,$(GCC_MAJOR)),)
> +# gcc >= 3.x
> +GCC3_DEBUG_FLAGS = -Wbad-function-cast -Wno-sign-compare
> -Wno-unused-parameter
> +ifeq ($(filter 3,$(GCC_MAJOR)),)
> +ifeq ($(filter 4,$(GCC_MAJOR)),)
> +# gcc >= 5.x
> +GCC4_DEBUG_FLAGS = -Wno-type-limits
> +else
> +# gcc >= 4.x
> +ifeq ($(filter 0 1 2,$(GCC_MINOR)),)
> +# gcc >= 4.3
> +GCC4_DEBUG_FLAGS = -Wno-type-limits
> +endif
>  endif
>  endif
> -
> -ifeq ($(GCC_MAJOR),4)
> - ifeq ($(GCC_MINOR),0)
> -GCC_DEBUG_FLAGS_SPECIAL =
> - else
> -  ifeq ($(GCC_MINOR),1)
> -GCC_DEBUG_FLAGS_SPECIAL =
> -  else
> -   ifeq ($(GCC_MINOR),2)
> -GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
> -   else
> -    ifeq ($(GCC_MINOR),3)
> -GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings -Wno-sign-conversion
> -Wno-type-limits
> -    else
> -     ifeq ($(GCC_MINOR),4)
> -GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings -Wno-sign-conversion
> -Wno-type-limits
> -     else
> -      ifeq ($(GCC_MINOR),5)
> -GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings -Wno-sign-conversion
> -Wno-type-limits
> -      else
> -# gcc 4.6 and later works.
> -GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings -Wno-sign-conversion
> -Wno-type-limits -Wsuggest-attribute=const
> -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines
> -      endif
> -     endif
> -    endif
> -   endif
> -  endif
> -GCC_DEBUG_FLAGS = $(GCC_DEBUG_FLAGS_FOR_ALL) $(GCC_DEBUG_FLAGS_SPECIAL)
> - endif
>  endif
> +GCC_DEBUG_FLAGS = $(COMMON_DEBUG_FLAGS) $(GCC3_DEBUG_FLAGS)
> $(GCC4_DEBUG_FLAGS)
>
>  #
>  # If you want to use System V compatibility code, add
> @@ -349,7 +321,7 @@
>  		-DHAVE_STRERROR=1 -DHAVE_SYMLINK=0 -DHAVE_STDINT_H=1\
>  		-DSTD_INSPIRED \
>  		-DLOCALE_HOME=\"/dev/env/DJDIR~c:/djgpp~/share/locale\" \
> -		$(CROSS_GCC_DEBUG_FLAGS) -O2
> +		$(CROSS_GCC_DEBUG_FLAGS) -O2 -nostdinc -I$(TOPDIR)/include
>
>  # Flags for native compiler
>  GCCFLAGS=	-DHAVE_ADJTIME=0 -DHAVE_LONG_DOUBLE=1 -DHAVE_SETTIMEOFDAY=1 \
> @@ -368,7 +340,12 @@
>  LDFLAGS=	$(LFLAGS)
>
>  EXEEXT=		.exe
> -zic=		./host-zic
> +HOST_ZIC=	$(TOPDIR)/hostbin/zic$(EXEEXT)
> +ifeq ($(CROSS_BUILD),1)
> +zic=		$(HOST_ZIC)
> +else
> +zic=		zic$(EXEEXT)
> +endif
>  ZIC=		$(zic) $(ZFLAGS)
>
>  # The name of a Posix-compliant `awk' on your system.
> @@ -508,7 +485,7 @@
>  		$(UTIL) cp zdump.man $(MANDIR)/cat8/zdump.8
>  		$(UTIL) cp zic.man $(MANDIR)/cat8/zic.8
>
> -all:		tzselect host-zic zic$(EXEEXT) zdump$(EXEEXT) $(LIBOBJS)
> +all:		tzselect $(HOST_ZIC) zic$(EXEEXT) zdump$(EXEEXT) $(LIBOBJS)
>
>  ALL:		all date$(EXEEXT)
>
> @@ -517,18 +494,23 @@
>  		 echo 'static char const TZVERSION[]="$(VERSION)";' && \
>  		 echo 'static char const REPORT_BUGS_TO[]="$(BUGEMAIL)";') >$@
>
> -zdump$(EXEEXT):	$(TZDOBJS)
> -		$(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(TZDOBJS) $(LDLIBS)
> -		$(CROSS_STRIP) $@
> -
> -host-zic:	$(TZCSRCS) yearistype version.h
> +zdump$(EXEEXT):	$(TZDOBJS) $(TOPDIR)/lib/crt0.o $(TOPDIR)/lib/libc.a
> +		$(CROSS_LD) -s $(LDFLAGS) $(TOPDIR)/lib/crt0.o $(TZDOBJS) -o $@
> $(TOPDIR)/lib/libc.a $(LIBGCCA) -T $(DJGPP_DJL)
> +		$(TOPDIR)/hostbin/stubify.exe $@
> +
> +ifneq ($(CROSS_BUILD),1)
> +$(HOST_ZIC):	zic$(EXEEXT)
> +		$(UTIL) cp zic$(EXEEXT) $(HOST_ZIC)
> +else
> +$(HOST_ZIC):	$(TZCSRCS) yearistype version.h
>  		$(GCC) -DTZDIR=\"/dev/env/DJDIR~c:/djgpp~/zoneinfo\" \
>  		$(GCCFLAGS) $(LDFLAGS) $(TZCSRCS) $(LDLIBS) -o $@
>  		$(STRIP) $@
> +endif
>
> -zic$(EXEEXT):	$(TZCOBJS) yearistype
> -		$(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(TZCOBJS) $(LDLIBS)
> -		$(CROSS_STRIP) $@
> +zic$(EXEEXT):	$(TZCOBJS) $(TOPDIR)/lib/crt0.o $(TOPDIR)/lib/libc.a
> yearistype
> +		$(CROSS_LD) -s $(LDFLAGS) $(TOPDIR)/lib/crt0.o $(TZCOBJS) -o $@
> $(TOPDIR)/lib/libc.a $(LIBGCCA) -T $(DJGPP_DJL)
> +		$(TOPDIR)/hostbin/stubify.exe $@
>
>  yearistype:	yearistype.sh
>  		$(UTIL) cp yearistype.sh yearistype
> @@ -578,15 +560,9 @@
>  		-$(UTIL) mkdir $(LIBDIR)
>  		$(CROSS_AR) rus $@ $(LIBOBJS)
>
> -# We use the system's logwtmp in preference to ours if available.
> -
> -date$(EXEEXT):	$(DATEOBJS)
> -		$(CROSS_AR) rs logwtmpl.a logwtmp.o
> -		$(CC) $(CFLAGS) date.o localtime.o asctime.o strftime.o \
> -			$(LDLIBS) -lc logwtmpl.a -o $@
> -		$(CROSS_STRIP) $@
> -		$(UTIL) rm logwtmpl.a
> -		$(CROSS_STRIP) $@
> +date$(EXEEXT):	$(DATEOBJS) $(TOPDIR)/lib/crt0.o $(TOPDIR)/lib/libc.a
> +		$(CROSS_LD) -s $(LDFLAGS) $(TOPDIR)/lib/crt0.o $(DATEOBJS) -o $@
> $(TOPDIR)/lib/libc.a $(LIBGCCA) -T $(DJGPP_DJL)
> +		$(TOPDIR)/hostbin/stubify.exe $@
>
>  tzselect:	tzselect.ksh
>  		sed \
> @@ -611,7 +587,7 @@
>
>  clean_misc:
>  		$(UTIL) rm core *.o *.out tzselect zdump$(EXEEXT) zic$(EXEEXT) \
> -			yearistype date$(EXEEXT) logwtmpl* *.tar.gz host-zic *.exe *.man \
> +			yearistype date$(EXEEXT) logwtmpl* *.tar.gz $(HOST_ZIC) *.exe *.man \
>  			TDATA_list
>  clean:		clean_misc
>  		$(UTIL) rm -f -r tzpublic
>
> --
> O.S.
>

Applied
0
Ozkan
5/24/2015 7:52:21 AM
On 05/21/2015 07:01 PM, Eli Zaretskii (eliz@gnu.org) wrote:
>> Date: Thu, 21 May 2015 07:25:20 +0300
>> From: "Andris Pavenis (andris.pavenis@iki.fi)" <djgpp@delorie.com>
>>
>> This change is most likely only a result of other changes. So if we do not know these other changes
>> it would be very difficult to see whether that go32-nat.c change is actually OK or some detail is
>> accidentally left out.
> Juan quoted a discussion from a year ago, which ended with this
> conclusion:
>
>>>> (gdb) r
>>>> Starting program: h:/l/bins/bin/a.exe
>>>> Warning:
>>>> Cannot insert breakpoint 1.
>>>> Cannot access memory at address 0x1e04
>>> This means inserting a breakpoint at 0x1e04 returned EIO.  I suggest
>>> to take a good look at the code that's involved in this.  I see that
>>> in GDB-7.7.1, we had these 2 lines in go32-nat.c:
>>>
>>>     go32_ops.to_insert_breakpoint = memory_insert_breakpoint;
>>>     go32_ops.to_remove_breakpoint = memory_remove_breakpoint;
>>>
>>> but these lines are no longer there, and instead the go32 target
>>> inherits from inf_child_target.  Perhaps that's the cause of the
>>> problem.
>> Thank you for the pointer.  The change from the old way to handle the
>> native support to the new way of initializing struct target_ops inf_child_ops
>> by inf_child_target and go32_target seems to be the source of the difficulties.
>> At least go32_ops.to_insert_breakpoint and go32_ops.to_remove_breakpoint are
>> not set to the corresponding equivalent new variables for DJGPP.
> Can we pick up where this was left off?
>
> FWIW, I don't understand what Juan wrote back then: go32_ops no longer
> exists in the current sources.  Instead, the initialization calls
> go32_target, which does this:
>
>    static struct target_ops *
>    go32_target (void)
>    {
>      struct target_ops *t = inf_child_target ();
>
> In inf_child_target, I see that to_insert_breakpoint and
> to_remove_breakpoint are correctly assigned:
>
>    struct target_ops *
>    inf_child_target (void)
>    {
>      struct target_ops *t = XCNEW (struct target_ops);
>
>    [...]
>      t->to_insert_breakpoint = memory_insert_breakpoint;
>      t->to_remove_breakpoint = memory_remove_breakpoint;
>
> Back in the go32-nat initialization function, we have this call, after
> all the members of target_ops were initialized:
>
>    add_target (t);
>
> where before GDB 7.8 it did this instead:
>
>    add_target (&go32_ops);
>
> This all looks OK to me, and I just stepped through the corresponding
> code for the MinGW native target and saw that it does the same (and
> certainly works, as I use it every day).
>
> So what and how goes wrong in the DJGPP build of GDB?  Can someone
> with enough free time step through the go32 initialization, and see
> what's wrong there?

Perhaps at least some hint could give GDB commit which caused that DJGPP port stopped to work (with 
symptoms described earlier)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=9b409511d07fe375284701af34909fb539029caf

Debugging DJGPP programs worked before this commit, but not after that. Used test executable for 
testing whether GDB works OK was cc1.exe from my build of gcc-4.8.4 (HDDs are large now and I still 
have build directory) in stage 3. Tested criteria: successful stepping into program, no error 
messages, backtrace works reasonably well.

Andris




0
Andris
5/24/2015 8:17:27 AM
> Date: Sun, 24 May 2015 11:17:27 +0300
> From: "Andris Pavenis (andris.pavenis@iki.fi)" <djgpp@delorie.com>
> 
> > So what and how goes wrong in the DJGPP build of GDB?  Can someone
> > with enough free time step through the go32 initialization, and see
> > what's wrong there?
> 
> Perhaps at least some hint could give GDB commit which caused that DJGPP port stopped to work (with 
> symptoms described earlier)
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=9b409511d07fe375284701af34909fb539029caf

Thanks!

Actually, it seems bd265cd0bde9e045ab5946532449430b66fe91ad, which is
a followup to the one you mentioned, is the bad commit.  It seems a
simple case of misunderstanding the API conventions of our read_child
and write_child.

Can you try the patch below?  If it fixes the problem, I will push it.

diff --git a/gdb/go32-nat.c b/gdb/go32-nat.c
index f3966cd..852473b 100644
--- a/gdb/go32-nat.c
+++ b/gdb/go32-nat.c
@@ -587,6 +587,13 @@
   else
     res = read_child (memaddr, readbuf, len);
 
+  /* read_child and write_child return zero on success, non-zero on
+     failure; adjust the result value to that.  */
+  if (res == 0)
+    res = len;
+  else
+    res = -1;
+
   if (res <= 0)
     return TARGET_XFER_E_IO;
 
0
Eli
5/24/2015 9:24:32 AM
> Date: Sun, 24 May 2015 14:48:32 +0200
> From: "Juan Manuel Guerrero (juan.guerrero@gmx.de)" <djgpp@delorie.com>
> 
> > Can you try the patch below?  If it fixes the problem, I will push it.
> >
> > diff --git a/gdb/go32-nat.c b/gdb/go32-nat.c
> > index f3966cd..852473b 100644
> > --- a/gdb/go32-nat.c
> > +++ b/gdb/go32-nat.c
> > @@ -587,6 +587,13 @@
> >     else
> >       res = read_child (memaddr, readbuf, len);
> >
> > +  /* read_child and write_child return zero on success, non-zero on
> > +     failure; adjust the result value to that.  */
> > +  if (res == 0)
> > +    res = len;
> > +  else
> > +    res = -1;
> > +
> >     if (res<= 0)
> >       return TARGET_XFER_E_IO;
> >
> 
> I have tried the patch with gdb 7.9.1 and djgpp support seems to work again.
> Neitherless sometimes backtrace and finish behave strange.  Please give me
> some time more to check.  Especially with djgpp 2.05.

Thanks for testing.

Is there a reason to withhold this patch?  The issues you describe are
probably additional problems, unrelated to this one.

But if you'd like me to wait, I will.
0
Eli
5/24/2015 2:39:21 PM
Am 24.05.2015 16:39, schrieb Eli Zaretskii (eliz@gnu.org):
>> Date: Sun, 24 May 2015 14:48:32 +0200
>> From: "Juan Manuel Guerrero (juan.guerrero@gmx.de)"<djgpp@delorie.com>
>>
>>> Can you try the patch below?  If it fixes the problem, I will push it.
>>>
>>> diff --git a/gdb/go32-nat.c b/gdb/go32-nat.c
>>> index f3966cd..852473b 100644
>>> --- a/gdb/go32-nat.c
>>> +++ b/gdb/go32-nat.c
>>> @@ -587,6 +587,13 @@
>>>      else
>>>        res = read_child (memaddr, readbuf, len);
>>>
>>> +  /* read_child and write_child return zero on success, non-zero on
>>> +     failure; adjust the result value to that.  */
>>> +  if (res == 0)
>>> +    res = len;
>>> +  else
>>> +    res = -1;
>>> +
>>>      if (res<= 0)
>>>        return TARGET_XFER_E_IO;
>>>
>>
>> I have tried the patch with gdb 7.9.1 and djgpp support seems to work again.
>> Neitherless sometimes backtrace and finish behave strange.  Please give me
>> some time more to check.  Especially with djgpp 2.05.
>
> Thanks for testing.
>
> Is there a reason to withhold this patch?  The issues you describe are
> probably additional problems, unrelated to this one.
>
> But if you'd like me to wait, I will.

If you known that the issues are not related to each other then there is no reason to withhold the patch.
Plaes go ahead an commit the patch.

Regards,
Juan M. Guerrero
0
Juan
5/24/2015 3:01:57 PM
> Date: Sun, 24 May 2015 17:01:57 +0200
> From: "Juan Manuel Guerrero (juan.guerrero@gmx.de)" <djgpp@delorie.com>
> 
> If you known that the issues are not related to each other then there is no reason to withhold the patch.
> Please go ahead and commit the patch.

Thanks, I've posted the patch for review to the GDB mailing list, and
will commit in a few days, barring any objections.
0
Eli
5/24/2015 3:21:47 PM
Am 24.05.2015 14:48, schrieb Juan Manuel Guerrero (juan.guerrero@gmx.de):
> Am 24.05.2015 11:24, schrieb Eli Zaretskii (eliz@gnu.org):
>>> Date: Sun, 24 May 2015 11:17:27 +0300
>>> From: "Andris Pavenis (andris.pavenis@iki.fi)"<djgpp@delorie.com>
>>>
>>>> So what and how goes wrong in the DJGPP build of GDB? Can someone
>>>> with enough free time step through the go32 initialization, and see
>>>> what's wrong there?
>>>
>>> Perhaps at least some hint could give GDB commit which caused that DJGPP port stopped to work (with
>>> symptoms described earlier)
>>>
>>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=9b409511d07fe375284701af34909fb539029caf
>>
>> Thanks!
>>
>> Actually, it seems bd265cd0bde9e045ab5946532449430b66fe91ad, which is
>> a followup to the one you mentioned, is the bad commit. It seems a
>> simple case of misunderstanding the API conventions of our read_child
>> and write_child.
>>
>> Can you try the patch below? If it fixes the problem, I will push it.
>>
>> diff --git a/gdb/go32-nat.c b/gdb/go32-nat.c
>> index f3966cd..852473b 100644
>> --- a/gdb/go32-nat.c
>> +++ b/gdb/go32-nat.c
>> @@ -587,6 +587,13 @@
>> else
>> res = read_child (memaddr, readbuf, len);
>>
>> + /* read_child and write_child return zero on success, non-zero on
>> + failure; adjust the result value to that. */
>> + if (res == 0)
>> + res = len;
>> + else
>> + res = -1;
>> +
>> if (res<= 0)
>> return TARGET_XFER_E_IO;
>>
>
> I have tried the patch with gdb 7.9.1 and djgpp support seems to work again.
> Neitherless sometimes backtrace and finish behave strange. Please give me
> some time more to check. Especially with djgpp 2.05.
>
> Regards,
> Juan M. Guerrero
>
>


OFYI,
I have compiled the repository code from yesterday using GCC 4.9.2 and GNU Binutils 2.24.
I have used -O0 -ggdb flags.  This was intentional to be able to step into functions.
The produced library has been installed and used to compile GDB 7.9.1.

The following test program has been compiled using -O0 -ggdb:
-------------  program start -------------
#include <stdio.h>


int print(const char *message)
{
   int written;

   written = printf("%s\n", message);

   return written;
}

int main(void)
{
   int written = 0;

   written = print("qwertz");

   return written;
}
-------------  program end -------------

Steppinng into the code works well.
If I step into printf() and I issue the bt command I get the following
output:

(gdb) r
Starting program: c:/tmp/5/a.exe

Breakpoint 1, main () at a.c:15
15        int written = 0;
(gdb) s
17        written = print("qwertz");
(gdb)
print (message=0x1f35 <print+33> "qwertz") at a.c:8
8         written = printf("%s\n", message);
(gdb)
printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:10
10      {
(gdb)
printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:14
14        va_start(args, fmt);
(gdb) n
15        len = _doprnt(fmt, args, stdout);
(gdb) bt
#0  printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:15
#1  0x00003316 in nofpsig () at npxsetup.c:51
#2  0x00000006 in ?? ()
#3  0x00001f2a in print (message=0x1f35 <print+33> "qwertz") at a.c:8
#4  0x00001f61 in main () at a.c:17
(gdb)



The remarkable issue is that although I used the n command to avoid stepping
into _doprnt() gdb behaves as if the s command had been used.  After having
stepped into _doprnt() I get the following output for the bt command:

10      {
(gdb)
printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:14
14        va_start(args, fmt);
(gdb) n
15        len = _doprnt(fmt, args, stdout);
(gdb) bt
#0  printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:15
#1  0x00003316 in nofpsig () at npxsetup.c:51
#2  0x00000006 in ?? ()
#3  0x00001f2a in print (message=0x1f35 <print+33> "qwertz") at a.c:8
#4  0x00001f61 in main () at a.c:17
(gdb) n
_doprnt (fmt0=0x1f10 <_crt0_init_mcount+10> "%s\n", argp=0x99b24 "5\037",
     fp=0x11db0 <__dj_stdout>) at doprnt.c:119
119     {
(gdb)
148       locale_info = localeconv();
(gdb)
149       decimal_point = locale_info->decimal_point[0];
(gdb) bt
#0  _doprnt (fmt0=0x1f10 <_crt0_init_mcount+10> "%s\n", argp=0x99b24 "5\037",
     fp=0x11db0 <__dj_stdout>) at doprnt.c:149
#1  0x00000000 in ?? ()
(gdb)



If I issue the finish command to run until the end of the function
I get the following output:

#0  printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:15
#1  0x00003316 in nofpsig () at npxsetup.c:51
#2  0x00000006 in ?? ()
#3  0x00001f2a in print (message=0x1f35 <print+33> "qwertz") at a.c:8
#4  0x00001f61 in main () at a.c:17
(gdb) n
_doprnt (fmt0=0x1f10 <_crt0_init_mcount+10> "%s\n", argp=0x99b24 "5\037",
     fp=0x11db0 <__dj_stdout>) at doprnt.c:119
119     {
(gdb)
148       locale_info = localeconv();
(gdb)
149       decimal_point = locale_info->decimal_point[0];
(gdb) bt
#0  _doprnt (fmt0=0x1f10 <_crt0_init_mcount+10> "%s\n", argp=0x99b24 "5\037",
     fp=0x11db0 <__dj_stdout>) at doprnt.c:149
#1  0x00000000 in ?? ()
(gdb) finish
Run till exit from #0  _doprnt (fmt0=0x1f10 <_crt0_init_mcount+10> "%s\n",
     argp=0x99b24 "5\037", fp=0x11db0 <__dj_stdout>) at doprnt.c:149
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x0

(gdb)



If more information is required please let me know.

Regards,
Juan M. Guerrero

0
Juan
5/24/2015 3:46:42 PM
> Date: Sun, 24 May 2015 17:46:42 +0200
> From: "Juan Manuel Guerrero (juan.guerrero@gmx.de)" <djgpp@delorie.com>
> 
> The following test program has been compiled using -O0 -ggdb:

What does -ggdb mean with the DJGPP build of GCC 4.9.2?  It is better
to use an explicit debug info option (see below).

What does GDB say when you step into 'main' and type

 (gdb) info source

One of the things it should announce is the type of debug info it
found in the program.

In any case, I suggest to try this experiment with all 3 debug info
types, COFF, stabs, and DWARF.  To that end, instead of -ggdb, please
use "-gcoff -g3", "-gstabs -g3", and "-gdwarf-2 -g3", respectively.
(You could also try -gdwarf-3 and -gdwarf-4, not sure if the DJGPP
build of GCC supports that.)

> If I step into printf() and I issue the bt command I get the following
> output:
> 
> (gdb) r
> Starting program: c:/tmp/5/a.exe
> 
> Breakpoint 1, main () at a.c:15
> 15        int written = 0;
> (gdb) s
> 17        written = print("qwertz");
> (gdb)
> print (message=0x1f35 <print+33> "qwertz") at a.c:8
> 8         written = printf("%s\n", message);
> (gdb)
> printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:10
> 10      {
> (gdb)
> printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:14
> 14        va_start(args, fmt);
> (gdb) n
> 15        len = _doprnt(fmt, args, stdout);
> (gdb) bt
> #0  printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:15
> #1  0x00003316 in nofpsig () at npxsetup.c:51
> #2  0x00000006 in ?? ()
> #3  0x00001f2a in print (message=0x1f35 <print+33> "qwertz") at a.c:8
> #4  0x00001f61 in main () at a.c:17
> (gdb)
> 
> The remarkable issue is that although I used the n command to avoid stepping
> into _doprnt() gdb behaves as if the s command had been used.

This backtrace is obviously bogus: the 0x00000006 address cannot be an
address of any function, and nofpsig is not called by 'print'.

Can you try compiling the program with an older compiler, and try
debugging the program compiled by GCC 4.9.2 with a pre-7.7 version of
GDB?  It's important to understand if this is a GCC bug or GDB bug.
0
Eli
5/24/2015 4:10:25 PM
On 05/24/2015 12:24 PM, Eli Zaretskii (eliz@gnu.org) wrote:
>> Date: Sun, 24 May 2015 11:17:27 +0300
>> From: "Andris Pavenis (andris.pavenis@iki.fi)" <djgpp@delorie.com>
>>
>>> So what and how goes wrong in the DJGPP build of GDB?  Can someone
>>> with enough free time step through the go32 initialization, and see
>>> what's wrong there?
>> Perhaps at least some hint could give GDB commit which caused that DJGPP port stopped to work (with
>> symptoms described earlier)
>>
>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=9b409511d07fe375284701af34909fb539029caf
> Thanks!
>
> Actually, it seems bd265cd0bde9e045ab5946532449430b66fe91ad, which is
> a followup to the one you mentioned, is the bad commit.  It seems a
> simple case of misunderstanding the API conventions of our read_child
> and write_child.
>
> Can you try the patch below?  If it fixes the problem, I will push it.
>
> diff --git a/gdb/go32-nat.c b/gdb/go32-nat.c
> index f3966cd..852473b 100644
> --- a/gdb/go32-nat.c
> +++ b/gdb/go32-nat.c
> @@ -587,6 +587,13 @@
>     else
>       res = read_child (memaddr, readbuf, len);
>   
> +  /* read_child and write_child return zero on success, non-zero on
> +     failure; adjust the result value to that.  */
> +  if (res == 0)
> +    res = len;
> +  else
> +    res = -1;
> +
>     if (res <= 0)
>       return TARGET_XFER_E_IO;
>   
>
>
I can confirm that with this patch applied I git current GIT master version of GDB to work for DJGPP:
- same example program cc1.exe from my earlier gcc-4.8.4 build used
- no error messages about accessing process memory
- backtrace somewhat unreliable but mostly works

Some small build problems:
- perhaps it would be best to kill dos_noop() in gdb-ser32.c and add appropriate static functions 
instead (proptype of of one of them has changed in master branch, which caused compile error)
- got also DJGPP related compile error which is potentially related to latest changes, but I did 
not have time to check whether it so

Also: Tried also cc1.exe from my last gcc-5.1.0 build with about the same results as with gcc-4.8.4 
except that backtrace works sligthly worse.

Also: fails to read debug info from cc1.exe from gcc-6.0.0 20150506 snapshot build and complains 
about dwarf error (could not find abbrev number 115 ....)

cc1.exe used from each tests were from stage 3 compile which is built by stage2 compiler of the 
same version.

Andris

0
Andris
5/24/2015 8:36:54 PM
Am 25.05.2015 06:11, schrieb Andris Pavenis (andris.pavenis@iki.fi):
> On 05/25/2015 05:38 AM, Eli Zaretskii (eliz@gnu.org) wrote:
>> - got also DJGPP related compile error which is potentially related to latest changes, but I did
>> not have time to check whether it so
>> Please report the error messages, either here or to the GDB mailing
>> list.
>>
> It is related to gdb/gnulib/import headers instead (included from gdb/djgpp/vsnprintf.c). This file belongs to DJGPP related changes I rebased onto current master branch.
>
> We do not need gdb/djgpp/vsnprintf.c for upcoming DJGPP v2.05, so I simply commented it out for testing.
>
> Andris


That file was required when porting for both djdev204 and djdev203.  With djdev205 I will
no longer support neither djdev204 nor djdev203 and all those files taken from the repositors
will no longer be part of the port.

Regards,
Juan M. Guerrero

0
Juan
5/25/2015 1:01:01 AM
> Date: Sun, 24 May 2015 23:36:54 +0300
> From: "Andris Pavenis (andris.pavenis@iki.fi)" <djgpp@delorie.com>
> 
> I can confirm that with this patch applied I git current GIT master version of GDB to work for DJGPP:
> - same example program cc1.exe from my earlier gcc-4.8.4 build used
> - no error messages about accessing process memory
> - backtrace somewhat unreliable but mostly works

Thanks for testing (and for bisecting the problem in the first place).

> Some small build problems:
> - perhaps it would be best to kill dos_noop() in gdb-ser32.c and add appropriate static functions 
> instead (proptype of of one of them has changed in master branch, which caused compile error)
> - got also DJGPP related compile error which is potentially related to latest changes, but I did 
> not have time to check whether it so

Please report the error messages, either here or to the GDB mailing
list.
0
Eli
5/25/2015 2:38:07 AM
On 05/25/2015 05:38 AM, Eli Zaretskii (eliz@gnu.org) wrote:
> - got also DJGPP related compile error which is potentially related to latest changes, but I did
> not have time to check whether it so
> Please report the error messages, either here or to the GDB mailing
> list.
>
It is related to gdb/gnulib/import headers instead (included from gdb/djgpp/vsnprintf.c). This file 
belongs to DJGPP related changes I rebased onto current master branch.

We do not need gdb/djgpp/vsnprintf.c for upcoming DJGPP v2.05, so I simply commented it out for 
testing.

Andris




0
Andris
5/25/2015 4:11:04 AM
Am 24.05.2015 18:10, schrieb Eli Zaretskii (eliz@gnu.org):
>> Date: Sun, 24 May 2015 17:46:42 +0200
>> From: "Juan Manuel Guerrero (juan.guerrero@gmx.de)"<djgpp@delorie.com>
>>
>> The following test program has been compiled using -O0 -ggdb:
>
> What does -ggdb mean with the DJGPP build of GCC 4.9.2?  It is better
> to use an explicit debug info option (see below).
>
> What does GDB say when you step into 'main' and type
>
>   (gdb) info source
>
> One of the things it should announce is the type of debug info it
> found in the program.
>
> In any case, I suggest to try this experiment with all 3 debug info
> types, COFF, stabs, and DWARF.  To that end, instead of -ggdb, please
> use "-gcoff -g3", "-gstabs -g3", and "-gdwarf-2 -g3", respectively.
> (You could also try -gdwarf-3 and -gdwarf-4, not sure if the DJGPP
> build of GCC supports that.)
>
>> If I step into printf() and I issue the bt command I get the following
>> output:
>>
>> (gdb) r
>> Starting program: c:/tmp/5/a.exe
>>
>> Breakpoint 1, main () at a.c:15
>> 15        int written = 0;
>> (gdb) s
>> 17        written = print("qwertz");
>> (gdb)
>> print (message=0x1f35<print+33>  "qwertz") at a.c:8
>> 8         written = printf("%s\n", message);
>> (gdb)
>> printf (fmt=0x1f10<_crt0_init_mcount+10>  "%s\n") at printf.c:10
>> 10      {
>> (gdb)
>> printf (fmt=0x1f10<_crt0_init_mcount+10>  "%s\n") at printf.c:14
>> 14        va_start(args, fmt);
>> (gdb) n
>> 15        len = _doprnt(fmt, args, stdout);
>> (gdb) bt
>> #0  printf (fmt=0x1f10<_crt0_init_mcount+10>  "%s\n") at printf.c:15
>> #1  0x00003316 in nofpsig () at npxsetup.c:51
>> #2  0x00000006 in ?? ()
>> #3  0x00001f2a in print (message=0x1f35<print+33>  "qwertz") at a.c:8
>> #4  0x00001f61 in main () at a.c:17
>> (gdb)
>>
>> The remarkable issue is that although I used the n command to avoid stepping
>> into _doprnt() gdb behaves as if the s command had been used.
>
> This backtrace is obviously bogus: the 0x00000006 address cannot be an
> address of any function, and nofpsig is not called by 'print'.
>
> Can you try compiling the program with an older compiler, and try
> debugging the program compiled by GCC 4.9.2 with a pre-7.7 version of
> GDB?  It's important to understand if this is a GCC bug or GDB bug.


To make the long story short:  the error was to use the -ggdb flag.  The djgpp
port of gcc seems not to understand this.  The right flag is -gdwarf-2.  It is
also possible to compile with -gdwarf-3 and -gdwarf-4 but later the info source
command always claims that the debug format is DWARF2.  It seems to be of no
benefit to use either the -gdwarf-3 or -gdwarf4 flag.  Compiling with -gstabs
still works but makes no major sense to me because all source files must be
located in the same cwd or the debugger will not find them.  Using -gcoff makes
no sense at all for debugging because it makes gdb crash like this:

C:\tmp\5>gdb a.exe
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i786-pc-msdosdjgpp --target=djgpp".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.exe...rmvfromfree: memory fouled
Exiting due to signal SIGABRT
Raised at eip=003f96da
eax=005440e4 ebx=00000120 ecx=00000011 edx=00000000 esi=00000198 edi=00000198
ebp=000001a8 esp=005440d0 program=C:\DJGPP-2.04\BIN\GDB.EXE
cs: sel=01a7  base=02990000  limit=006affff
ds: sel=01af  base=02990000  limit=006affff
es: sel=01af  base=02990000  limit=006affff
fs: sel=017f  base=00008e80  limit=0000ffff
gs: sel=01bf  base=00000000  limit=0010ffff
ss: sel=01af  base=02990000  limit=006affff
App stack: [00544788..004c478c]  Exceptn stack: [004c46e8..004c27a8]

Call frame traceback EIPs:
   0x003f96da

C:\tmp\5>

I do not think it make sense to investigate this issue any more.


Using -gdwarf-2 makes work gdb again at least for the test cases I have tried.
The bt command works and also the step and next commands work as they should.
I do not understand why -ggdb did not work.  I expected the port of the compiler
to be clever enough to know that -ggdb means -gdwarf-2 for a DJGPP port of gcc.
But it seems to be that I am wrong.

Regards,
Juan M. Guerrero

0
Juan
5/25/2015 12:44:08 PM
> Date: Mon, 25 May 2015 07:11:04 +0300
> From: "Andris Pavenis (andris.pavenis@iki.fi)" <djgpp@delorie.com>
> 
> On 05/25/2015 05:38 AM, Eli Zaretskii (eliz@gnu.org) wrote:
> > - got also DJGPP related compile error which is potentially related to latest changes, but I did
> > not have time to check whether it so
> > Please report the error messages, either here or to the GDB mailing
> > list.
> >
> It is related to gdb/gnulib/import headers instead (included from gdb/djgpp/vsnprintf.c). This file 
> belongs to DJGPP related changes I rebased onto current master branch.
> 
> We do not need gdb/djgpp/vsnprintf.c for upcoming DJGPP v2.05, so I simply commented it out for 
> testing.

If we don't need vsnprintf, then why does the configure script think
we do?
0
Eli
5/25/2015 2:27:33 PM
> Date: Mon, 25 May 2015 14:44:08 +0200
> From: "Juan Manuel Guerrero (juan.guerrero@gmx.de)" <djgpp@delorie.com>
> 
> To make the long story short:  the error was to use the -ggdb flag.  The djgpp
> port of gcc seems not to understand this.

Thanks for looking into this.  This should be reported to the GCC
maintainers (or maybe Andris will be able to fix that regardless).

> The right flag is -gdwarf-2.  It is
> also possible to compile with -gdwarf-3 and -gdwarf-4 but later the info source
> command always claims that the debug format is DWARF2.  It seems to be of no
> benefit to use either the -gdwarf-3 or -gdwarf4 flag.

That's a common misconception: -gdwarf-N actually generates debug info
according to DWARF Standard version N.  GDB says it's all DWARF2 for
historical reasons.

You should be able to see the difference between the various values of
N by running "objdump --dwarf" on the executable and comparing the
output.  (If the output is identical, then there's another bug in the
DJGPP port of GCC; GCC 4.8.1 provided by MinGW does support N=3 and
N=4, and the results are definitely different.)

> Using -gcoff makes no sense at all for debugging because it makes
> gdb crash like this:
> 
> C:\tmp\5>gdb a.exe
> GNU gdb (GDB) 7.9.1
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i786-pc-msdosdjgpp --target=djgpp".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from a.exe...rmvfromfree: memory fouled
> Exiting due to signal SIGABRT
> Raised at eip=003f96da
> eax=005440e4 ebx=00000120 ecx=00000011 edx=00000000 esi=00000198 edi=00000198
> ebp=000001a8 esp=005440d0 program=C:\DJGPP-2.04\BIN\GDB.EXE
> cs: sel=01a7  base=02990000  limit=006affff
> ds: sel=01af  base=02990000  limit=006affff
> es: sel=01af  base=02990000  limit=006affff
> fs: sel=017f  base=00008e80  limit=0000ffff
> gs: sel=01bf  base=00000000  limit=0010ffff
> ss: sel=01af  base=02990000  limit=006affff
> App stack: [00544788..004c478c]  Exceptn stack: [004c46e8..004c27a8]
> 
> Call frame traceback EIPs:
>    0x003f96da
> 
> C:\tmp\5>
> 
> I do not think it make sense to investigate this issue any more.

Too bad: it means the new GCC/GDB are of no use for debugging Emacs.
Sounds like some memory allocation error to me.

> Using -gdwarf-2 makes work gdb again at least for the test cases I have tried.
> The bt command works and also the step and next commands work as they should.
> I do not understand why -ggdb did not work.  I expected the port of the compiler
> to be clever enough to know that -ggdb means -gdwarf-2 for a DJGPP port of gcc.
> But it seems to be that I am wrong.

You are right; it's a bug in GCC.

Thanks.
0
Eli
5/25/2015 2:37:31 PM
> Too bad: it means the new GCC/GDB are of no use for debugging Emacs.

Why can't emacs use dwarf, like other platforms?
0
DJ
5/25/2015 6:25:25 PM
> Date: Mon, 25 May 2015 14:25:25 -0400
> From: DJ Delorie <dj@delorie.com>
> 
> 
> > Too bad: it means the new GCC/GDB are of no use for debugging Emacs.
> 
> Why can't emacs use dwarf, like other platforms?

Because last time I tried, the dumped Emacs segfaulted when temacs was
built with DWARF debug info, and no one cared enough, or had enough
resources, to fix that.  (Most probably, we need to fix up something
in the debug info when we copy it from temacs to emacs.)
0
Eli
5/25/2015 7:05:20 PM
On 5/4/15, Andris Pavenis (andris.pavenis@iki.fi)
<djgpp-announce@delorie.com> wrote:
> This is announcement of DJGPP 2.05 beta 1
>
> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
> Unfortunately DJGPP v2.04 was never released and old beta version slowly
> became almost unusable together with other newer DJGPP packages.
>
> More information about changes in DJGPP 2.05 beta 1 is available at
>
>      http://www.delorie.com/djgpp/doc/kb/
>
> both in sections about changes in 2.04 and 2.05. The same information is
> also
> available in file info/kb.inf in djdev205.zip
>
> It needs a lot of testing. Please test it if you have time and/or are
> interested in any of the above features. Any level of testing would be
> appreciated.

Some dxe3gen and dxe3res issues: They are not flexible with relation to
development environment:

1. As it seems, they were designed to be run under dos-djgpp not with a
 cross-toolchain, i.e. dxe3gen expects 'gcc', 'as', 'ar' and 'ld' to be
 djgpp-targeting tools. Well, ld _can_ be changed to be a cross-ld, but
 only at compile time. User must have the ability to specify his choice
 of tools.
- We may make dxe3gen to check environment variables such as DXE_CC,
 DXE_AS, DXE_AR and DXE_LD whose values will be the names of the tools
 of choice. (Maybe even a common DXE_CROSS_PREFIX to cover all those
 at once??)
- Command line switches instead? (Environment vars seem better to me.)

2. Strict requirement for DXE_LD_LIBRARY_PATH environment is rude for
 cross-compilers. It should be optional ifndef DJGPP

3. dxe3gen sends -T dxe.ld to ld, but the user can't specify a choice
 of linker script. (One consequence is when compiling djgpp itself with
 old toolchains, the toolchain-provided dxe.ld is used instead of the
 one in the source tree.)  Maybe add a '-T' switch to dxe3gen itself??

3. Both dxe3gen and dxe3res expect little endian host.  On the other
 hand, their father tool dxegen swaps bytes as required. Needs fixing.

Thoughts?

--
O.S.
0
Ozkan
5/28/2015 2:25:22 PM
On 5/28/15, Ozkan Sezer <sezeroz@gmail.com> wrote:
> On 5/4/15, Andris Pavenis (andris.pavenis@iki.fi)
> <djgpp-announce@delorie.com> wrote:
>> This is announcement of DJGPP 2.05 beta 1
>>
>> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
>> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
>> Unfortunately DJGPP v2.04 was never released and old beta version slowly
>> became almost unusable together with other newer DJGPP packages.
>>
>> More information about changes in DJGPP 2.05 beta 1 is available at
>>
>>      http://www.delorie.com/djgpp/doc/kb/
>>
>> both in sections about changes in 2.04 and 2.05. The same information is
>> also
>> available in file info/kb.inf in djdev205.zip
>>
>> It needs a lot of testing. Please test it if you have time and/or are
>> interested in any of the above features. Any level of testing would be
>> appreciated.
>
> Some dxe3gen and dxe3res issues: They are not flexible with relation to
> development environment:
>
> 1. As it seems, they were designed to be run under dos-djgpp not with a
>  cross-toolchain, i.e. dxe3gen expects 'gcc', 'as', 'ar' and 'ld' to be
>  djgpp-targeting tools. Well, ld _can_ be changed to be a cross-ld, but
>  only at compile time. User must have the ability to specify his choice
>  of tools.
> - We may make dxe3gen to check environment variables such as DXE_CC,
>  DXE_AS, DXE_AR and DXE_LD whose values will be the names of the tools
>  of choice. (Maybe even a common DXE_CROSS_PREFIX to cover all those
>  at once??)
> - Command line switches instead? (Environment vars seem better to me.)
>
> 2. Strict requirement for DXE_LD_LIBRARY_PATH environment is rude for
>  cross-compilers. It should be optional ifndef DJGPP

I was miserably wrong about the DXE_LD_LIBRARY_PATH. Noticed that I
was testing with some stale environment vars set

>
> 3. dxe3gen sends -T dxe.ld to ld, but the user can't specify a choice
>  of linker script. (One consequence is when compiling djgpp itself with
>  old toolchains, the toolchain-provided dxe.ld is used instead of the
>  one in the source tree.)  Maybe add a '-T' switch to dxe3gen itself??

.. was wrong about the wrong script part too like above.  (Sorry.)


>
> 3. Both dxe3gen and dxe3res expect little endian host.  On the other
>  hand, their father tool dxegen swaps bytes as required. Needs fixing.
>
> Thoughts?
>
0
Ozkan
5/28/2015 7:11:37 PM
I have a minor 2.04 libc header bug that probably also exists 2.05.  I
just recently ported lz4 [0] to djgpp via Andrew Wu's build-djgpp 2.04
cross compilers [1].  It's currently on the dev branch of lz4 and due
to be included on the next release of master.

In porting, I noticed that using `cc -std=c99` confuses the djgpp
headers such that the main bodies of the headers get nullified for
io.h, fcntl.h, and unistd.h.  This is because `-std=c99` implies
`__STRICT_ANSI__` which is guarded against in those headers and
probably others.  The simple work around is to instead use
`-std=gnu99` which does not imply `__STRICT_ANSI__`  and brings in the
needed function prototypes (isatty(), setmode(), a couple others).


[0] https://github.com/lpsantil/lz4
[1] https://github.com/andrewwutw/build-djgpp/releases

On Thu, May 28, 2015 at 12:11 PM, Ozkan Sezer (sezeroz@gmail.com)
<djgpp@delorie.com> wrote:
> On 5/28/15, Ozkan Sezer <sezeroz@gmail.com> wrote:
>> On 5/4/15, Andris Pavenis (andris.pavenis@iki.fi)
>> <djgpp-announce@delorie.com> wrote:
>>> This is announcement of DJGPP 2.05 beta 1
>>>
>>> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
>>> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
>>> Unfortunately DJGPP v2.04 was never released and old beta version slowly
>>> became almost unusable together with other newer DJGPP packages.
>>>
>>> More information about changes in DJGPP 2.05 beta 1 is available at
>>>
>>>      http://www.delorie.com/djgpp/doc/kb/
>>>
>>> both in sections about changes in 2.04 and 2.05. The same information is
>>> also
>>> available in file info/kb.inf in djdev205.zip
>>>
>>> It needs a lot of testing. Please test it if you have time and/or are
>>> interested in any of the above features. Any level of testing would be
>>> appreciated.
>>
>> Some dxe3gen and dxe3res issues: They are not flexible with relation to
>> development environment:
>>
>> 1. As it seems, they were designed to be run under dos-djgpp not with a
>>  cross-toolchain, i.e. dxe3gen expects 'gcc', 'as', 'ar' and 'ld' to be
>>  djgpp-targeting tools. Well, ld _can_ be changed to be a cross-ld, but
>>  only at compile time. User must have the ability to specify his choice
>>  of tools.
>> - We may make dxe3gen to check environment variables such as DXE_CC,
>>  DXE_AS, DXE_AR and DXE_LD whose values will be the names of the tools
>>  of choice. (Maybe even a common DXE_CROSS_PREFIX to cover all those
>>  at once??)
>> - Command line switches instead? (Environment vars seem better to me.)
>>
>> 2. Strict requirement for DXE_LD_LIBRARY_PATH environment is rude for
>>  cross-compilers. It should be optional ifndef DJGPP
>
> I was miserably wrong about the DXE_LD_LIBRARY_PATH. Noticed that I
> was testing with some stale environment vars set
>
>>
>> 3. dxe3gen sends -T dxe.ld to ld, but the user can't specify a choice
>>  of linker script. (One consequence is when compiling djgpp itself with
>>  old toolchains, the toolchain-provided dxe.ld is used instead of the
>>  one in the source tree.)  Maybe add a '-T' switch to dxe3gen itself??
>
> .. was wrong about the wrong script part too like above.  (Sorry.)
>
>
>>
>> 3. Both dxe3gen and dxe3res expect little endian host.  On the other
>>  hand, their father tool dxegen swaps bytes as required. Needs fixing.
>>
>> Thoughts?
>>
0
Louis
5/28/2015 10:00:35 PM
We used the ISO standards as references when writing those headers.
If a function isn't in the ISO standard, it isn't declared when you
require a strict ISO/ANSI implementation.  If the application expects
a non-ISO function in a header, and uses --std=c99, the application is
wrong.

Now, if the newer standards (c99/c11 vs c89) require more functions to
be declared in system headers, we should revisit that and protect
those functions accordingly.
0
DJ
5/28/2015 10:05:38 PM
> Date: Thu, 28 May 2015 15:00:35 -0700
> From: "Louis Santillan (lpsantil@gmail.com)" <djgpp@delorie.com>
> 
> In porting, I noticed that using `cc -std=c99` confuses the djgpp
> headers such that the main bodies of the headers get nullified for
> io.h, fcntl.h, and unistd.h.  This is because `-std=c99` implies
> `__STRICT_ANSI__` which is guarded against in those headers and
> probably others.  The simple work around is to instead use
> `-std=gnu99` which does not imply `__STRICT_ANSI__`  and brings in the
> needed function prototypes (isatty(), setmode(), a couple others).

Don't use -std=c99, unless you are building a program that doesn't use
any features not in the ANSI C99 standard.

I think you want -std=gnu99 instead.  That option doesn't disable
non-ANSI features, but does assume C99 features supported.
0
Eli
5/29/2015 5:58:02 AM
> Date: Sun, 24 May 2015 18:21:47 +0300
> From: "Eli Zaretskii (eliz@gnu.org)" <djgpp@delorie.com>
> 
> > Date: Sun, 24 May 2015 17:01:57 +0200
> > From: "Juan Manuel Guerrero (juan.guerrero@gmx.de)" <djgpp@delorie.com>
> > 
> > If you known that the issues are not related to each other then there is no reason to withhold the patch.
> > Please go ahead and commit the patch.
> 
> Thanks, I've posted the patch for review to the GDB mailing list, and
> will commit in a few days, barring any objections.

Committed.
0
Eli
5/30/2015 10:10:37 AM
Reply: