From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: annotate.texi Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C55BEE.D8E6F7BE@apple.com> References: <200003070832.DAA14451@indy.delorie.com> X-SW-Source: 2000-q1/msg00561.html Eli Zaretskii wrote: > > Is there any reason why annotate.texi shouldn't be @include'd by > gdb.texinfo and be part of the manual? Right now, "set annotate" is > not documented at all, and annotate.texi seems to be just what the > doctor ordered... This is on my long-term wish list for the manual, along with agentexpr info. My guiding principle is that the manual should document everything that a user can do with GDB, so it should include information about builtin protocols, such as annotation, remote debug, and MI. Conversely, the internals manual is for anything that involves looking at GDB's source code. > And while at that, NEWS seems to be in the need of some work, it > doesn't mention many of the new features that already are in the CVS > tree. I would like at least to mention the improvements in the DJGPP > version. Yes please. To paraphrase the esteemed Dr Wirtiglieben, when speaking of the Doomsday Device: VUT GOOD IS IT IF NOBODY KNOWS ABOUT IT!!?? :-) But seriously, everybody doing a checkin should ask themselves: will users want to know about this change? Usually the answer will be yes; users complain about lack of information far more often than about overloaded... Stan >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: ac131313@cygnus.com Cc: agold@bga.com, gdb@sourceware.cygnus.com Subject: Re: gdb does not `break' when using LD_PRELOAD Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002171430.e1HEUt801735@delius.kettenis.local> References: <388F30C2.B6795E21@bga.com> <38ABB665.CFA09B56@cygnus.com> X-SW-Source: 2000-q1/msg00328.html Content-length: 1006 Date: Thu, 17 Feb 2000 19:50:45 +1100 From: Andrew Cagney "Arthur H. Gold" wrote: > > gdb list: > > Since upgrading to glibc-2.1.2, I've been having a problem with gdb-- > specifically in regard to its use with LD_PRELOAD. The problem is that > when running with a preloaded library (either from the shell or set > within gdb) gdb fails to respect any breakpoints I set (though the > breakpoints themselves seem to be set successfully). > > I understand there are problems with 4.18; I have, however, started > to run 4.17-14 (HJ Lu's patched version)--but to no avail. > > Any input would be more than welcome Has anyone looked at this, or got any suggestions/comments? AFAICT setting breakpoints in preloaded libraries seems to work fine on i586-pc-linux-gnu with a glibc-2.1.3 snapshot. Setting breakpoints works and they are properly triggered. Arthur, can you provide a small test-case, that shows your problems? Mark >From jsm@cygnus.com Sat Apr 01 00:00:00 2000 From: Jason Molenda To: Jimmy Guo Cc: gdb@sourceware.cygnus.com, gdb-testers@sourceware.cygnus.com Subject: Re: Problems with the new GDB repository source Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000207195157.C28795@cygnus.com> References: <20000206224315.A25084@cygnus.com> <20000207194817.A28795@cygnus.com> X-SW-Source: 2000-q1/msg00155.html Content-length: 635 On Mon, Feb 07, 2000 at 07:48:17PM -0800, Jason Molenda wrote: > At some point in the future (I have no idea when), someone will merge the > sourceware binutils repo with the Cygnus binutils repo and the changes > that had been happening within Cygnus will get out there. Incidentally, I should add that few changes are actually done to libiberty on the internal Cygnus repo any more. My guess is that these changes were in GCC (I think GCC is defined as the master set of sources for libiberty?), were merged from the GCC repo into the Cygnus internal repo, but haven't yet been merged in to the binutils sourceware repo. Jason >From toddpw@windriver.com Sat Apr 01 00:00:00 2000 From: Todd Whitesel To: gdb@sourceware.cygnus.com (GDB Developers) Subject: symfile.c:symfile_bfd_open() Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003241351.FAA06850@alabama.wrs.com> X-SW-Source: 2000-q1/msg00795.html Content-length: 819 While merging up to 4.18 (as a stepping stone to devo), I noticed something that we're doing locally here which seems generally useful for cross developing folks. symfile.c:symfile_bfd_open() opens objects/executables using BFD. It tells openp() to search the $PATH, which is obviously handy for native, but seems to make no sense whatsoever for cross development. Our local patch is to add a second argument to symfile_bfd_open, "use_source_path", which ends up being set to 1 nearly all of the time, since with our targets we are always cross developing. In that case, we have openp() search source_path instead of getenv("PATH"). Does the multi-arch stuff provide a clean test for native vs. cross? That'd be a better decision-maker than the "use_source_path" argument. -- Todd Whitesel toddpw @ windriver.com >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Kevin Buettner Cc: gdb@sourceware.cygnus.com Subject: Re: Patches for GNU/Linux PPC native now in CVS Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B1FF0B.F9F0A939@cygnus.com> References: <1000222025201.ZM9805@ocotillo.lan> X-SW-Source: 2000-q1/msg00366.html Content-length: 134 Kevin Buettner wrote: > [....] Kevin, I'd suggest also putting a brief announcement on gdb-announce at sourceware. (Cool!). Andrew >From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000 From: Jim Blandy To: Eli Zaretskii Cc: Jim Blandy , hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Problems with hardware watchpoint on ia32. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091210.HAA19857@indy.delorie.com> <200003221806.NAA14225@indy.delorie.com> X-SW-Source: 2000-q1/msg00819.html Content-length: 608 > I seem to be unable to reproduce the problem, at least in a C program: > whenever I say "watch foo == bar" (where foo and bar are structs), GDB > curses thusly: > > Structure has no component named operator==. > > Am I missing something? As Michael points out, structure comparison is broken. But that doesn't change my original point --- that it's perfectly legitimate to have `struct value' objects representing structures, which should be watched in their entirety. The type of a value is irrelevant --- we're trying to track the memory references made in the course of evaluating the expression. >From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: gdb@sourceware.cygnus.com Subject: Re: gdbstubs library posted at sourceforge Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200001291645.LAA19052@devserv.devel.redhat.com> References: <200001271910.OAA04242@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00073.html Content-length: 1956 > * I don't want someone turning gdbstubs itself into a closed source > product Well, my own personal perspective is that the #1 thing which prevents this is an active community which is developing the open product. If someone can avoid all the engineering costs of doing their own closed fork, and get a much better result, they often will. If the open version has stagnated, then they are kind of stuck with doing their own version. So I think putting it on sourceforge is the key thing which will encourage people to contribute to gdbstubs, not the license (in the past, noone had a suitable process for accepting submissions to the stubs). > (particularly the tracepoint stuff, when it arrives) Ah, I see, scars from the proprietary tracepoint stubs. The story here is that Red Hat is committed to open source and much of the code which was closed source pre-merger will be opened. However, I have no idea how that applies to tracepoint stubs (there are a lot of programs/products to sort through and look at both business and technical sides, and I wouldn't be surprised if tracepoints are a pawn in a larger game and/or lost in the shuffle :-)). You could argue that Cygnus's past actions disprove this, but I'd argue that there just isn't much economic value in proprietary stubs, and thus little risk/likelihood that we'll see a lot of proprietary stubs. When Red Hat files their financials for the first quarter combined with Cygnus (late March) you'll see actual numbers (at least, I think so, I guess I don't know for sure exactly how they will break it down). > Maybe CEPL is a closer fit for what I'm after, because it accomplishes > everything the LGPL does *and* eliminates the need for .o's? I could > go there. I would think CEPL/Mozilla works better than LGPL, yes (the CEPL is basically the same license as the Mozilla license for those who don't know - see http://sourceware.cygnus.com/ecos/ and http://www.mozilla.org/ ). >From tromey@cygnus.com Sat Apr 01 00:00:00 2000 From: Tom Tromey To: gdb@sourceware.cygnus.com Subject: Re: Patch: Remove 'Dave' error message. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <874sba1arg.fsf@cygnus.com> References: <200002150059.QAA02943@elmo.cygnus.com> <20000214171818.A15790@cygnus.com> X-SW-Source: 2000-q1/msg00300.html Content-length: 359 Jason> I think his patch was quietly ignored because it reduces the Jason> humor value of gdb. gdb is a boring program and we need all Jason> the humor I can get. Jason> I agree that it is not very helpful for foreigners to have Jason> things like this in there, sigh. If gdb used GNU gettext we could replace it with a locale-specific joke. Tom >From blizzard@redhat.com Sat Apr 01 00:00:00 2000 From: Chris Blizzard To: gdb@sourceware.cygnus.com Subject: Re: problems with gdb Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38AB2DC4.FA9A3C71@redhat.com> References: <38A47E89.3F4674B3@mozilla.org> X-SW-Source: 2000-q1/msg00313.html Content-length: 1986 So, one of the problems that I've been having is that some large .so libraries take forever to load. One of the libraries is about 28 meg with debugging symbols in it. I've let it run for about 10 mins and it's never finished loading. Here's what gprof says for loading a reasonable sized library ( 5 meg or so ): Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 70.98 19.47 19.47 11954 1.63 2.25 lookup_minimal_symbol 27.12 26.91 7.44 33240213 0.00 0.00 strcmp_iw 0.33 27.00 0.09 3 30.00 9038.95 read_dbx_symtab 0.15 27.04 0.04 44554 0.00 0.00 hash 0.11 27.07 0.03 337915 0.00 0.00 bfd_getl32 0.11 27.10 0.03 44554 0.00 0.00 bcache 0.11 27.13 0.03 150 0.20 0.20 end_psymtab Uhh...that's 33 _million_ calls. That looks like this chunk of code: for (objfile = object_files; objfile != NULL && found_symbol == NULL; objfile = objfile->next) { if (objf == NULL || objf == objfile) { for (msymbol = objfile->msymbols; msymbol != NULL && SYMBOL_NAME (msymbol) != NULL && found_symbol == NULL; msymbol++) { if (SYMBOL_MATCHES_NAME (msymbol, name)) { switch (MSYMBOL_TYPE (msymbol)) { case mst_file_text: I'm sorry, is that looking over a linked list? SYMBOL_MATCHES_NAME() is a macro that does some mangling magic so we can't use a standard hash lookup table but there has to be something we can do to speed that up. --Chris -- ------------ Christopher Blizzard http://people.redhat.com/blizzard/ A few years back, I saw a young child stuck in a tree. Nowadays, when I find myself in a troubling situation, I look back and wonder if that kid saw me take that chocolate bar from his backpack on the ground. ------------ >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Mark Kettenis Cc: aj@suse.de, gdb@sourceware.cygnus.com Subject: Re: core dump from GNU/Linux ; Was: Build failure on Linux/i686 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A7DA9C.F82221C9@cygnus.com> References: <200002101919.UAA23595@landau.wins.uva.nl> <38A353C3.DDD9A240@cygnus.com> <200002110736.e1B7afa00398@delius.kettenis.local> X-SW-Source: 2000-q1/msg00261.html Content-length: 1284 Mark Kettenis wrote: > > Date: Fri, 11 Feb 2000 11:11:47 +1100 > From: Andrew Cagney > > Mark Kettenis wrote: > > > This is the solution I proposed: > > > > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00103.html > > > > Note that you'll need to patch too, otherwise GDB will > > segfault when you try to debug a multithreaded app! > > Um, can you expand on this a little? (You may have already). > > The first version of glibc that includes the threads debugging library > (libthread.so) will be 2.1.3, which has not been officially released > yet. Since both Andreas and I are glibc developers we were among the > first to test a GDB that makes use of that functionality apart from > the people who actually implemented it. It looks as if Ulrich Drepper > (the glibc maintainer) and Michael have let things go slighty out of > sync. So without patches to both GDB and the glibc prereleases it > won't work. > > If there is a header file found in a standard GNU/Linux distribution > that can cause GDB to dump core we're going to need some sort of evasive > action. Sigh. > > That's what I'm trying to prevent :-) Ok. That sounds like the best that can be done. Thanks! Andrew >From france@crl.dec.com Sat Apr 01 00:00:00 2000 From: George France To: "'Xavier Bestel'" , gdb@sourceware.cygnus.com Subject: RE: single-step Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: X-SW-Source: 2000-q1/msg00448.html Content-type: multipart/mixed; boundary="----------=_1583534244-23286-7" This is a multi-part message in MIME format... ------------=_1583534244-23286-7 Content-length: 1102 Hello Xavier; Which ARM dev board do you have?? I have attached a patch for ptrace.c for Linux 2.2.14 that will allow you to single step on the armv4l architecture. The patch implements PTRACE_GETREGS, PTRACE_SETREGS, PTRACE_GETFPREGS & PTRACE_SETREGS, with PTRACE_SET_BPT etc.... Best Regards, --George George France, france@crl.dec.com Cambridge Research Laboratory, Compaq Computer Corporation One Kendall Square, Building 700 MS: CRL Cambridge, MA 02139 USA -----Original Message----- From: Xavier Bestel [ mailto:xbestel@aplio.fr ] Sent: Monday, February 28, 2000 9:44 AM To: gdb@sourceware.cygnus.com Subject: single-step Hi ! I have and ARM dev board hooked to a Jeeni, controlled via ethernet. It doesn't singl-step, it only stops at breakpoints. When I issue a "info target", gdb replies that "Target can't single-step". However I would greatly appreciate it to single step to debug my apps ... So do you know how to fix it ? Is it a hardware non-feature or a simple software misconfiguration ? Can gdb emulate singlestepping transparently using breakpoints ? Xav ------------=_1583534244-23286-7 Content-Type: text/x-diff; charset=us-ascii; name="ptrace-for-2.2.14-patch" Content-Disposition: inline; filename="ptrace-for-2.2.14-patch" Content-Transfer-Encoding: base64 Content-Length: 18780 LS0tIC9za2lmZi9qYW1leS9saW51eC0yLjIuMTQtcm1rMy1jcmwxL2luY2x1 ZGUvYXNtLWFybS9wdHJhY2UuaAlUdWUgSmFuIDE4IDE4OjEzOjA5IDIwMDAK KysrIC91c3Ivc3JjL2xpbnV4L2luY2x1ZGUvYXNtLWFybS9wdHJhY2UuaAlX ZWQgSmFuIDI2IDAxOjIxOjM3IDIwMDAKQEAgLTMsNiArMywxMyBAQAogCiAj aW5jbHVkZSA8YXNtL3Byb2MvcHRyYWNlLmg+CiAKKworI2RlZmluZSBQVFJB Q0VfR0VUUkVHUwkJMTIKKyNkZWZpbmUgUFRSQUNFX1NFVFJFR1MJCTEzCisj ZGVmaW5lIFBUUkFDRV9HRVRGUFJFR1MJMTQKKyNkZWZpbmUgUFRSQUNFX1NF VEZQUkVHUwkxNQorCisKICNpZmRlZiBfX0tFUk5FTF9fCiBleHRlcm4gdm9p ZCBzaG93X3JlZ3Moc3RydWN0IHB0X3JlZ3MgKik7CiAjZW5kaWYKLS0tIC9z a2lmZi9qYW1leS9saW51eC0yLjIuMTQtcm1rMy1jcmwxL2luY2x1ZGUvYXNt LWFybS9wcm9jZXNzb3IuaAlUdWUgSmFuIDE4IDE4OjEzOjA5IDIwMDAKKysr IC91c3Ivc3JjL2xpbnV4L2luY2x1ZGUvYXNtLWFybS9wcm9jZXNzb3IuaAlX ZWQgSmFuIDI2IDAxOjIxOjUxIDIwMDAKQEAgLTMyLDEyICszMiwyMCBAQAog I2luY2x1ZGUgPGFzbS9hcmNoL3Byb2Nlc3Nvci5oPgogI2luY2x1ZGUgPGFz bS9wcm9jL3Byb2Nlc3Nvci5oPgogCitzdHJ1Y3QgZGVidWdfaW5mbyB7CisJ aW50CQkJCW5zYXZlZDsKKwlzdHJ1Y3QgeworCQl1bnNpZ25lZCBsb25nCQlh ZGRyZXNzOworCQl1bnNpZ25lZCBsb25nCQlpbnNuOworCX0gYnBbMl07Cit9 OworCiBzdHJ1Y3QgdGhyZWFkX3N0cnVjdCB7CiAJdW5zaWduZWQgbG9uZwkJ CWFkZHJlc3M7CSAgLyogQWRkcmVzcyBvZiBmYXVsdAkqLwogCXVuc2lnbmVk IGxvbmcJCQl0cmFwX25vOwkgIC8qIFRyYXAgbnVtYmVyCSovCiAJdW5zaWdu ZWQgbG9uZwkJCWVycm9yX2NvZGU7CSAgLyogRXJyb3IgY29kZSBvZiB0cmFw CSovCiAJdW5pb24gZnBfc3RhdGUJCQlmcHN0YXRlOwkgIC8qIEZQRSBzYXZl IHN0YXRlCSovCi0JdW5zaWduZWQgbG9uZwkJCWRlYnVnW05SX0RFQlVHU107 IC8qIERlYnVnL3B0cmFjZQkqLworCXN0cnVjdCBkZWJ1Z19pbmZvCQlkZWJ1 ZzsgICAgICAgICAgICAvKiBEZWJ1Zy9wdHJhY2UJKi8KIAlzdHJ1Y3QgY29u dGV4dF9zYXZlX3N0cnVjdAkqc2F2ZTsJCSAgLyogY29udGV4dCBzYXZlCSov CiAJdW5zaWduZWQgbG9uZwkJCW1lbW1hcDsJCSAgLyogcGFnZSB0YWJsZXMJ Ki8KIAlFWFRSQV9USFJFQURfU1RSVUNUCi0tLSAvc2tpZmYvamFtZXkvbGlu dXgtMi4yLjE0LXJtazMtY3JsMS9hcmNoL2FybS9rZXJuZWwvcHRyYWNlLmMJ VHVlIEphbiAxOCAxODowNjoxMyAyMDAwCisrKyAvdXNyL3NyYy9saW51eC9h cmNoL2FybS9rZXJuZWwvcHRyYWNlLmMJV2VkIEphbiAyNiAwMToyMTozOCAy MDAwCkBAIC0xMiwxMCArMTIsMTMgQEAKICNpbmNsdWRlIDxsaW51eC9wdHJh Y2UuaD4KICNpbmNsdWRlIDxsaW51eC91c2VyLmg+CiAKKwogI2luY2x1ZGUg PGFzbS91YWNjZXNzLmg+CiAjaW5jbHVkZSA8YXNtL3BndGFibGUuaD4KICNp bmNsdWRlIDxhc20vc3lzdGVtLmg+CiAKKworCiAvKgogICogZG9lcyBub3Qg eWV0IGNhdGNoIHNpZ25hbHMgc2VudCB3aGVuIHRoZSBjaGlsZCBkaWVzLgog ICogaW4gZXhpdC5jIG9yIGluIHNpZ25hbC5jLgpAQCAtMjYsMzcgKzI5LDkg QEAKICAqLwogI2RlZmluZSBCUkVBS0lOU1QJMHhlZjlmMDAwMQogCi0vKgot ICogdGhpcyByb3V0aW5lIHdpbGwgZ2V0IGEgd29yZCBvZmYgb2YgdGhlIHBy b2Nlc3NlcyBwcml2aWxlZ2VkIHN0YWNrLgotICogdGhlIG9mZnNldCBpcyBo b3cgZmFyIGZyb20gdGhlIGJhc2UgYWRkciBhcyBzdG9yZWQgaW4gdGhlIFRT Uy4KLSAqIHRoaXMgcm91dGluZSBhc3N1bWVzIHRoYXQgYWxsIHRoZSBwcml2 aWxlZ2VkIHN0YWNrcyBhcmUgaW4gb3VyCi0gKiBkYXRhIHNwYWNlLgotICov Ci1zdGF0aWMgaW5saW5lIGxvbmcgZ2V0X3N0YWNrX2xvbmcoc3RydWN0IHRh c2tfc3RydWN0ICp0YXNrLCBpbnQgb2Zmc2V0KQotewotCXVuc2lnbmVkIGNo YXIgKnN0YWNrOwogCi0Jc3RhY2sgPSAodW5zaWduZWQgY2hhciAqKSgodW5z aWduZWQgbG9uZyl0YXNrICsgODE5MiAtIHNpemVvZihzdHJ1Y3QgcHRfcmVn cykpOwotCXN0YWNrICs9IG9mZnNldCA8PCAyOwotCXJldHVybiAqKHVuc2ln bmVkIGxvbmcgKilzdGFjazsKLX0KIAotLyoKLSAqIHRoaXMgcm91dGluZSB3 aWxsIHB1dCBhIHdvcmQgb24gdGhlIHByb2Nlc3NlcyBwcml2aWxlZ2VkIHN0 YWNrLgotICogdGhlIG9mZnNldCBpcyBob3cgZmFyIGZyb20gdGhlIGJhc2Ug YWRkciBhcyBzdG9yZWQgaW4gdGhlIFRTUy4KLSAqIHRoaXMgcm91dGluZSBh c3N1bWVzIHRoYXQgYWxsIHRoZSBwcml2aWxlZ2VkIHN0YWNrcyBhcmUgaW4g b3VyCi0gKiBkYXRhIHNwYWNlLgotICovCi1zdGF0aWMgaW5saW5lIGxvbmcg cHV0X3N0YWNrX2xvbmcoc3RydWN0IHRhc2tfc3RydWN0ICp0YXNrLCBpbnQg b2Zmc2V0LAotCXVuc2lnbmVkIGxvbmcgZGF0YSkKLXsKLQl1bnNpZ25lZCBj aGFyICpzdGFjazsKIAotCXN0YWNrID0gKHVuc2lnbmVkIGNoYXIgKikoKHVu c2lnbmVkIGxvbmcpdGFzayArIDgxOTIgLSBzaXplb2Yoc3RydWN0IHB0X3Jl Z3MpKTsKLQlzdGFjayArPSBvZmZzZXQgPDwgMjsKLQkqKHVuc2lnbmVkIGxv bmcgKikgc3RhY2sgPSBkYXRhOwotCXJldHVybiAwOwotfQogCiAvKgogICog VGhpcyByb3V0aW5lIGdldHMgYSBsb25nIGZyb20gYW55IHByb2Nlc3Mgc3Bh Y2UgYnkgZm9sbG93aW5nIHRoZSBwYWdlCkBAIC0xNzMsNiArMTQ4LDcgQEAK IAkJZm9yY2Vfc2lnKFNJR0tJTEwsIHRzayk7CiB9CiAKKwogc3RhdGljIHN0 cnVjdCB2bV9hcmVhX3N0cnVjdCAqIGZpbmRfZXh0ZW5kX3ZtYShzdHJ1Y3Qg dGFza19zdHJ1Y3QgKiB0c2ssIHVuc2lnbmVkIGxvbmcgYWRkcikKIHsKIAlz dHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKiB2bWE7CkBAIC0xOTIsNiArMTY4LDQy IEBACiAJcmV0dXJuIHZtYTsKIH0KIAorCisKKy8qCisgKiB0aGlzIHJvdXRp bmUgd2lsbCBnZXQgYSB3b3JkIG9mZiBvZiB0aGUgcHJvY2Vzc2VzIHByaXZp bGVnZWQgc3RhY2suCisgKiB0aGUgb2Zmc2V0IGlzIGhvdyBmYXIgZnJvbSB0 aGUgYmFzZSBhZGRyIGFzIHN0b3JlZCBpbiB0aGUgVEhSRUFELgorICogdGhp cyByb3V0aW5lIGFzc3VtZXMgdGhhdCBhbGwgdGhlIHByaXZpbGVnZWQgc3Rh Y2tzIGFyZSBpbiBvdXIKKyAqIGRhdGEgc3BhY2UuCisgKi8KK3N0YXRpYyBp bmxpbmUgbG9uZyBnZXRfc3RhY2tfbG9uZyhzdHJ1Y3QgdGFza19zdHJ1Y3Qg KnRhc2ssIGludCBvZmZzZXQpCit7CisJc3RydWN0IHB0X3JlZ3MgKnJlZ3M7 CisKKwlyZWdzID0gKHN0cnVjdCBwdF9yZWdzICopKCh1bnNpZ25lZCBsb25n KXRhc2sgKyA4MTkyIC0gc2l6ZW9mKHN0cnVjdCBwdF9yZWdzKSk7CisKKwly ZXR1cm4gcmVncy0+dXJlZ3Nbb2Zmc2V0XTsKK30KKworLyoKKyAqIHRoaXMg cm91dGluZSB3aWxsIHB1dCBhIHdvcmQgb24gdGhlIHByb2Nlc3NlcyBwcml2 aWxlZ2VkIHN0YWNrLgorICogdGhlIG9mZnNldCBpcyBob3cgZmFyIGZyb20g dGhlIGJhc2UgYWRkciBhcyBzdG9yZWQgaW4gdGhlIFRIUkVBRC4KKyAqIHRo aXMgcm91dGluZSBhc3N1bWVzIHRoYXQgYWxsIHRoZSBwcml2aWxlZ2VkIHN0 YWNrcyBhcmUgaW4gb3VyCisgKiBkYXRhIHNwYWNlLgorICovCitzdGF0aWMg aW5saW5lIGxvbmcgcHV0X3N0YWNrX2xvbmcoc3RydWN0IHRhc2tfc3RydWN0 ICp0YXNrLCBpbnQgb2Zmc2V0LAorCXVuc2lnbmVkIGxvbmcgZGF0YSkKK3sK KwlzdHJ1Y3QgcHRfcmVncyAqcmVnczsKKworCXJlZ3MgPSAoc3RydWN0IHB0 X3JlZ3MgKikoKHVuc2lnbmVkIGxvbmcpdGFzayArIDgxOTIgLSBzaXplb2Yo c3RydWN0IHB0X3JlZ3MpKTsKKworCXJlZ3MtPnVyZWdzW29mZnNldF0gPSBk YXRhOworCisJcmV0dXJuIDA7Cit9CisKKwogLyoKICAqIFRoaXMgcm91dGlu ZSBjaGVja3MgdGhlIHBhZ2UgYm91bmRhcmllcywgYW5kIHRoYXQgdGhlIG9m ZnNldCBpcwogICogd2l0aGluIHRoZSB0YXNrIGFyZWEuIEl0IHRoZW4gY2Fs bHMgZ2V0X2xvbmcoKSB0byByZWFkIGEgbG9uZy4KQEAgLTI4Niw2ICsyOTgs OCBAQAogCXJldHVybiAwOwogfQogCisKKwogLyoKICAqIEdldCB2YWx1ZSBv ZiByZWdpc3RlciBgcm4nIChpbiB0aGUgaW5zdHJ1Y3Rpb24pCiAgKi8KQEAg LTI5OSw3ICszMTMsNiBAQAogCWVsc2UKIAkJdmFsID0gZ2V0X3N0YWNrX2xv bmcgKGNoaWxkLCByZWcpOwogCi1wcmludGsgKCJyJTAyZD0lMDhsWCAiLCBy ZWcsIHZhbCk7CiAJcmV0dXJuIHZhbDsKIH0KIApAQCAtMzEyLDEyICszMjUs MTAgQEAKIAlpbnQgc2hpZnQ7CiAJaW50IHR5cGU7CiAKLXByaW50ayAoIm9w Mj0iKTsKIAlpZiAoaW5zbiAmIDEgPDwgMjUpIHsKIAkJdmFsID0gaW5zbiAm IDI1NTsKIAkJc2hpZnQgPSAoaW5zbiA+PiA4KSAmIDE1OwogCQl0eXBlID0g MzsKLXByaW50ayAoIihpbW0pIik7CiAJfSBlbHNlIHsKIAkJdmFsID0gZ2V0 X3N0YWNrX2xvbmcgKGNoaWxkLCBpbnNuICYgMTUpOwogCkBAIC0zMjcsOSAr MzM4LDcgQEAKIAkJCXNoaWZ0ID0gKGluc24gPj4gNykgJiAzMTsKIAogCQl0 eXBlID0gKGluc24gPj4gNSkgJiAzOwotcHJpbnRrICgiKHIlMDJsZCkiLCBp bnNuICYgMTUpOwogCX0KLXByaW50ayAoInNoJWR4JWQiLCB0eXBlLCBzaGlm dCk7CiAJc3dpdGNoICh0eXBlKSB7CiAJY2FzZSAwOgl2YWwgPDw9IHNoaWZ0 OwlicmVhazsKIAljYXNlIDE6CXZhbCA+Pj0gc2hpZnQ7CWJyZWFrOwpAQCAt MzM3LDEwICszNDYsOSBAQAogCQl2YWwgPSAoKChzaWduZWQgbG9uZyl2YWwp ID4+IHNoaWZ0KTsKIAkJYnJlYWs7CiAJY2FzZSAzOgotCQlfX2FzbV9fIF9f dm9sYXRpbGVfXygibW92ICUwLCAlMCwgcm9yICUxIiA6ICI9ciIgKHZhbCkg OiAiMCIgKHZhbCksICJyIiAoc2hpZnQpKTsKKyAJCXZhbCA9ICh2YWwgPj4g c2hpZnQpIHwgKHZhbCA8PCAoMzIgLSBzaGlmdCkpOwogCQlicmVhazsKIAl9 Ci1wcmludGsgKCI9JTA4bFggIiwgdmFsKTsKIAlyZXR1cm4gdmFsOwogfQog CkBAIC0zNTcsNyArMzY1LDYgQEAKIAlzaGlmdCA9IChpbnNuID4+IDcpICYg MzE7CiAJdHlwZSA9IChpbnNuID4+IDUpICYgMzsKIAotcHJpbnRrICgib3Ay PXIlMDJsZHNoJWR4JWQiLCBpbnNuICYgMTUsIHNoaWZ0LCB0eXBlKTsKIAlz d2l0Y2ggKHR5cGUpIHsKIAljYXNlIDA6CXZhbCA8PD0gc2hpZnQ7CWJyZWFr OwogCWNhc2UgMToJdmFsID4+PSBzaGlmdDsJYnJlYWs7CkBAIC0zNjUsMzMg KzM3MiwyMiBAQAogCQl2YWwgPSAoKChzaWduZWQgbG9uZyl2YWwpID4+IHNo aWZ0KTsKIAkJYnJlYWs7CiAJY2FzZSAzOgotCQlfX2FzbV9fIF9fdm9sYXRp bGVfXygibW92ICUwLCAlMCwgcm9yICUxIiA6ICI9ciIgKHZhbCkgOiAiMCIg KHZhbCksICJyIiAoc2hpZnQpKTsKKyAJCXZhbCA9ICh2YWwgPj4gc2hpZnQp IHwgKHZhbCA8PCAoMzIgLSBzaGlmdCkpOwogCQlicmVhazsKIAl9Ci1wcmlu dGsgKCI9JTA4bFggIiwgdmFsKTsKIAlyZXR1cm4gdmFsOwogfQotI3VuZGVm IHBjX3BvaW50ZXIKLSNkZWZpbmUgcGNfcG9pbnRlcih4KSAoKHgpICYgMHgw M2ZmZmZmYykKLWludCBwdHJhY2Vfc2V0X2JwdCAoc3RydWN0IHRhc2tfc3Ry dWN0ICpjaGlsZCkKLXsKLQl1bnNpZ25lZCBsb25nIGluc24sIHBjLCBhbHQ7 Ci0JaW50IGksIG5zYXZlZCA9IDAsIHJlczsKLQotCXBjID0gcGNfcG9pbnRl ciAoZ2V0X3N0YWNrX2xvbmcgKGNoaWxkLCAxNS8qUkVHX1BDKi8pKTsKIAot CXJlcyA9IHJlYWRfbG9uZyAoY2hpbGQsIHBjLCAmaW5zbik7Ci0JaWYgKHJl cyA8IDApCi0JCXJldHVybiByZXM7CitzdGF0aWMgdW5zaWduZWQgbG9uZwor Z2V0X2JyYW5jaF9hZGRyZXNzKHN0cnVjdCB0YXNrX3N0cnVjdCAqY2hpbGQs IHVuc2lnbmVkIGxvbmcgcGMsIHVuc2lnbmVkIGxvbmcgaW5zbikKK3sKKwl1 bnNpZ25lZCBsb25nIGFsdCA9IDA7CiAKLQljaGlsZC0+dHNzLmRlYnVnW25z YXZlZCsrXSA9IGFsdCA9IHBjICsgNDsKLXByaW50ayAoInB0cmFjZV9zZXRf YnB0OiBpbnNuPSUwOGxYIHBjPSUwOGxYICIsIGluc24sIHBjKTsKIAlzd2l0 Y2ggKGluc24gJiAweDBlMTAwMDAwKSB7CiAJY2FzZSAweDAwMDAwMDAwOgog CWNhc2UgMHgwMDEwMDAwMDoKIAljYXNlIDB4MDIwMDAwMDA6CiAJY2FzZSAw eDAyMTAwMDAwOiAvKiBkYXRhIHByb2Nlc3NpbmcgKi8KLQkJcHJpbnRrICgi ZGF0YSAiKTsKIAkJc3dpdGNoIChpbnNuICYgMHgwMWUwZjAwMCkgewogCQlj YXNlIDB4MDAwMGYwMDA6CiAJCQlhbHQgPSBwdHJhY2VfZ2V0cm4oY2hpbGQs IGluc24pICYgcHRyYWNlX2dldGFsdW9wMihjaGlsZCwgaW5zbik7CkBAIC00 MzUsOSArNDMxLDggQEAKIAkJfQogCQlicmVhazsKIAotCWNhc2UgMHgwNDEw MDAwMDogLyogbGRyICovCisJY2FzZSAweDA2MTAwMDAwOiAvKiBsZHIgKi8K IAkJaWYgKChpbnNuICYgMHhmMDAwKSA9PSAweGYwMDApIHsKLXByaW50ayAo ImxkciAiKTsKIAkJCWFsdCA9IHB0cmFjZV9nZXRybihjaGlsZCwgaW5zbik7 CiAJCQlpZiAoaW5zbiAmIDEgPDwgMjQpIHsKIAkJCQlpZiAoaW5zbiAmIDEg PDwgMjMpCkBAIC00NDYsMTUgKzQ0MSwxNCBAQAogCQkJCQlhbHQgLT0gcHRy YWNlX2dldGxkcm9wMiAoY2hpbGQsIGluc24pOwogCQkJfQogCQkJaWYgKHJl YWRfbG9uZyAoY2hpbGQsIGFsdCwgJmFsdCkgPCAwKQotCQkJCWFsdCA9IHBj ICsgNDsgLyogbm90IHZhbGlkICovCisJCQkJYWx0ID0gMDsgLyogbm90IHZh bGlkICovCiAJCQllbHNlCiAJCQkJYWx0ID0gcGNfcG9pbnRlciAoYWx0KTsK IAkJfQogCQlicmVhazsKIAotCWNhc2UgMHgwNjEwMDAwMDogLyogbGRyIGlt bSAqLworCWNhc2UgMHgwNDEwMDAwMDogLyogbGRyIGltbSAqLwogCQlpZiAo KGluc24gJiAweGYwMDApID09IDB4ZjAwMCkgewotcHJpbnRrICgibGRyaW1t ICIpOwogCQkJYWx0ID0gcHRyYWNlX2dldHJuKGNoaWxkLCBpbnNuKTsKIAkJ CWlmIChpbnNuICYgMSA8PCAyNCkgewogCQkJCWlmIChpbnNuICYgMSA8PCAy MykKQEAgLTQ2Myw3ICs0NTcsNyBAQAogCQkJCQlhbHQgLT0gaW5zbiAmIDB4 ZmZmOwogCQkJfQogCQkJaWYgKHJlYWRfbG9uZyAoY2hpbGQsIGFsdCwgJmFs dCkgPCAwKQotCQkJCWFsdCA9IHBjICsgNDsgLyogbm90IHZhbGlkICovCisJ CQkJYWx0ID0gMDsgLyogbm90IHZhbGlkICovCiAJCQllbHNlCiAJCQkJYWx0 ID0gcGNfcG9pbnRlciAoYWx0KTsKIAkJfQpAQCAtNDczLDcgKzQ2Nyw2IEBA CiAJCWlmIChpbnNuICYgKDEgPDwgMTUpKSB7CiAJCQl1bnNpZ25lZCBsb25n IGJhc2U7CiAJCQlpbnQgbnJfcmVnczsKLXByaW50ayAoImxkbSAiKTsKIAog CQkJaWYgKGluc24gJiAoMSA8PCAyMykpIHsKIAkJCQlucl9yZWdzID0gaW5z biAmIDY1NTM1OwpAQCAtNDk2LDcgKzQ4OSw3IEBACiAJCQliYXNlID0gcHRy YWNlX2dldHJuIChjaGlsZCwgaW5zbik7CiAKIAkJCWlmIChyZWFkX2xvbmcg KGNoaWxkLCBiYXNlICsgbnJfcmVncywgJmFsdCkgPCAwKQotCQkJCWFsdCA9 IHBjICsgNDsgLyogbm90IHZhbGlkICovCisJCQkJYWx0ID0gMDsgLyogbm90 IHZhbGlkICovCiAJCQllbHNlCiAJCQkJYWx0ID0gcGNfcG9pbnRlciAoYWx0 KTsKIAkJCWJyZWFrOwpAQCAtNTA2LDcgKzQ5OSw2IEBACiAJY2FzZSAweDBh MDAwMDAwOgogCWNhc2UgMHgwYTEwMDAwMDogeyAvKiBibCBvciBiICovCiAJ CXNpZ25lZCBsb25nIGRpc3BsOwotcHJpbnRrICgiYi9ibCAiKTsKIAkJLyog SXQncyBhIGJyYW5jaC9icmFuY2ggbGluazogaW5zdGVhZCBvZiB0cnlpbmcg dG8KIAkJICogZmlndXJlIG91dCB3aGV0aGVyIHRoZSBicmFuY2ggd2lsbCBi ZSB0YWtlbiBvciBub3QsCiAJCSAqIHdlJ2xsIHB1dCBhIGJyZWFrcG9pbnQg YXQgZWl0aGVyIGxvY2F0aW9uLiAgVGhpcyBpcwpAQCAtNTIxLDQxICs1MTMs OTcgQEAKIAkgICAgfQogCSAgICBicmVhazsKIAl9Ci1wcmludGsgKCI9JTA4 bFhcbiIsIGFsdCk7Ci0JaWYgKGFsdCAhPSBwYyArIDQpCi0JCWNoaWxkLT50 c3MuZGVidWdbbnNhdmVkKytdID0gYWx0OwogCi0JZm9yIChpID0gMDsgaSA8 IG5zYXZlZDsgaSsrKSB7Ci0JCXJlcyA9IHJlYWRfbG9uZyAoY2hpbGQsIGNo aWxkLT50c3MuZGVidWdbaV0sICZpbnNuKTsKLQkJaWYgKHJlcyA+PSAwKSB7 Ci0JCQljaGlsZC0+dHNzLmRlYnVnW2kgKyAyXSA9IGluc247Ci0JCQlyZXMg PSB3cml0ZV9sb25nIChjaGlsZCwgY2hpbGQtPnRzcy5kZWJ1Z1tpXSwgQlJF QUtJTlNUKTsKKwlyZXR1cm4gYWx0OwogCQl9Ci0JCWlmIChyZXMgPCAwKSB7 Ci0JCQljaGlsZC0+dHNzLmRlYnVnWzRdID0gMDsKKworc3RhdGljIGludAor YWRkX2JyZWFrcG9pbnQoc3RydWN0IHRhc2tfc3RydWN0ICpjaGlsZCwgc3Ry dWN0IGRlYnVnX2luZm8gKmRiZywgdW5zaWduZWQgbG9uZyBhZGRyKQorewor CWludCBuciA9IGRiZy0+bnNhdmVkOworCWludCByZXMgPSAtRUlOVkFMOwor CisJaWYgKG5yIDwgMikgeworCQlyZXMgPSByZWFkX2xvbmcoY2hpbGQsIGFk ZHIsICZkYmctPmJwW25yXS5pbnNuKTsKKwkJaWYgKHJlcyA9PSAwKQorCQkJ cmVzID0gd3JpdGVfbG9uZyhjaGlsZCwgYWRkciwgQlJFQUtJTlNUKTsKKwor CQlpZiAocmVzID09IDApIHsKKwkJCWRiZy0+YnBbbnJdLmFkZHJlc3MgPSBh ZGRyOworCQkJZGJnLT5uc2F2ZWQgKz0gMTsKKwkJfQorCX0gZWxzZQorCQlw cmludGsoS0VSTl9ERUJVRyAiYWRkX2JyZWFrcG9pbnQ6IHRvbyBtYW55IGJy ZWFrcG9pbnRzXG4iKTsKKwogCQkJcmV0dXJuIHJlczsKIAkJfQorCisjZGVm aW5lIHByZWRpY2F0ZSh4KQkoeCAmIDB4ZjAwMDAwMDApCisKK2ludCBwdHJh Y2Vfc2V0X2JwdCAoc3RydWN0IHRhc2tfc3RydWN0ICpjaGlsZCkKK3sKKwlz dHJ1Y3QgZGVidWdfaW5mbyAqZGJnID0gJmNoaWxkLT50c3MuZGVidWc7CisJ dW5zaWduZWQgbG9uZyBpbnNuLCBwYywgYWx0OworCWludCByZXM7CisKKwlw YyA9IHBjX3BvaW50ZXIgKGdldF9zdGFja19sb25nIChjaGlsZCwgMTUvKlJF R19QQyovKSk7CisKKwlyZXMgPSByZWFkX2xvbmcoY2hpbGQsIHBjLCAmaW5z bik7CisJaWYgKHJlcyA+PSAwKSB7CisJCXJlcyA9IDA7CisKKwkJZGJnLT5u c2F2ZWQgPSAwOworCisJCWFsdCA9IGdldF9icmFuY2hfYWRkcmVzcyhjaGls ZCwgcGMsIGluc24pOworCQlpZiAoYWx0KQorCQkJcmVzID0gYWRkX2JyZWFr cG9pbnQoY2hpbGQsIGRiZywgYWx0KTsKKworCQlpZiAoIXJlcyAmJiAoIWFs dCB8fCAocHJlZGljYXRlKGluc24pICE9IDB4ZTAwMDAwMDApKSkKKwkJCXJl cyA9IGFkZF9icmVha3BvaW50KGNoaWxkLCBkYmcsIHBjICsgNCk7CiAJfQot CWNoaWxkLT50c3MuZGVidWdbNF0gPSBuc2F2ZWQ7Ci0JcmV0dXJuIDA7CisK KwlyZXR1cm4gcmVzOwogfQogCi0vKiBFbnN1cmUgbm8gc2luZ2xlLXN0ZXAg YnJlYWtwb2ludCBpcyBwZW5kaW5nLiAgUmV0dXJucyBub24temVybwotICog dmFsdWUgaWYgY2hpbGQgd2FzIGJlaW5nIHNpbmdsZS1zdGVwcGVkLgorLyog RW5zdXJlIG5vIHNpbmdsZS1zdGVwIGJyZWFrcG9pbnQgaXMgcGVuZGluZy4K ICAqLwotaW50IHB0cmFjZV9jYW5jZWxfYnB0IChzdHJ1Y3QgdGFza19zdHJ1 Y3QgKmNoaWxkKQordm9pZCBwdHJhY2VfZG9fY2FuY2VsX2JwdCAoc3RydWN0 IHRhc2tfc3RydWN0ICpjaGlsZCkKIHsKLQlpbnQgaSwgbnNhdmVkID0gY2hp bGQtPnRzcy5kZWJ1Z1s0XTsKKwlzdHJ1Y3QgZGVidWdfaW5mbyAqZGJnID0g JmNoaWxkLT50c3MuZGVidWc7CisJdW5zaWduZWQgbG9uZyB0bXA7CisJaW50 IGksIG5zYXZlZCA9IGRiZy0+bnNhdmVkOwogCi0JY2hpbGQtPnRzcy5kZWJ1 Z1s0XSA9IDA7CisJZGJnLT5uc2F2ZWQgPSAwOwogCiAJaWYgKG5zYXZlZCA+ IDIpIHsKIAkJcHJpbnRrICgicHRyYWNlX2NhbmNlbF9icHQ6IGJvZ3VzIG5z YXZlZDogJWQhXG4iLCBuc2F2ZWQpOwogCQluc2F2ZWQgPSAyOwogCX0KLQlm b3IgKGkgPSAwOyBpIDwgbnNhdmVkOyBpKyspCi0JCXdyaXRlX2xvbmcgKGNo aWxkLCBjaGlsZC0+dHNzLmRlYnVnW2ldLCBjaGlsZC0+dHNzLmRlYnVnW2kg KyAyXSk7Ci0JcmV0dXJuIG5zYXZlZCAhPSAwOworCisJZm9yIChpID0gMDsg aSA8IG5zYXZlZDsgaSsrKSB7CisJCXJlYWRfbG9uZyhjaGlsZCwgZGJnLT5i cFtpXS5hZGRyZXNzLCAmdG1wKTsKKwkJaWYgKHRtcCAhPSBCUkVBS0lOU1Qp CisJCQlwcmludGsoS0VSTl9FUlIgInB0cmFjZV9jYW5jZWxfYnB0OiB3ZWly ZG5lc3NcbiIpOworCQl3cml0ZV9sb25nKGNoaWxkLCBkYmctPmJwW2ldLmFk ZHJlc3MsIGRiZy0+YnBbaV0uaW5zbik7CisJfQorfQorCisKK3N0YXRpYyBp bmxpbmUgaW50IAorcHRyYWNlX3F1ZXJ5X2JwdCAoc3RydWN0IHRhc2tfc3Ry dWN0ICpjaGlsZCkKK3sKKwlyZXR1cm4gKGNoaWxkLT50c3MuZGVidWcubnNh dmVkICE9IDApOworfQorCitpbnQKK3B0cmFjZV9jYW5jZWxfYnB0IChzdHJ1 Y3QgdGFza19zdHJ1Y3QgKmNoaWxkKQoreworCWludCByOworCWlmIChyID0g cHRyYWNlX3F1ZXJ5X2JwdCAoY2hpbGQpLCByID09IDApCisJCXJldHVybiAw OworCisJcHRyYWNlX2RvX2NhbmNlbF9icHQgKGNoaWxkKTsKKwlyZXR1cm4g cjsKIH0KIAogYXNtbGlua2FnZSBpbnQgc3lzX3B0cmFjZShsb25nIHJlcXVl c3QsIGxvbmcgcGlkLCBsb25nIGFkZHIsIGxvbmcgZGF0YSkKQEAgLTU4OSw2 ICs2MzcsNyBAQAogCQkgICAgKGN1cnJlbnQtPnVpZCAhPSBjaGlsZC0+dWlk KSB8fAogCSAJICAgIChjdXJyZW50LT5naWQgIT0gY2hpbGQtPmVnaWQpIHx8 CiAJIAkgICAgKGN1cnJlbnQtPmdpZCAhPSBjaGlsZC0+c2dpZCkgfHwKKwkJ ICAgICghY2FwX2lzc3Vic2V0KGNoaWxkLT5jYXBfcGVybWl0dGVkLCBjdXJy ZW50LT5jYXBfcGVybWl0dGVkKSkgfHwKIAkgCSAgICAoY3VycmVudC0+Z2lk ICE9IGNoaWxkLT5naWQpKSAmJiAhY2FwYWJsZShDQVBfU1lTX1BUUkFDRSkp CiAJCQlnb3RvIG91dDsKIAkJLyogdGhlIHNhbWUgcHJvY2VzcyBjYW5ub3Qg YmUgYXR0YWNoZWQgbWFueSB0aW1lcyAqLwpAQCAtNjIwLDcgKzY2OSw3IEBA CiAJCQl1bnNpZ25lZCBsb25nIHRtcDsKIAogCQkJcmV0ID0gcmVhZF9sb25n KGNoaWxkLCBhZGRyLCAmdG1wKTsKLQkJCWlmIChyZXQgPj0gMCkKKwkJCWlm ICghcmV0KQogCQkJCXJldCA9IHB1dF91c2VyKHRtcCwgKHVuc2lnbmVkIGxv bmcgKilkYXRhKTsKIAkJCWdvdG8gb3V0OwogCQl9CkBAIC02ODcsMTIgKzcz Niw1NCBAQAogCQkJcmV0ID0gLUVJTzsKIAkJCWlmICgodW5zaWduZWQgbG9u ZykgZGF0YSA+IF9OU0lHKQogCQkJCWdvdG8gb3V0OwotCQkJY2hpbGQtPnRz cy5kZWJ1Z1s0XSA9IC0xOworCQkJY2hpbGQtPnRzcy5kZWJ1Zy5uc2F2ZWQg PSAtMTsKIAkJCWNoaWxkLT5mbGFncyAmPSB+UEZfVFJBQ0VTWVM7CiAJCQl3 YWtlX3VwX3Byb2Nlc3MoY2hpbGQpOwogCQkJY2hpbGQtPmV4aXRfY29kZSA9 IGRhdGE7CiAJCQkvKiBnaXZlIGl0IGEgY2hhbmNlIHRvIHJ1bi4gKi8KIAkJ CXJldCA9IDA7CisJCQlnb3RvIG91dDsKKworCQljYXNlIFBUUkFDRV9HRVRS RUdTOgorCQl7CS8qIEdldCBhbGwgZ3AgcmVncyBmcm9tIHRoZSBjaGlsZC4g Ki8KKwkJCXVuc2lnbmVkIGNoYXIgKnN0YWNrOworCisJCQlyZXQgPSAwOwor CQkJc3RhY2sgPSAodW5zaWduZWQgY2hhciAqKSgodW5zaWduZWQgbG9uZylj aGlsZCArIDgxOTIgLSBzaXplb2Yoc3RydWN0IHB0X3JlZ3MpKTsKKwkJCWlm IChjb3B5X3RvX3VzZXIoKHZvaWQgKilkYXRhLCBzdGFjaywKKwkJCQkJIHNp emVvZihzdHJ1Y3QgcHRfcmVncykpKQorCQkJCXJldCA9IC1FRkFVTFQ7CisK KwkJCWdvdG8gb3V0OworCQl9OworCisJCWNhc2UgUFRSQUNFX1NFVFJFR1M6 CisJCXsKKwkJCS8qIFNldCBhbGwgZ3AgcmVncyBpbiB0aGUgY2hpbGQuICov CisJCQl1bnNpZ25lZCBjaGFyICpzdGFjazsKKworCQkJcmV0ID0gMDsKKwkJ CXN0YWNrID0gKHVuc2lnbmVkIGNoYXIgKikoKHVuc2lnbmVkIGxvbmcpY2hp bGQgKyA4MTkyIC0gc2l6ZW9mKHN0cnVjdCBwdF9yZWdzKSk7CisJCQlpZiAo Y29weV9mcm9tX3VzZXIoc3RhY2ssICh2b2lkICopZGF0YSwKKwkJCQkJICAg c2l6ZW9mKHN0cnVjdCBwdF9yZWdzKSkpCisJCQkJcmV0ID0gLUVGQVVMVDsK KwkJCWdvdG8gb3V0OworCQkgIH07CisKKwkJY2FzZSBQVFJBQ0VfR0VURlBS RUdTOiAKKwkJCS8qIEdldCB0aGUgY2hpbGQgRlBVIHN0YXRlLiAqLworCQkJ cmV0ID0gMDsKKwkJCWlmIChjb3B5X3RvX3VzZXIoKHZvaWQgKilkYXRhLCAm Y2hpbGQtPnRzcy5mcHN0YXRlLAorCQkJCQkgc2l6ZW9mKHN0cnVjdCB1c2Vy X2ZwKSkpCisJCQkJcmV0ID0gLUVGQVVMVDsKKwkJCWdvdG8gb3V0OworCQkK KwkJY2FzZSBQVFJBQ0VfU0VURlBSRUdTOgorCQkJLyogU2V0IHRoZSBjaGls ZCBGUFUgc3RhdGUuICovCisJCQlyZXQgPSAwOworCQkJaWYgKGNvcHlfZnJv bV91c2VyKCZjaGlsZC0+dHNzLmZwc3RhdGUsICh2b2lkICopZGF0YSwKKwkJ CQkJICAgc2l6ZW9mKHN0cnVjdCB1c2VyX2ZwKSkpCisJCQkJcmV0ID0gLUVG QVVMVDsKIAkJCWdvdG8gb3V0OwogCiAJCWNhc2UgUFRSQUNFX0RFVEFDSDoJ CQkJLyogZGV0YWNoIGEgcHJvY2VzcyB0aGF0IHdhcyBhdHRhY2hlZC4gKi8K LS0tIC9za2lmZi9qYW1leS9saW51eC0yLjIuMTQtcm1rMy1jcmwxL2FyY2gv YXJtL2tlcm5lbC9wcm9jZXNzLmMJVHVlIEphbiAxOCAxODowNjozMiAyMDAw CisrKyAvdXNyL3NyYy9saW51eC9hcmNoL2FybS9rZXJuZWwvcHJvY2Vzcy5j CVR1ZSBKYW4gMjUgMDI6MzM6NDYgMjAwMApAQCAtMjA4LDEwICsyMDgsOCBA QAogCiB2b2lkIGZsdXNoX3RocmVhZCh2b2lkKQogewotCWludCBpOwotCi0J Zm9yIChpID0gMDsgaSA8IE5SX0RFQlVHUzsgaSsrKQotCQljdXJyZW50LT50 c3MuZGVidWdbaV0gPSAwOworCW1lbXNldCgmY3VycmVudC0+dHNzLmRlYnVn LCAwLCBzaXplb2YoY3VycmVudC0+dHNzLmRlYnVnKSk7CisJbWVtc2V0KCZj dXJyZW50LT50c3MuZnBzdGF0ZSwgMCwgc2l6ZW9mKGN1cnJlbnQtPnRzcy5m cHN0YXRlKSk7CiAJY3VycmVudC0+dXNlZF9tYXRoID0gMDsKIAljdXJyZW50 LT5mbGFncyAmPSB+UEZfVVNFREZQVTsKIH0KQEAgLTI1Niw3ICsyNTQsNiBA QAogICovCiB2b2lkIGR1bXBfdGhyZWFkKHN0cnVjdCBwdF9yZWdzICogcmVn cywgc3RydWN0IHVzZXIgKiBkdW1wKQogewotCWludCBpOwogCiAJZHVtcC0+ bWFnaWMgPSBDTUFHSUM7CiAJZHVtcC0+c3RhcnRfY29kZSA9IGN1cnJlbnQt Pm1tLT5zdGFydF9jb2RlOwpAQCAtMjY2LDggKzI2MywxMSBAQAogCWR1bXAt PnVfZHNpemUgPSAoY3VycmVudC0+bW0tPmJyayAtIGN1cnJlbnQtPm1tLT5z dGFydF9kYXRhICsgUEFHRV9TSVpFIC0gMSkgPj4gUEFHRV9TSElGVDsKIAlk dW1wLT51X3NzaXplID0gMDsKIAotCWZvciAoaSA9IDA7IGkgPCBOUl9ERUJV R1M7IGkrKykKLQkJZHVtcC0+dV9kZWJ1Z3JlZ1tpXSA9IGN1cnJlbnQtPnRz cy5kZWJ1Z1tpXTsgIAorCWR1bXAtPnVfZGVidWdyZWdbMF0gPSBjdXJyZW50 LT50c3MuZGVidWcuYnBbMF0uYWRkcmVzczsKKwlkdW1wLT51X2RlYnVncmVn WzFdID0gY3VycmVudC0+dHNzLmRlYnVnLmJwWzFdLmFkZHJlc3M7CisJZHVt cC0+dV9kZWJ1Z3JlZ1syXSA9IGN1cnJlbnQtPnRzcy5kZWJ1Zy5icFswXS5p bnNuOworCWR1bXAtPnVfZGVidWdyZWdbM10gPSBjdXJyZW50LT50c3MuZGVi dWcuYnBbMV0uaW5zbjsKKwlkdW1wLT51X2RlYnVncmVnWzRdID0gY3VycmVu dC0+dHNzLmRlYnVnLm5zYXZlZDsKIAogCWlmIChkdW1wLT5zdGFydF9zdGFj ayA8IDB4MDQwMDAwMDApCiAJCWR1bXAtPnVfc3NpemUgPSAoMHgwNDAwMDAw MCAtIGR1bXAtPnN0YXJ0X3N0YWNrKSA+PiBQQUdFX1NISUZUOwo= ------------=_1583534244-23286-7-- >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: ac131313@cygnus.com Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com Subject: Re: Dependence on config.status Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003050737.CAA10121@indy.delorie.com> References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com> <200003021007.FAA04124@indy.delorie.com> <38C0ACF2.C00719B0@cygnus.com> X-SW-Source: 2000-q1/msg00541.html Content-length: 509 > Eli Zaretskii wrote: > > > > > Well, if memory serves, if you re-ran configure in such a way that > > > tm.h started linking to a different file, then the config.status > > > dependency was the only way to force a rebuild. > > > > How about adding some #define to config.h that would also change when > > this happens? > > Such as the names of the tm, xm and nm files? Yes, that's what I had in mind. Since the configure scripts already knows the names of those files, it could put them into config.h. >From tromey@cygnus.com Sat Apr 01 00:00:00 2000 From: Tom Tromey To: gdb@sourceware.cygnus.com Subject: Re: INSTALL set incorrectly in gdb/doc/Makefile Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <87og88rxaf.fsf@cygnus.com> References: <200002270838.DAA25037@indy.delorie.com> <38BCDC1C.2917C1D6@cygnus.com> <200003211816.NAA12426@indy.delorie.com> X-SW-Source: 2000-q1/msg00761.html Content-length: 323 >>>>> "Eli" == Eli Zaretskii writes: Eli> How would people suggest to go about trying to solve this problem? It Eli> looks like some Autoconf problem. Where would be a good place to ask Eli> about this? I didn't follow this thread, but autoconf questions should go to autoconf@gnu.org. Tom >From hjl@valinux.com Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: GDB Subject: Problems with hardware watchpoint on ia32. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000307132401.A20282@valinux.com> X-SW-Source: 2000-q1/msg00564.html Content-length: 4090 I don't like the hardware watchpoint support on ia32. That is one reason I started hacking gdb. Here are some examples: # cat y.c int a1; int a2; int a3; int a4; int a5; int a6; main () { a1 = 11; a2 = 12; a3 = 13; a4 = 14; a5 = 15; a6 = 16; return 0; } # gcc -g -o y y.c # /work/build/gnu/bin/gdb.orig/gdb/gdb y (gdb) watch a1 Hardware watchpoint 1: a1 (gdb) watch a2 Hardware watchpoint 2: a2 (gdb) watch a3 Hardware watchpoint 3: a3 (gdb) watch a4 Hardware watchpoint 4: a4 (gdb) watch a5 Hardware watchpoint 5: a5 (gdb) r Starting program: /home/hjl/bugs/gdb/hw/y warning: Could not insert hardware watchpoint 5. ptrace: Unknown error 4294967295. Cannot insert breakpoints. The same program may be running in another process. (gdb) del 5 (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/hjl/bugs/gdb/hw/y warning: Could not insert hardware watchpoint 1. warning: Could not insert hardware watchpoint 3. ptrace: Unknown error 4294967295. Cannot insert breakpoints. The same program may be running in another process. (gdb) ia32 only has 4 hardware debug registers. But gdb shouldn't crash. Even worse, after deleted one hardware watchpoint, gdb still refused to work. One more annoying thing: # cat ll.c unsigned long long a1 = 0; double a2 = 0; main () { a1 = 0x00000000ffffffffL; a2 = 12; a1 = 0xffffffff00000000L; return 0; } # gcc -g -o ll ll.c # /work/build/gnu/bin/gdb.orig/gdb/gdb ll (gdb) watch a1 Watchpoint 1: a1 (gdb) watch a2 Watchpoint 2: a2 (gdb) gdb won't set hardware watchpoints on long long nor double. I put some kludegs in gdb 4.17. They work for me the way I prefer. F r the first one, I got # /work/build/gnu/bin/gdb/gdb/gdb y (gdb) watch a1 Hardware watchpoint 1: a1 (gdb) watch a2 Hardware watchpoint 2: a2 (gdb) watch a3 Hardware watchpoint 3: a3 (gdb) watch a4 Hardware watchpoint 4: a4 (gdb) watch a5 Hardware watchpoint 5: a5 (gdb) r Starting program: /home/hjl/bugs/gdb/hw/y warning: Could not insert hardware watchpoint 5. warning: Could not insert hardware watchpoint 5. Hardware watchpoint 1: a1 Hardware watchpoint 2: a2 Hardware watchpoint 3: a3 Hardware watchpoint 4: a4 Hardware watchpoint 5: a5 Hardware watchpoint 1: a1 Hardware watchpoint 2: a2 Hardware watchpoint 3: a3 Hardware watchpoint 4: a4 Hardware watchpoint 5: a5 warning: Could not insert hardware watchpoint 5. warning: Could not insert hardware watchpoint 5. Hardware watchpoint 1: a1 Hardware watchpoint 2: a2 Hardware watchpoint 3: a3 Hardware watchpoint 4: a4 Hardware watchpoint 5: a5 warning: Could not insert hardware watchpoint 5. Hardware watchpoint 1: a1 Old value = 0 New value = 11 main () at y.c:12 12 a2 = 12; (gdb) del 1 (gdb) del 1 (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/hjl/bugs/gdb/hw/y Hardware watchpoint 2: a2 Hardware watchpoint 3: a3 Hardware watchpoint 4: a4 Hardware watchpoint 5: a5 Hardware watchpoint 2: a2 Hardware watchpoint 3: a3 Hardware watchpoint 4: a4 Hardware watchpoint 5: a5 Hardware watchpoint 2: a2 Hardware watchpoint 3: a3 Hardware watchpoint 4: a4 Hardware watchpoint 5: a5 Hardware watchpoint 2: a2 Old value = 0 New value = 12 main () at y.c:13 13 a3 = 13; (gdb) For the second one, # /work/build/gnu/bin/gdb/gdb/gdb ll (gdb) watch a1 Hardware watchpoint 1: a1 (gdb) watch a2 Hardware watchpoint 2: a2 (gdb) r Starting program: /home/hjl/bugs/gdb/hw/ll Hardware watchpoint 1: a1 Hardware watchpoint 2: a2 Hardware watchpoint 1: a1 Hardware watchpoint 2: a2 Hardware watchpoint 1: a1 Hardware watchpoint 2: a2 Hardware watchpoint 1: a1 Old value = 0 New value = 4294967295 0x80483d3 in main () at ll.c:7 7 a1 = 0x00000000ffffffffL; (gdb) c Continuing. Hardware watchpoint 2: a2 Old value = 0 New value = 12 main () at ll.c:9 9 a1 = 0xffffffff00000000L; I know the support for long long and double is not perfect. But I much prefer it than none at all. I will send in a patch in another email. H.J. >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Discussion Subject: [Fwd: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release] Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <389ECBAF.66013B07@cygnus.com> X-SW-Source: 2000-q1/msg00120.html Content-length: 2738 To : GDB Testers Subject : Preparing for the GDB 5.0 / GDB 2000 / GDB2k release >From : Andrew Cagney Date : Tue, 08 Feb 2000 00:26:45 +1100 Newsgroups : cygnus.testers.gdb Organization : Cygnus Solutions Xref : cygnus.com cygnus.testers.gdb:212 [Please follow up to the general GDB mailing list] Hello, Given it is now almost a year since the last release of GDB (4.18) and given also the number of significant internal changes made since that release (event-loop, multi-arch, ui-out, ISO-C, obsolete code, ...), it is now time to start anew the process of releasing a major version of GDB - GDB 5.0. As this release is being conducted entirely from the (new!) public CVS repository I'm hoping that a more aggressive release schedule can be achieved. With that in mind, I've tentatively planned: two weeks of patch resolution; the cutting of the 5.0 branch (2000-02-21?); one week of last minute checks; and then the 5.0 release (29/2 2000-02-29?). (Everyone is free to roll on the floor laughing at this point :-) So, as Jason Molenda aptly wrote way back in '98: > If you have patches that are ready to go in, but have not yet been > submitted, please send them in now. If you don't have your FSF copyright > assignment paperwork submitted and on-file at the FSF, we probably won't > have time to get significant contributions in for this release. > > If you sent in a patch, but have not heard anything and the patch is not > in the latest snapshot [snip], > please send it in again. We have a backlog of patches which have not > yet been evaluated, so we'll be going over those for the next few days. > I'd rather have two copies of a patch than zero copies, so don't be shy. It would be good to see this GDB release running on *Linux, *BSD and cygwin as well as plenty of the more traditional UNIX platforms. For your reference, general GDB information can be found at: http://sourceware.cygnus.com/gdb/ while a pre- checked-out CVS source tree containing both GDB and DEJAGNU can be found at: ftp://sourceware.cygnus.com/pub/gdb/snapshots/gdb-dejagnu-pserver-2000-02-06.tar.bz2 Alternativly, the separate components: ftp://sourceware.cygnus.com/pub/gdb/snapshots/dejagnu-pserver-2000-02-06.tar.bz2 ftp://sourceware.cygnus.com/pub/gdb/snapshots/gdb-pserver-2000-02-06.tar.bz2 are also available. You will need to build (install) dejagnu before running the GDB testsuite. Finally, the GDB 5.1 release process is scheduled to start before July '00 (if not much sooner!). If you have a major new port or contribution then perhaphs 5.1 is the release you should be shooting for. enjoy, Andrew -- Andrew Cagney (Red Hat) GDB >From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: memory region attribute CLI Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5mhfe0kvpm.fsf@jtc.redbacknetworks.com> References: <5mr9dd5dlt.fsf@jtc.redbacknetworks.com> <200003160944.EAA01842@indy.delorie.com> <5mem9avs45.fsf@jtc.redbacknetworks.com> <5m3dplwjri.fsf@jtc.redbacknetworks.com> <200003211819.NAA12438@indy.delorie.com> X-SW-Source: 2000-q1/msg00762.html Content-length: 600 >>>>> "Eli" == Eli Zaretskii writes: Eli> I think this is a very useful idea. But as far as I understand, the Eli> information managed by the code you posted needs to be consulted by Eli> other GDB commands, right? I don't see any code that does that yet. Correct. I just started on the code that actually looks up and acts on memory region attributes yesterday. I sent messages with the CLI description and later the CLI code to get feedback on those parts, as well as feedback on the general concept of region attributes. --jtc -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com, DJ Delorie Subject: Re: 000217: status of DJGPP support Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B092B7.73CDF9B6@cygnus.com> References: <200002201017.FAA12081@indy.delorie.com> X-SW-Source: 2000-q1/msg00357.html Content-length: 2418 Eli Zaretskii wrote: > > I fetched the 000217 snapshot yesterday and tried to build it with > DJGPP. I had only limited success: after some tweaking, everything > compiled, but linker complains about undefined references to several > functions. In general, the DJGPP native support should be currently > considered broken in several ways; I'm working on repairing it. > > Here are some specific comments/questions: > > - There are lots of warnings about comparison of signed with > unsigned and unused arguments. I find it hard to believe that > this is specific to DJGPP: doesn't anyone else see these warnings? > No doubt they are due to -Wall, but I understand we want to go > into production with these switches, right? Not for 5.0. The only warnings I consider significant for 5.0 are those from: ,-Wimplicit\ ,-Wreturn-type\ ,-Wcomment\ ,-Wtrigraphs\ ,-Wformat\ ,-Wparentheses\ ,-Wpointer-arith\ ,-Woverloaded-virtual\ even then, there are going to be platforms that can't be compiled if these flags are specified. Sorry. > - The configure scripts cannot be run without some tricks, like > setting a few variables in the environment. So I'm thinking about > adding a gdb/djgpp subdirectory with a special script that DJGPP > users will need to run (and which in turn will run the top-level > configure), and maybe a few small Sed scripts to fix file-name > related problems on 8+3 filesystems. Is this acceptable? Well, there is currently: gdb/mpw-make.sed and gdb/config/mpw/* I'd suggest: gdb/config/djgpp/* Comments? Stan? > - What is the policy for fixing problems in the directories taken > from Binutils? I'd imagine you want me to send patches to > Binutils maintainers, but with the next Binutils release nowhere > in sight, and some of my patches to Binutils in the queue since > August, is this really practical? How can I make sure these > problems are fixed in GDB before GDB 5.0 is released? GDB 5.0 shares the bfd, include, and a few other directories with BINUTILS. This means that once a patch is approved for BINUTILS, GDB gets it immediatly - the problem of new release has been eliminated. Unfortunatly, this also means that if BINUTILS pushes back on a patch, GDB can't accept it :-( How to solve the situtation you're in? Off hand, I don't know - what exactly is the status of those patches? Andrew >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Quality Quorum Cc: gdb@sourceware.cygnus.com, Leon Pollak Subject: Re: gdb remote protocol, winnt, wigglers Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <3872E2E2.8E713C7F@cygnus.com> References: X-SW-Source: 2000-q1/msg00006.html Content-length: 4779 [List pruned a little :-)] Quality Quorum wrote: > Hi, > > I am working on implmenting standard compliant remote.c and gdbserver. > I found just a few problems with protocol specs so far. > > 1. There is no need in 'isThreadAlive' request: remote.c has to maintain > local cache of available threads, which is updated by 'threadListQuery' > if required (I tried a few variants implementing thread list > synchronization and it seems this one is the most rational). > > Target methods xxx_is_thread_alive and xxxxx_find_new_thread > are simply using this cache without generating any traffic > on the wire. > > So. 'itThreadAlive' is depreciated. > > 2. I misread code implementing 'addBWPoint' and 'deleteBWPpoint', > so the description was incorrec, it is fixed now. > > I put updated document at http://www.std.com/qqi/ftp/protocol.txt . > > I put updated rproxy at http://www.std.com/qqi/labslave/rproxy.html . > > It is now running on WinNT and sipports Wiggler among other things - > I tried it with MPC860ADS. It will be not too complicated to add > other processors, however, I do have 68360 based board only and no > other wigglers. I have ICD cable which I am using under linux, > I am planning to provide a target under linux using ICD cable to 68360. > > Please, be forgiving: WinNT stuff is barely in alpha state, rest is > barely in beta. > > I have nagging outstanding problem: I do not know what paperwork and > what changes in the files I have to make in order to turn it over > to FSF. I signed and submitted the most appropriate paper I found on > gnu website, however, I did not hear from them yet and it seems to me > that it will not be enough. > > Can any kind soul help me with this ? Just FYI, there are several things that we're going to need to keep in mind if this is to go forward. As a general comment, its good to at least see someone with the energy to pursue the gdbserver/stub code so that there is a generic (and correct!) stub reference implementation available. The fact that you're hammering the external side is (as they say in the USofA) cool. When it comes to things like the remote protocol spec and remote.c, you might need to take a little care and think about what you want to do with the work in the longer term. To that end, I've some notes on both remote.c and the spec below. [[As an aside, I'm away for much of January, because of that and because you appearing to be moving at a rapid rate of knots, I'm going to try to be fairly to the point with the problems we're going to encounter. That way, I'm hopefully avoiding the possibility of you doing much significant work that, unfortunately, ends up in limbo.]] Andrew Spec: The current ``official'' protocol spec is in the GDB user guide. (As an aside, it wasn't put in the internals manual as it was documenting an external interface.) Rather than end up with two possibly conflicting definitions, its obviously going to be better if there was only one definition of the protocol. To that end, you many want to first think about how to re-structure (before re-wording) the protocol spec. Should it go into a separate chapter or as an appendix / attatchment? It's actually Stan Shebs decision (as the doco maintainer). With the higher level stuff out the way, it will become possible, through a series of patches, to evolve the current spec into something better. FWIW, I'm strongly against simply replacing the existing spec with a new one. I'd like to be able to see (using CVS diff) what was changed at each point so that any problems/issues can be traced down and then fixed. remote.c: Beware, remote.c's underlying architecture is in a state of flux. Of the possible targets to async first remote was selected as it wasn't going to affect native targets and was entirely self contained (also it didn't involve signals or ptrace). It turned out that it had some of the more complex interactions but that is another story. :-) The consequence is that remote.c currently contains two remote targets: remote / extended-remote and async / extended-async. Once all the async issues are resolved, the old code will be given the flick. If you've been looking through remote.c you'll have noticed the FIXME's I've added as place holders while other async code is finished. If you're looking to re-do remote.c you'll need to keep in mind that file is going to continue to receive major changes and those changes will, unfortunately, take priority over anything else (sigh). If you're able to submit small and distinct patches then there is a really high likelihood of your work being accepted quickly and that will allow the work to keep reasonably in sync with the mainline code. Take care, Andrew >From Guenther.Grau@marconicomms.com Sat Apr 01 00:00:00 2000 From: Guenther Grau To: gdb@sourceware.cygnus.com Subject: Re: A patch for gnu-regex Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C7C369.97CF2A7F@marconicomms.com> References: <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local> <5m4saivyew.fsf@jtc.redbacknetworks.com> <38C7B8BD.26C0E220@cygnus.com> X-SW-Source: 2000-q1/msg00651.html Content-length: 714 Andrew Cagney wrote: > [...] > > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00562.html > > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00566.html > > This patch is definitly much better than the original. > > Unfortunatly, I don't think that selecting a pre-installed regexp should > be the default. My rationale (As Mark? noted) is that ensuring that a > GDB release provides consistent behavour between systems (1) is more > important than having it select the latest/greatest random regexp. I support this (not that it matters :-). If H.J. Lu wants it on Linux, he can ./configure --with-libc-regex or --with-native-regex, but the default should be the regex within gdb. Guenther >From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: Elena Zannoni Cc: "Peter.Schauer" , Mark Kettenis , gdb@sourceware.cygnus.com Subject: Re: Testsuite regression Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DFF635.A64D0CC8@apple.com> References: <200003261706.e2QH6Yn08493@delius.kettenis.local> <200003261941.VAA32661@reisser.regent.e-technik.tu-muenchen.de> <14559.39965.642134.260490@kwikemart.cygnus.com> X-SW-Source: 2000-q1/msg00822.html Content-length: 301 Elena Zannoni wrote: > > I tested your fix on solaris and linux, it seems to work fine. I have > committed it. (Sorry, I know I shouldn't have done it w/o official > approval from Stan). No, that's cool. To quote from the GCC pages, "We don't want to get overly anal about checkin policies". Stan >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: msnyder@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: lin-thread cannot handle thread exit Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003031635.e23GZwi00372@delius.kettenis.local> X-SW-Source: 2000-q1/msg00525.html Content-length: 1394 Hi Michael, The thread_db assisted debugging code doesn't handle exiting threads properly, at least in combination with glibc 2.1.3. There are at least two problems that prevent this from working: 1. In lin-thread.c:enable_thread_event_reporting(), GDB requests TD_DEATH events to be reported, and sets a breakpoint at the appropriate location. The problem is that the LinuxThreads implementation included with glibc 2.1.3 triggers that breakpoint after it has flagged the thread as terminated. As a conseuqence when GDB tries to fetch the registers for that thread it doesn't succeed, and GDB complains about a breakpoint at location 0x0 that it doesn't know of. 2. If I disable the reporting of TD_DEATH events, things still don't work. The problem is that when the thread really exits, a TARGET_WAITKIND_EXITED event is reported to GDB in. So the answer to the question ``Can I get this event mistakenly from a thread?'' in lin-thread.c:thread_db_wait() is ``Yes''. Since the TARGET_WAITKIND_EXITED event is passed on to other code in GDB, GDB thinks that the entire process has died. Ignoring those "spurious" TARGET_WAITKIND_EXITED events doesn't help since some parts of GDB still think that the thread is still alive then. Looking through the code, it seems that there quite a few "loose ends". Is this still "work in progress"? Mark