From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gareth Hughes To: Alan Cox , Mark Kettenis , drepper@redhat.com Cc: adam@yggdrasil.com, linux-kernel@vger.rutgers.edu, bug-glibc@gnu.org, gdb@sourceware.cygnus.com Subject: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1 Date: Sun, 11 Jun 2000 01:03:00 -0000 Message-id: <394428DD.A2EFC21B@precisioninsight.com> References: X-SW-Source: 2000-06/msg00077.html Content-type: multipart/mixed; boundary="----------=_1583534240-23286-3" This is a multi-part message in MIME format... ------------=_1583534240-23286-3 Content-length: 1590 Here's a copy of my latest work, this time kernel and glibc headers only. I'm still working on updating GDB, as incorporating Mark's suggestions leads to some problems with the stock 5.0 code (mainly in the interpretation of the FPU tag word). What are we doing now? We use FXSAVE/FXRSTOR only to save and restore the FPU context as before. Nice and fast. As always, the FPU state is only saved when the FPU is used and restored with an #NM exception. We (correctly) convert the FXSR-format data into the expanded signal context, and include the original FXSR-format data like before. This includes doing a full conversion between tag word formats. We (correctly) convert the FXSR-format data on the PTRACE_[GET|SET]FPREGS requests. We just use the 512-byte FXSR data on PTRACE_[GET|SET]XFPREGS requests. This requires updates to GDB, which I'm working on now. Nothing major, the code is the same as in the kernel. The tag word conversion originally seen in 2.4.0-test1 was almost correct, but this code does a more thorough job - important for GDB 5.0 correctness. As always, please let me know if you have any grievances. Doing the conversion turned out to be a lot less ugly than I had imagined, and as we only need to do it for signals, ptracing and dumping core, it doesn't affect things too greatly. I will add in the core dumping support when the work in this patch gets applied (in whatever form). The signal handler test from my previous email will still work, and I encourage you to verify this. -- Gareth patch-2.4.0test1-ac12-gth2.gz patch-glibc-2.1.3-gth2.gz ------------=_1583534240-23286-3 Content-Type: application/x-gzip; charset=binary; name="patch-2.4.0test1-ac12-gth2.gz" Content-Disposition: inline; filename="patch-2.4.0test1-ac12-gth2.gz" Content-Transfer-Encoding: base64 Content-Length: 5539 H4sICCYkRDkAA3BhdGNoLTIuNC4wdGVzdDEtYWMxMi1ndGgyAM0ba3PaSPIz /IreuqocGOTwNobEl9wGe30bJynjzeYu56JkMRhVQOIk4ccm/u/X3TOjtwB7 k6tzlS0Y9fT09Lt7xlN7NgNjDYbhCWvt+faNwM+OuDVm9kLAwnbWd89Nz5o/ t9v93vMvwnPE4vnKcy3h+/uWBNi/DuYbgMqGYWzFVBqvHfgH/jab0OwOuv1B twOtRqNRrtVqOy2TwNAcdHqDTl9iePUKjG6jW28dQo2e3Sa8elWG53tlgD3A jS7AdiCYCzj+8Bv4gbe2grUnYOZ6YILl4sfpernaJ/DnZeMv9syZihmcnb7D L/jJdgR9qZh1uKqWKpWKWYUXULmqVuFvQF8G/AWBhTO1Z2VcLWCMk9lqDRW5 IKyCiSeufaSIHnVFB6x94U1wwwcTOYAEr9bVMnwtQ4nwzFY35sKeDvGrmhGY /hcFDHuB/wVeAorWE04wLBvlGpJP1P/8/t3x6cnkU783Of40Pi/XSmvHt68d MQV/7no01R3mjM48d0njtLaNH/SeSooQXA3XNI6Q7ulkaQZzosyeQUW9rzLl iHZh/nFPDKggeBUpK5WWYmmt7hFwXYdnjCSYe8Kc7tP29+emN60TGMgf4rhv /yHcWaWAVVUGJ/gkHIMQOg1XxfWhgC+IAQkyjpbmtW3h5vSLydnrk9OfiRO7 0A0HKFdFxcJ1rmnFGs0NXMRZSTO5+ozX9IOJvzIt8blxyQsR7/PBc1fdz8xH ha7YiKExBBtVtI+PWq0OSETtJXTrwAvgxz5JCSforQWufFeHbrSPJBW8o1Lp ARkpFr7I8K2xK6sITIl4i3hZalr9cGH86wm0XCdmFA/E5iKVj+zwzvdYF9O2 mDVFBtXWxaZY+6rMIVy1tospkviLbaaWtplajs18D4bG9iNFyBzLMLL2EJl6 ruskZBt85355+rRQE3iowFsijYLZGGgUzNPjTB6C9qDdHbTbUZhp9+vNBtTw 0eMYQwEDdIwYHb+dvD8+Ho8uoFLBL0arutcxkjJRmofRAr5DpDFCUQVz2wfP XQeE4pbkdi0ClNCt603BRcm4MxajCqfCx0/2DQrmmgw8MK0v+6AQCYL3cTZi nLu3MDM96Tjo1ZXpCzCnU5S+j/NQ/lOtIRfj8T4As6nZPkAG1Zrtdr3dYkZp hcMHahwbLpRruHCA3sN2FkQ22Zhv3gjpBEjhilwD7F2tZ6z4qPoFXh/26Is0 38KYSEZouat7aSaBK1fVy6IpEoUCPTCtB4ywSsuq3TQ5QJI7lKgmE0am8YST 6ltdXRYrCzg01IY00TyWeYLlkOVaPkc028hdbODuoxhH6iGXlrvNZ+AurEtj YhZ+L+ahzi6RbV/Ma6Vs9/5E2j0HbeTkf9bIzDrwt5U9VZ9I39XHqRmYKjvL iwHW3F6gNyUb6DTb9WYHap12t95nG0gy8+z1xS+T0dlvb19fnL5/RzkTsQGu XDeYWKv1hFZiB88RAziv0maP8kupWuXGxTizV6VZGCmYjoL86vEZ1q45llGc Y5UqxbbMRFeLUzAjzDgeg6UxDN0kKXzKsWzBEzMS/CliZzatzAr1AYh4mRTH iPDdWVDJw0sv6lKBOo06VjSdbu8H6k9kb4U6k1AtrQ+P052dtIc4nvVlxapc U9i3qcRjhZSgYRc5dRsU7Dq9br3TlcFOpskqcyUvFCbIV4jhS5SGWRROP1yc v/55NDkZXXw6/nA+OhkP4CvGdTjBeRRYeXUQdwFixHAri1j0qvuUfRS7aNaH n0yL4v3E/VL5ODo/Pf7n5Pfz04tRPVZkxDV+xzxSlw9yZ8bo9L0UX7g72l5y 46ycPylGhokwaEy43bG9XC8oWJgOiOUquKedyj2S6YiAMuOJdTutMJY6NO4a 7YOZ0hz93k+8x5/U+yD+foY/1YjeJ/rURzAuFvSSzIs81QYNGac1ZPxDNOR8 9PrN/0ZBMurwkuP3Y7wTJN2TSgl3qINi2rlRJBBSLYvQp9U5xEpzsbnO0TCb 6hwN8+Q6pwBBqzvodKI6p9nv1ZsHmMHj86AhnZqF/Kb83XKn4nP/knL44Z+q YjbU7ZzcptogaLnSJ6N9kjTTbRJ8r4r11IuYG9JdLarNc5slSnHJMCqIEJ6h l2hX4aeX8hlp9beXUGnCixdgxxwIzXhJhMDREbSUEcdKH53Ex7L3vCR6h/xd 22E6zw4z94gJnLcK5+bzwWWsdYFT7rAS1W3AaJQH013AoiQd0aocPdMASyfl +JXIN44sZlK6vUSoPjcumeGhW5YT/OIJzdwJoRiS+pKLoRXDEEMxs1eIggDa l7FRd5VHCSPqRIg47JAKNHtxlJZPk1OwcQDXVWt2E2v6arR3Kdkoe4ppOVbh mWJXsiuomorPUErGEWqSHi7sFdJfmpQwhozko5ahkjrrjBJ7XO5xE5CFGESN pi3VLG0oW0uyjheWYJk2HHquhTC9RC9a0ZMNMwXtXW43cDqbTXw1YdVYdbVL urulut6ZNiVZ9iHSiGIuYishWSstKu038OZxlf1GJj+Z8pyin5tMW3SsQL24 2dfp1FvU7Ts8qDcbuuHHSdd6BSbIUIpWYC6FOjyC3YMau2XyUbr1FKdmUzMr 48F9Cm/vfnv7dphx+0HKdbJrhtBL5kwwr7ODKoCGvi0ZGXTI58x08vrNm/MK xgOHIj+nDHvVZ5VZNfJLUIOKU0VGSu+4SyjWkbipIzBvOccFxmiQOmXrg5iS f2sH1pwmGUfibuU66B40Ok6y5f4GMoVEPuAKraGsTFbCslHSqhSJZbF6JnFF zeScmhYhDtoz2zKdKQe2Z1FPIfO+ueV9a8v79qXeiia9OSTK/yU8NyQ7rHLj cK1h3g4fMhtFIZvrRRDbZJYGllGfg19ykQYv8pHPQr4LNTySwCDnt4eylhxx /Sjnh6UopWwEhklbpYX6Z6tCIJG1pUPWtqxNF4t5biTuzXaw6+0ZW27CdleU samMKmP/URr2LWXUKqUqmOEXzGhdqmwr4clUg0yCtAkkzKz0aCc2isnRN6jk rktZF8pMJVMyP4omuq4e7cVH/UzWmujKc+J6kHPYWZi8ctaVyaLUie3OydiT si5NeTbnCtydMq4wOOZFw6gpmZ9uwaPyrU03EGg14Xlh1a3q6+y556NPbFim +XlFQpaGEiZRge5gMlmtA8Xb/BP22zDBIm6sfamCmdnJlrWewq3oqj7sxVl5 pOTIOSej23T4u1N3Pr2yzNCgVHSzgDarz63z2KKvfeQZ14bLHaXcc4dUCp3b ZMrZU3X33UNi98UHFZHcNh1EJKAa8WsKkRli8rlTq8h2rMV6Kp6b/tLgRo06 onW9/XmskbMJLNYw2gSW0zPq5/WMdsbRG7QPBpgYh22jVr/J5+P0PJRdI/Kn pdALtluXHOH7e80eXN0HwuebBMLEzOz4g0G+E1OXVl+9o4xaYrhbLndA8ens bAOOlTmd2s715y4V0oamjBRdpnnU0r81PQFK+20HES/RXboOY3lAizeDwLOv 1oGYTDBaYULDQaOCsYmvq0QNsKTulEqNuytxZc6EZUYZcxaGwmqyPo40msjT XverPHk44GP2zkGPThqj+wj5yo21CXWIUTu/RykyLMS2e7eOHWASy2OTq9L2 5CpD6Z9ou5U2tN2416BFGz+uQG9YhxtzUYWpC1/h34Vet6AzRlOHNO0Bbufk OCoNWaB2qDuL8j9s44PEHweALDFBHjFGATHp0jFFTG3jtIz0c/cA6jIZHWWk tJUU+YnuU17k2ew7FcxGx6lgShdrAW+EBXAITXSZ6PHww+HhwVavqRHEXWZr gIViuxu5zE5PHh7qM14lsujEh457IPbTbGegTkYX8lgoBtXJw5WB6kbOKHMK GUK1slDjHKgey1P6nsnk19H5u9HbySQig49hlu5UVPgGFLrPj2fo+ca/Ytko h7Awny1MevcNa4F2bPzOoitTT1MI1F/LdQL0AZuVIg63STHicE8OqYVIGoNu e9CKxdRmk2yc/6oG1AdMtO31Ek5PT4FspQ7j8Qj89WqFFkoQpROMYsEcfllf zzECvrjmr6/oqh8RZLnLozqcmfdyEZxQNhDtRXhBmlwaHadF9/18rKuQ2XNz SpdJrz33lp6mhajcKYEHc1GubUGC0/0tKGh72WNMvphj01Wzq3s+7xwH6HWW GMthfHr2BkY0w8cw7XMbjojA1WwfHBe9nLVeIsPkNTdnij4qXHe1sP25vDpn yoPUpUuwqpnHPcAGcR//SvNM1+gLQfBYyIanYanQMJlReUUVXTpmUJGHfu9c XK8XpsebxVzf9lyHUMq0JblaybodpgdLfs4YN/GY+kO6f1frNOrNXg79JZKP O5tlMdALXyxit85l96FEpW+f06cUGTKPKhsPifYhB43wZeYFp9Ay+ZJtBQwd XowhrD+us7iXvdUsc+8Ud430mR/zKj3KzMoMMrcyo+6KzjmzG7VXzLD0sOUz u9LDIYPzXvAMVgKOeDkakOoJlaKSsCeT4PhEUniE5SuZWe0pLdGHellJo20L 70ZMicRkFyOUdbrZVNKH6fQ2QQXl3iyzNCkaAabxjACf8gg5RU0qRS/WMSOj DEoLKFmnT6VcQyzx32Hu+zsJcKchHoBV3s8SotSWdk4uilRQVgoDaKAGH49f fxzVZXMSWYNfZPkwjGX0kf9Hap8W1yiebo5oEmJTLJMQT45iOdOxJjwcYA0Y XZnu8E0CenR/dARz0Q7MqwVfIRq9PTbIx2P9RiMkKc1xurGO7h59vtqRL6MK xRKEY1ysFHW4xZiw9gMZ/jzXXXKxSdDaT1GaGwtVGOJuxWJBTwpohAoFGQU1 vYgCl3qzDxw4ZUdhZovFFCzcwhUnTRSvGM9UYBWzlBUMZtFIvpwd/mvTLS5K exPTOnIA582xig0XpMv6Eg+C+HoBHEWlC9DFYlkkPNT4QMZZx3WMDyigGoTl v490/s40hXubuYuFe0uRGJl7Q2J1nQGYPPsPOnyI78mmiIvMpgteYZBnA2Fc aa7UValgQjGmKFyEaBRLOR354Lk39lRo1QqFd/Lm79Ddb+h0dk8ns+oGsGwp MENMK8DdMbJbO5hLXqPKGor3s4VrEgSsXG5vRg4cmXWcfEmukTEp3subV9EN er0XhTr8z4u1ucDdO47wpFyvXEkI4wqzGnrDwp5lV82seGObjJx0UxYqjEzv H2k/RSHhhoUHdMZVB2tuOtdkKW6ob/Foxf9zcKWxzBaoU9HGqGH8Vz+yEHG3 4vfhqal25tEdznTelLnd+VW3dSzZjFTZUPSZzzf5fwO7lMN1dZGcakm1GmE/ qVHYkuo3Yt2kRKIXo/guj+T4/xN9jcc7mWYo4jN5St5ouKHeId8s7x2o/0L5 /22yJSJ1jgjzInZKB7IhO83yHx6zn++V/wu48DvuSTsAAA== ------------=_1583534240-23286-3 Content-Type: application/x-gzip; charset=binary; name="patch-glibc-2.1.3-gth2.gz" Content-Disposition: inline; filename="patch-glibc-2.1.3-gth2.gz" Content-Transfer-Encoding: base64 Content-Length: 1973 H4sICOYjRDkAA3BhdGNoLWdsaWJjLTIuMS4zLWd0aDIAxVdrb9s2FP1s/4oL 9EO3yA89HDextyFd4qQZWiyLUqxDUBiKRMlEJFIjKdtBsf++S0qyZVsZ1hTD AiQOX4fnPnjudUTjGPoF9PuChIWQdEkgSelD2HcHzsAbyicZkVwOC0bXerAc ppQV6yH1TsZ6PCxCzhRZq8GieW6QqMXXnO32+/2X3tv5nURwSR7A9cC2J7Y3 8WxwbdvuWpb1LaQ6fsHgF/x1HHDGE3c8sZ0S+OwM+ifHvTFY+NcZwdlZF/6a duEVYRGNu9C1hkddCwBuCFO0yOD6+houP/m3PfD9Gcgiz7lQXatzFQiiFvCu SBZEwg+JGZ4tA8NpEPLspx58CJ4qcwzk3YLA5c1HkCpQBKJABfivKEJVCAKL QOJvBIpDIvhKfwYhwvBIb1YLYiDQOiSqvbbBEeTPggqcenjS28BXggQZZQn4 1x8uYKZPSMqZHNQk8DYqgXGIeFhkaCceRiwWBSLa3JunVC4QEHcGygBnXO8d wNEQ7YHhEVyQmDKqNDao4JEwiAXPzN5HIhhJYUGCiAg5AH2oMhbmOq7zOBck 6cIXE5FTt3cClmPbPdcxIQEokHTCNLMFOhwoU2h8zhlSmJYh61p7gGuNaH3R Zrac1hM0piHaeT/6PH1m1/aO9vU8iCL07b2nEZCFtcdinWUtLFKO4TDwKdFO LAmY4/teMUHVfsHz6ONbkhRpIEy8CVtSwZkGMP5suyBcTdsX5HMLKkimJgiO 7fbeYBRcr+eM96Ow2a7TlsfxM2B6VZLUrB6GG+ZS3Z+g6f1Whmh5IZ9z/D+v ZkFCw2mngx6z1zH+wI/4MLauM4+Ns/SpzN7St/pZtzm2NXLzeC3FHHfejz9P O3unS3x8KniI67f4HEq2DqWYtq8JIolYksgst6R2RaF04Q4DvdjOoCU3QX+a KLSyqBP8GM2s3pn2lb8RKhSIiMhQ0AdSX06l2rzy6JvLEnrhRSXJnHtBOTLn OncFMRUDTsFxJ643GR2Dc3p68sJSVILulaHR5NjbliF8Z1iGmq8NfcshK8KF jgQHimJ7wdlrBQiHI4i5gIA9oShjsDjqrECxDRgk0QNGMiVSGpQnXsAjwxqy WqB06xEWJxR7PGXU2xS5/6LA3Qi+pBGpQQxfXQ2uLn6G44ENN3e3b89n86NP lze3syvflC4ilTQb0WQiglAhSwO2omphTmtyfdyRoTFxygO9A3Ju5HT7cDH7 LncX9YswSCj5gMmKZQ09hLlOmcGt9aGCrmYLWQQp6gljRPTQ21hXeUnEYG3q pF4xBTY+vPXgxiUNDDgjK8gVWlmC1fYj92sGhJqIhiigPQgxrgn6HdNAVW1D U6VWNE3xhgolTkmotoahBD++llV7gG0F1jSzXpfuShR0jpa6LOfllC47CGi0 IFxFZVnwTJqOvB42aWWamvWY82ljILcDqeYyRxPh3rUPqqS5dL17a2vJNvcf Tsv2adU+HfPcTJckaXMQysZA22I1bakHW702wx2J3jPWcz9vp1FiW+crdYUd eW26pumXl0qpFqAyy75CR5uH/rWINg91LgWFX9EO3cy/mYzcieN9vYLuIDbl 843+euCOtvJ5eqp7RvzrnJi8fBXpdpSgyMwvZndvz9/VclOOtKNN1T/HLwl4 FTEvWCqe1/0tw+YavkOVK0TZyX4PyCYM0rSsbNi0VIj+H/752/fvscdwRzq0 LdO9JqGd1d3hphm5Igrwqo2c9Es5MTKDurypsjpNTK8fQC641peyr9edvS7/ urFXtQLjTs4MbBaEWDVIVaS3nK9md7UaI+3jXtdq+LGxeLB9Q9z/f4j7O8TH O7z9A97bmUZPc0OE1v6aDui0048zLlhovtXgnbez3z7O/DtND78XAI9NqmAV ROHu/g2I2sIHgw8AAA== ------------=_1583534240-23286-3-- >From cgf@cygnus.com Sun Jun 11 09:43:00 2000 From: Chris Faylor To: gdb@sourceware.cygnus.com Subject: gdbarch.c problem building for cygwin Date: Sun, 11 Jun 2000 09:43:00 -0000 Message-id: <20000611124302.A2804@cygnus.com> X-SW-Source: 2000-06/msg00078.html Content-length: 1353 i686-pc-cygwin-gcc -c -g -O2 -I. -I/cygnus/src/sourceware/gdb -I/cygnus/src/sourceware/gdb/config -DHAVE_CONFIG_H -I/cygnus/src/sourceware/gdb/../include/opcode -I/cygnus/src/sourceware/gdb/../readline/.. -I../bfd -I/cygnus/src/sourceware/gdb/../bfd -I/cygnus/src/sourceware/gdb/../include -I../intl -I/cygnus/src/sourceware/gdb/../intl -DGDBTK -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized /cygnus/src/sourceware/gdb/gdbarch.c /cygnus/src/sourceware/gdb/gdbarch.c:926: macro `STRINGX' used with too many (4) args Here is the offending line: #ifdef FIX_CALL_DUMMY fprintf_unfiltered (file, "gdbarch_dump: %s # %s\n", "FIX_CALL_DUMMY(dummy, pc, fun, nargs, args, type, gcc_p)", XSTRING (FIX_CALL_DUMMY (dummy, pc, fun, nargs, args, type, gcc_p))); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ #endif FIX_CALL_DUMMY expands to a { .. } block on i386 so this doesn't work too well. Changing the line to this: XSTRING ((FIX_CALL_DUMMY (dummy, pc, fun, nargs, args, type, gcc_p)))); ^ ^ "fixes" the problem but I fear that we would just be using a gcc specific extension by doing this. cgf >From kettenis@wins.uva.nl Sun Jun 11 16:22:00 2000 From: Mark Kettenis To: gdb@sourceware.cygnus.com Cc: nsd@cygnus.com, Peter.Schauer@regent.e-technik.tu-muenchen.de, rjl@sco.com, eliz@gnu.org, cfg@cygnus.com, jtc@redback.com, jimb@cygnus.com Subject: i386 debugging registers Date: Sun, 11 Jun 2000 16:22:00 -0000 Message-id: <200006112322.e5BNM6513971@delius.kettenis.local> X-SW-Source: 2000-06/msg00079.html Content-length: 1306 Hi, While trying to build a generic layer for implementing hardware watchpoint for the various i386 native ports, I found myself starting to implement some sort of register cache for the debugging registers. Instead actually doing so, I wondered whether it would be a good idea to add the debug registers to the standard register cache. Pros: * It makes my life easier :-) * They are, you know, erh... registers. * Some people might actually want to fiddle with them, especially with the control register which has some bits that control the instruction pipeline. Cons: * It might confuse our users. Fiddling with the debug registers might interfere with the hardware watchpoint support. For example, Assigning to one of the address registers will probably make GDB forget about some hardware watchpoints and produce some weird warnings. It will also likely cause some spurious SIGTRAPS. * The exact effect of modifying the debugging registers is somewhat dependent on the underlying OS. To make sure GDB's hardware watchpoints work as expected, some additional frobbing of the debugging might be necessary in the code that actually fetches and/or stores the registers. The user will see those frobbed registers instead of the real ones. Comments? Mark >From fnasser@cygnus.com Sun Jun 11 16:34:00 2000 From: Fernando Nasser To: Mark Kettenis Cc: gdb@sourceware.cygnus.com, nsd@cygnus.com, Peter.Schauer@regent.e-technik.tu-muenchen.de, rjl@sco.com, eliz@gnu.org, cgf@cygnus.com, jtc@redback.com, jimb@cygnus.com Subject: Re: i386 debugging registers Date: Sun, 11 Jun 2000 16:34:00 -0000 Message-id: <3944218C.6FAAA98A@cygnus.com> References: <200006112322.e5BNM6513971@delius.kettenis.local> X-SW-Source: 2000-06/msg00080.html Content-length: 2209 Mark, I can see one situation where one may want to look at or set debugger registers: when debugging a debugger's hardware breakpoint support. So, I believe we should leave these registers out of the users sight. As a compromise, I suggest that we add (I will do the same on my targets around here) a pair of "qQ" packets to read/write those registers. What I mean is: qDEBUGREG...tbd... QDEBUGREG...tbd..= We can add a maintenance command to access that. That is what maintenance commands are for. What do you think? Would that solve your problem? Regards, Fernando Mark Kettenis wrote: > > Hi, > > While trying to build a generic layer for implementing hardware > watchpoint for the various i386 native ports, I found myself starting > to implement some sort of register cache for the debugging registers. > Instead actually doing so, I wondered whether it would be a good idea > to add the debug registers to the standard register cache. > > Pros: > > * It makes my life easier :-) > > * They are, you know, erh... registers. > > * Some people might actually want to fiddle with them, especially > with the control register which has some bits that control the > instruction pipeline. > > Cons: > > * It might confuse our users. Fiddling with the debug registers > might interfere with the hardware watchpoint support. For example, > Assigning to one of the address registers will probably make GDB > forget about some hardware watchpoints and produce some weird > warnings. It will also likely cause some spurious SIGTRAPS. > > * The exact effect of modifying the debugging registers is somewhat > dependent on the underlying OS. To make sure GDB's hardware > watchpoints work as expected, some additional frobbing of the > debugging might be necessary in the code that actually fetches > and/or stores the registers. The user will see those frobbed > registers instead of the real ones. > > Comments? > > Mark -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From ac131313@cygnus.com Sun Jun 11 16:50:00 2000 From: Andrew Cagney To: Chris Faylor Cc: gdb@sourceware.cygnus.com Subject: Re: gdbarch.c problem building for cygwin Date: Sun, 11 Jun 2000 16:50:00 -0000 Message-id: <394425AE.E1228A9E@cygnus.com> References: <20000611124302.A2804@cygnus.com> X-SW-Source: 2000-06/msg00081.html Content-length: 1533 Chris Faylor wrote: > > i686-pc-cygwin-gcc -c -g -O2 -I. -I/cygnus/src/sourceware/gdb -I/cygnus/src/sourceware/gdb/config -DHAVE_CONFIG_H -I/cygnus/src/sourceware/gdb/../include/opcode -I/cygnus/src/sourceware/gdb/../readline/.. -I../bfd -I/cygnus/src/sourceware/gdb/../bfd -I/cygnus/src/sourceware/gdb/../include -I../intl -I/cygnus/src/sourceware/gdb/../intl -DGDBTK -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized /cygnus/src/sourceware/gdb/gdbarch.c > /cygnus/src/sourceware/gdb/gdbarch.c:926: macro `STRINGX' used with too many (4) args > > Here is the offending line: > > #ifdef FIX_CALL_DUMMY > fprintf_unfiltered (file, > "gdbarch_dump: %s # %s\n", > "FIX_CALL_DUMMY(dummy, pc, fun, nargs, args, type, gcc_p)", > XSTRING (FIX_CALL_DUMMY (dummy, pc, fun, nargs, args, type, gcc_p))); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > #endif > > FIX_CALL_DUMMY expands to a { .. } block on i386 so this doesn't work too well. > Changing the line to this: > > XSTRING ((FIX_CALL_DUMMY (dummy, pc, fun, nargs, args, type, gcc_p)))); > ^ ^ > > "fixes" the problem but I fear that we would just be using a gcc > specific extension by doing this. Very gcc specific. I'll go through and see which ones can't be expanded, sigh. sorry, Andrew >From kettenis@wins.uva.nl Sun Jun 11 17:03:00 2000 From: Mark Kettenis To: gareth@precisioninsight.com Cc: alan@lxorguk.ukuu.org.uk, drepper@redhat.com, adam@yggdrasil.com, linux-kernel@vger.rutgers.edu, bug-glibc@gnu.org, gdb@sourceware.cygnus.com Subject: Re: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1 Date: Sun, 11 Jun 2000 17:03:00 -0000 Message-id: <200006120002.e5C02mv14043@delius.kettenis.local> References: <394428DD.A2EFC21B@precisioninsight.com> X-SW-Source: 2000-06/msg00082.html Content-length: 1773 Date: Sun, 11 Jun 2000 18:03:41 -0600 From: Gareth Hughes Here's a copy of my latest work, this time kernel and glibc headers only. I'm still working on updating GDB, as incorporating Mark's suggestions leads to some problems with the stock 5.0 code (mainly in the interpretation of the FPU tag word). Looks much better :-). I didn't realize there were tag word problems until yesterday :-(. If this means that stock GDB 5.0 won't work anymore, so be it. A sane kernel interface is more important. What exactly happens if you try to compile stock GDB 5.0 with the new kernel? Does it compile at all? Is it seriously crippled? Or does it basically work right? If there are major problems, it might be wise to choose a different name for the PTRACE_{GET,SET}XFPREGS requests to avoid confusion. That way, nobody will end up with a non-functional GDB (of course the blame lies entirely with the GDB team for this mess). My suggestion would be to call those requests PTRACE_{GET,SET}FPXREGS. It turns out that Unixware uses a similar name for its FXSR support (they don't have ptrace(), but they have a PCSFPXREG ioctl() and a __fpxregset_t type[1]). Moreover this makes the FSAVE/FPREGS vs. FXSAVE/FPXREGS analogy a bit more explicit. Mark [1] The patch implementing the FXSR support for Unixware is PTF7406B, which you can get at the following URLs: ftp://ftp.sco.com/SLS/ptf7406b.txt (description) ftp://ftp.sco.com/SLS/ptf7406b.Z (the actual patch) The patch is a `pkg Datastream (SVR4)' (according to file(1)), but if you ignore the binary bits you can read the documentation and header files. Anyhow, people might want to take a look at this for additional inspiration. >From kettenis@wins.uva.nl Sun Jun 11 17:09:00 2000 From: Mark Kettenis To: ac131313@cygnus.com Cc: cgf@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: gdbarch.c problem building for cygwin Date: Sun, 11 Jun 2000 17:09:00 -0000 Message-id: <200006120009.e5C092J14064@delius.kettenis.local> References: <20000611124302.A2804@cygnus.com> <394425AE.E1228A9E@cygnus.com> X-SW-Source: 2000-06/msg00083.html Content-length: 791 Date: Mon, 12 Jun 2000 09:50:06 +1000 From: Andrew Cagney Chris Faylor wrote: > FIX_CALL_DUMMY expands to a { .. } block on i386 so this doesn't > work too well. Changing the line to this: > > XSTRING ((FIX_CALL_DUMMY (dummy, pc, fun, nargs, args, type, gcc_p)))); > > "fixes" the problem but I fear that we would just be using a gcc > specific extension by doing this. Very gcc specific. I'll go through and see which ones can't be expanded, sigh. The obvious solution is of course to change FIX_CALL_DUMMY for the i386 :-). I'll turn it into a proper function in i386-tdep.c, and change config/i386/tm-i386.h accordingly. That wouldn't fix i[3456]86-*-sunos* but we've almost decided that that one is obsolete :-). Mark >From ac131313@cygnus.com Sun Jun 11 17:35:00 2000 From: Andrew Cagney To: Mark Kettenis Cc: cgf@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: gdbarch.c problem building for cygwin Date: Sun, 11 Jun 2000 17:35:00 -0000 Message-id: <3944300E.ACB4339A@cygnus.com> References: <20000611124302.A2804@cygnus.com> <394425AE.E1228A9E@cygnus.com> <200006120009.e5C092J14064@delius.kettenis.local> X-SW-Source: 2000-06/msg00084.html Content-length: 969 Mark Kettenis wrote: > > Date: Mon, 12 Jun 2000 09:50:06 +1000 > From: Andrew Cagney > > Chris Faylor wrote: > > > FIX_CALL_DUMMY expands to a { .. } block on i386 so this doesn't > > work too well. Changing the line to this: > > > > XSTRING ((FIX_CALL_DUMMY (dummy, pc, fun, nargs, args, type, gcc_p)))); > > > > "fixes" the problem but I fear that we would just be using a gcc > > specific extension by doing this. > > Very gcc specific. I'll go through and see which ones can't be > expanded, sigh. > > The obvious solution is of course to change FIX_CALL_DUMMY for the > i386 :-). I'll turn it into a proper function in i386-tdep.c, and > change config/i386/tm-i386.h accordingly. That wouldn't fix > i[3456]86-*-sunos* but we've almost decided that that one is obsolete > :-). :-) I've checked in the attached. It stops the dump when the function is void and things aren't multi-arch. Andrew >From kettenis@wins.uva.nl Sun Jun 11 18:47:00 2000 From: Mark Kettenis To: ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com Cc: cgf@cygnus.com, gdb@sourceware.cygnus.com Subject: [PATCH] Re: gdbarch.c problem building for cygwin Date: Sun, 11 Jun 2000 18:47:00 -0000 Message-id: <200006120147.e5C1l2m24732@delius.kettenis.local> References: <20000611124302.A2804@cygnus.com> <394425AE.E1228A9E@cygnus.com> <200006120009.e5C092J14064@delius.kettenis.local> <3944300E.ACB4339A@cygnus.com> X-SW-Source: 2000-06/msg00085.html Content-length: 3575 Date: Mon, 12 Jun 2000 10:34:22 +1000 From: Andrew Cagney > The obvious solution is of course to change FIX_CALL_DUMMY for the > i386 :-). I'll turn it into a proper function in i386-tdep.c, and > change config/i386/tm-i386.h accordingly. That wouldn't fix > i[3456]86-*-sunos* but we've almost decided that that one is obsolete > :-). :-) I've checked in the attached. It stops the dump when the function is void and things aren't multi-arch. I nevertheless checked in the following patch, since it is a small in the direction of multi-arching the i386. Mark 2000-06-12 Mark Kettenis * config/i386/tm-i386.h: Add forward declaration of `struct value'. (FIX_CALL_DUMMY): Redefined to call i386_fix_call_dummy. (i386_fix_call_dummy): Add prototype. * i386-tdep.c (i386_fix_call_dummy): New function based on the code from the old FIX_CALL_DUMMY macro. Index: i386-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/i386-tdep.c,v retrieving revision 1.13 diff -u -p -r1.13 i386-tdep.c --- i386-tdep.c 2000/06/08 00:52:56 1.13 +++ i386-tdep.c 2000/06/12 01:43:04 @@ -638,6 +638,26 @@ i386_push_dummy_frame () write_register (SP_REGNUM, sp); } +/* Insert the (relative) function address into the call sequence + stored at DYMMY. */ + +void +i386_fix_call_dummy (char *dummy, CORE_ADDR pc, CORE_ADDR fun, int nargs, + value_ptr *args, struct type *type, int gcc_p) +{ + int from, to, delta, loc; + + loc = (int)(read_register (SP_REGNUM) - CALL_DUMMY_LENGTH); + from = loc + 5; + to = (int)(fun); + delta = to - from; + + *((char *)(dummy) + 1) = (delta & 0xff); + *((char *)(dummy) + 2) = ((delta >> 8) & 0xff); + *((char *)(dummy) + 3) = ((delta >> 16) & 0xff); + *((char *)(dummy) + 4) = ((delta >> 24) & 0xff); +} + void i386_pop_frame () { Index: config/i386/tm-i386.h =================================================================== RCS file: /cvs/src/src/gdb/config/i386/tm-i386.h,v retrieving revision 1.6 diff -u -p -r1.6 tm-i386.h --- config/i386/tm-i386.h 2000/05/28 01:12:35 1.6 +++ config/i386/tm-i386.h 2000/06/12 01:43:04 @@ -21,9 +21,10 @@ #ifndef TM_I386_H #define TM_I386_H 1 -/* Forward decl's for prototypes */ +/* Forward declarations for prototypes. */ struct frame_info; struct frame_saved_regs; +struct value; struct type; #define TARGET_BYTE_ORDER LITTLE_ENDIAN @@ -408,19 +409,13 @@ extern void i386_pop_frame (void); /* Insert the specified number of args and function address into a call sequence of the above form stored at DUMMYNAME. */ -#define FIX_CALL_DUMMY(dummyname, pc, fun, nargs, args, type, gcc_p) \ -{ \ - int from, to, delta, loc; \ - loc = (int)(read_register (SP_REGNUM) - CALL_DUMMY_LENGTH); \ - from = loc + 5; \ - to = (int)(fun); \ - delta = to - from; \ - *((char *)(dummyname) + 1) = (delta & 0xff); \ - *((char *)(dummyname) + 2) = ((delta >> 8) & 0xff); \ - *((char *)(dummyname) + 3) = ((delta >> 16) & 0xff); \ - *((char *)(dummyname) + 4) = ((delta >> 24) & 0xff); \ -} +#define FIX_CALL_DUMMY(dummyname, pc, fun, nargs, args, type, gcc_p) \ + i386_fix_call_dummy (dummyname, pc, fun, nargs, args, type, gcc_p) +extern void i386_fix_call_dummy (char *dummy, CORE_ADDR pc, CORE_ADDR fun, + int nargs, struct value **args, + struct type *type, int gcc_p); +/* FIXME: kettenis/2000-06-12: These do not belong here. */ extern void print_387_control_word (unsigned int); extern void print_387_status_word (unsigned int);