From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: jimb@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: ST(i) and MMj Date: Wed, 01 Dec 1999 00:21:00 -0000 Message-id: <199912010821.DAA27130@mescaline.gnu.org> References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <199911231303.IAA01523@mescaline.gnu.org> <199911251715.MAA09225@mescaline.gnu.org> X-SW-Source: 1999-q4/msg00384.html (Note that I changed the subject: "none" seems inappropriate ;-) > If a symbol's address class (`aclass') is LOC_REGISTER and its value > is N, then GDB assumes the variable's value occupies register N. It > uses REGISTER_BYTE(N), REGISTER_RAW_SIZE(N), etc. to access that > symbol's value. We could arrange for REGISTER_RAW_SIZE and REGISTER_BYTE to perform the required mapping between %st(i) and %mmj using the current TOS. > We can't assign distinct register numbers to %st(0) and %mm0, for > reasons discussed previously: GDB can't cope with two distinct > register numbers referring to the same bits in the register file. During that discussion I did agree that these registers should not be treated as separate, but it seems we meant different things. What I meant was that it is a Bad Idea to maintain separate data for each one of these sets. In other words, if %st(3) corresponds to %mm0, it is wrong to have GDB maintain a separate data buffer where the contents of each one of these registers is held. The reason for this is that it would be very hard to teach GDB and the platform-specific code which data to use in each case, especially when the user changes the values in these registers and you need to pass the changed values to the debuggee. But I don't see why cannot GDB _think_ about %st(X) and %mmY as being separate registers while in reality they share the same data, if this sharing is concealed behind REGISTER_BYTE and REGISTER_RAW_SIZE (and possibly other functions/macros used to manipulate registers). What are the specific problems with this scheme? >From ac131313@cygnus.com Wed Dec 01 00:39:00 1999 From: Andrew Cagney To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: memory verify Date: Wed, 01 Dec 1999 00:39:00 -0000 Message-id: <3844DE71.32797799@cygnus.com> References: <5memd74iem.fsf@jtc.redbacknetworks.com> <384478F8.B079BDC2@cygnus.com> <5maenv4ehr.fsf@jtc.redbacknetworks.com> <38449CE7.26320160@cygnus.com> <5maenvcfqd.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00385.html Content-length: 1542 "J.T. Conklin" wrote: > > >>>>> "Andrew" == Andrew Cagney writes: > >> But is there a reason for higher level code to care how the compare > >> is implemented? We could have target_XXX_memory check > >> current_target-> to_XXX_memory --- if it's NULL, call that function > >> otherwise a generic implementation would be used. > > Andrew> Typically, yes. I can think of two cases: > Andrew> > Andrew> o a weak/broken CRC algorithm > Andrew> which the user doesn't like. > Andrew> > Andrew> o Internal operations such as > Andrew> program download that would exploit the CRC > Andrew> when available. (ex program load could run > Andrew> the crc before downloading each section. This > Andrew> could cleanup the compare sections command.). > > I don't think the existance of a to_XXX_memory() vector function is > enough of a hint for upper layers of GDB to decide whether to use it. > For example, changing generic_load() to call to_XXX_memory() on each > section to determine whether it is already loaded makes a lot of sense > with targets with CRC-like verification. Those that implement it with > a 'srecord verify'-like mechanism would lose (some ROM monitors have a > command where a srecord stream is compared with the contents of memory > instead of replacing the contents). But perhaps this is an argument > against using that kind of implementation. Thoughts? Bleuk :-) That suggests one requirement on that method is that it be significantly faster than a simple memory read :-) Andrew >From ac131313@cygnus.com Wed Dec 01 00:57:00 1999 From: Andrew Cagney To: "Brown, Rodney" Cc: "'gdb@sourceware.cygnus.com'" Subject: Re: memory verify Date: Wed, 01 Dec 1999 00:57:00 -0000 Message-id: <3844E2C4.85B7A492@cygnus.com> References: <9150F3E779F0D211BD370008C733141C38AA12@aus-msg-02.au.pmsc.com> X-SW-Source: 1999-q4/msg00386.html Content-length: 1387 > "Brown, Rodney" wrote: > > Depending how capable the stubs are, you could look at using Andrew > Tridgewell's > rsync algorithms. I think that uses CRCs to locate differences in > files on > different boxes to generate a delta file to update the file on one. > This could allow the first difference idiom when run over large memory > areas, > without having to transmit the area over the wire. Yes, I've had that in the back of my mind. Several aspects of a typical embedded target make it less general then one would hope: o the typical target has a weak CRC (This suggests that perhaphs the check should have a requirement that it be ``strong''. How strong is an interesting question. o rcync's performance depends heavily on the stream nature of its remote connection. The typical target uses an RPC like mechanism. GDB's remote protocol is especially bad. The overhead of requesting CRC's could quickly mitigate any savings in avoiding downloads. o remote targets are small and dumb with all the the inteligence (?) and memory living in GDB. Having said that, an embedded implementation of rsync would make for an interesting performance boost when it came to re-loading memory. It would definitly be a challenge to add an rsync session (it would be a complex interaction than a simple exchange of packets) to GDB's remote protocol. enjoy, Andrew >From ac131313@cygnus.com Wed Dec 01 01:55:00 1999 From: Andrew Cagney To: David Golombek Cc: gdb@sourceware.cygnus.com Subject: Re: Writing a new simulator Date: Wed, 01 Dec 1999 01:55:00 -0000 Message-id: <3844F02D.EEFFEE84@cygnus.com> References: <21vh6lj9mo.fsf@seattle143.maker.com> X-SW-Source: 1999-q4/msg00387.html Content-length: 2336 David Golombek wrote: > > I'm examining using the simulator code packaged with GDB for the basis > of a new simulator project. I haven't seen much discussion here about > the simulator packages, but haven't seen any other lists that might be > appropriate. If there is another list, please direct me towards it. > I've read through a fair bit of the existing code, and wanted to ask > some questions to make sure my assumptions are correct. > > This work is for a new processor, to which I've already ported the > Binutils, GDB, and Gas. This is for a 32bit processor with a lot of > special functional units, which are memory mapped. > > 1) It seems that using either the mips or the v850 code as an example > it the best bet, using the same igen framework that they use. T/F? Yes (along with the tic80 and d30v). The more recent simulators have tended to use igen and (more importantly) the sim/common framework. Another alternative would be to write your own simulator generator and just exploit the common framework. > 2) Reading the igen source, as well as the code in 'common', is the > only existing documentation on igen. T/F? Unfortunatly also true. The main igen documentation is in its header files where it describes the syntax of each file. > 3) Is there a good "ramp-up" methodology for writing a simulator, or > do I need to write very large parts of it before its useful at all? > IE, are there some pieces that I can implement first to get at least a > simulator that will run, if not do anything, so that I can do > piecewise implementation? Yes. Doing something like copying an existing sim directory (v850? tic80?) and then chopping it back to nothing is a good strategy. Just be ruthless. Simulators like the v850 were originally built using a gencode program and now many years later still show some of that in their internals. > 4) Are there any mail archives or any discussion saved anywhere of the > previous simulator implementations? Just to give me a heads up on > potential pit-falls, etc., that i may run into. To be honest, outside of direct discussions with people I work with, you're the first person to ask! There is an old PSIM mailing list / web site ( http://sourceware.cygnus.com/psim/ however that doesn't cover any of the the more recent sim/ developemnt. enjoy, Andrew >From rok.papez@kiss.uni-lj.si Wed Dec 01 03:28:00 1999 From: Rok Papez To: gdb@sourceware.cygnus.com, gnu-gdb-bug@moderators.isc.org Subject: Insight 19991116, gdbserver, fork() - always follows parent Date: Wed, 01 Dec 1999 03:28:00 -0000 Message-id: <99120112265800.00878@Strader.home> X-SW-Source: 1999-q4/msg00388.html Content-length: 1361 Hi! -> Problem description: ----------------- Even if I explicitly set follow-fork-mode to child, insight still follows a parent. I've succesfully compiled "insight 19991116" but I have encountered the following problems: ----------------- (gdb) s daemonize () at httpdial.c:105 105 rc=fork(); (gdb) show follow-fork-mode Debugger response to a program call of fork or vfork is "child". (gdb) n Program received signal SIGSTOP, Stopped (signal). 0x804926f in daemonize () at httpdial.c:105 105 rc=fork(); (gdb) show follow-fork-mode Debugger response to a program call of fork or vfork is "child". (gdb) n 106 if (-1==rc) { (gdb) p rc $1 = 11730 ----------------- -> Platforms: --------- Target is a Linux 2.2.13 (RH 6.0): - gdbserver from insight-19991116 - debugging via TCP Workstation is a Linux 2.2.13 (RH 6.0): - running insight GUI (problem tested with insight -nw) -> Questions: ---------- 1.) Is the insight 19991116 version same as gdb 19991116 ? 2.) Can insight and/or gdb finally work with LinuxThreads? What about gdbserver? Do new threads block when they get created ? 3.) How can I make gdb/insight/gdbserver follow a fork() && exec() ?? 4.) Is it possible to compile into the programme a breakpoint (so when it is run I could attach to it) - if yes - how to make it work with gdbserver. -- best regards, Rok Papez. >From rodneybrown@pmsc.com Wed Dec 01 06:03:00 1999 From: "Brown, Rodney" To: "'Andrew Cagney'" , "Brown, Rodney" Cc: "'gdb@sourceware.cygnus.com'" Subject: RE: memory verify Date: Wed, 01 Dec 1999 06:03:00 -0000 Message-id: <9150F3E779F0D211BD370008C733141C38AA13@aus-msg-02.au.pmsc.com> X-SW-Source: 1999-q4/msg00389.html Content-length: 2874 Title: RE: memory verify The loop unrolled CRC-32 used in the info-zip tools (with a bit of extra optimization) is 259 bytes i386 text space - but needs a 4*256 byte array. Assuming that ultimate speed in CRC calculation isn't needed in the stub then a nibble at a time varient - without loop unrolling should be possible in < 259 bytes with a 4*16 = 64 byte array. It should be possible to provide a CRC-32 in < 300 bytes (i386), if that is strong enough. Having just had a quick look at rsync, an MD4 checksum is being used - a cryptographic digest isn't it? If the rolling rsync checksum calculation is small enough & you replaced the MD4 checksum with one or two 32-bit CRC calculations you'd be able to do almost as well as with the MD4 checksum - but without the anti-tampering guarantees. Note that adding another 32-bit CRC polynomial should only cost another 64 bytes of array or so. -----Original Message----- From: Andrew Cagney [ mailto:ac131313@cygnus.com ] Sent: Wednesday, 1 December 1999 19:57 To: Brown, Rodney Cc: 'gdb@sourceware.cygnus.com' Subject: Re: memory verify > "Brown, Rodney" wrote: > > Depending how capable the stubs are, you could look at using Andrew > Tridgewell's > rsync algorithms. I think that uses CRCs to locate differences in > files on > different boxes to generate a delta file to update the file on one. > This could allow the first difference idiom when run over large memory > areas, > without having to transmit the area over the wire. Yes, I've had that in the back of my mind.  Several aspects of a typical embedded target make it less general then one would hope:         o       the typical target has a weak CRC                 (This suggests that perhaphs the check should                 have a requirement that it be ``strong''.                 How strong is an interesting question.         o       rcync's performance depends heavily on the                 stream nature of its remote connection.                 The typical target uses an RPC like mechanism.                 GDB's remote protocol is especially bad.  The                 overhead of requesting CRC's could quickly                 mitigate any savings in avoiding downloads.         o       remote targets are small and dumb with all the                 the inteligence (?) and memory living in GDB. Having said that, an embedded implementation of rsync would make for an interesting performance boost when it came to re-loading memory.  It would definitly be a challenge to add an rsync session (it would be a complex interaction than a simple exchange of packets) to GDB's remote protocol.         enjoy,                 Andrew