From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Andrew Cagney Cc: GDB Discussion Subject: Re: [remote] Make registers network byteordered? Date: Tue, 05 Dec 2000 14:34:00 -0000 Message-id: References: <3A2C4305.6D9E53B3@cygnus.com> X-SW-Source: 2000-12/msg00025.html Andrew Cagney writes: > > Hello, > > At present the target sends back registers in target byte order format > vis: > > T0525:c4060280ffffffff;1d:c0ffff81ffffffff; > > I'd like to think about a tweek to this part of the protocol so that the > format: > > T0525=ffffffff80020664;1d=ffffffff81ffffc0; > > is accepted. The thing I can't figure out is now to also change the > [pP] packets so that GDB can correctly detect targets that support this > format when writing registers. > > General comments? What's the point? Simply that registers don't have an endianness? >From jtc@redback.com Tue Dec 05 15:24:00 2000 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: GDB Discussion Subject: Re: SOFTWARE_SINGLE_STEP_P and multi-arch Date: Tue, 05 Dec 2000 15:24:00 -0000 Message-id: <5mk89ezc2o.fsf@jtc.redback.com> References: <3A2C4141.B3C2F486@cygnus.com> X-SW-Source: 2000-12/msg00026.html Content-length: 1920 >>>>> "Andrew" == Andrew Cagney writes: Andrew> At present there are two macros that control software stepping: Andrew> Andrew> SOFTWARE_SINGLE_STEP_P() Andrew> Andrew> and SOFTWARE_SINGLE_STEP(sig, insert_or_remove) Andrew> Andrew> I'd like to suggest the following: Andrew> Andrew> Rename SOFTWARE_SINGLE_STEP_P() to TARGET_SOFTWARE_SINGLE_STEP_P() and Andrew> add it to the *target* vector. You're correct that hardware single step support is target dependent. For example, SOFTWARE_SINGLE_STEP_P is 1 on the sparc (and thus the embedded sparc varients like the sparclite and sparclet), but single step performance using the remote protocol would be greatly improved if the stub managed the step internally. While not strictly a hard- ware single step, it acts more or less the same. Perhaps the names SOFTWARE_SINGLE_STEP_P and SOFTWARE_SINGLE_STEP() should be changed to something more appropriate? I can't think of anything off hand. One concern I have is that it may not be known whether a target supports "hardware" single step until it is attempts one. Using the above examples of the sparclite and sparclet, older stubs won't have support for the step command packet. I can't think of a good way to determine ahead of time whether the packet is supported. GDB won't know whether it's OK to use it until it's too late. Perhaps this indicates we should be taking another approach. This is not completely thought out, feel free to shoot holes in it. The step function would be split out of target_resume() into a new vector function target_step(). GDB would unconditionally call target_step(), if it fails with an error code indicating that hardware single step is not available, it would call SOFTWARE_SINGLE_STEP() and then target_resume(). Looking at infrun.c:resume(), it looks like this wouldn't be a trivial exercise. --jtc -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Tue Dec 05 16:18:00 2000 From: Andrew Cagney To: "Frank Ch. Eigler" Cc: GDB Discussion Subject: Re: [remote] Make registers network byteordered? Date: Tue, 05 Dec 2000 16:18:00 -0000 Message-id: <3A2D8384.1D52812B@cygnus.com> References: <3A2C4305.6D9E53B3@cygnus.com> X-SW-Source: 2000-12/msg00027.html Content-length: 545 "Frank Ch. Eigler" wrote: > > Andrew Cagney writes: > > : [..] > : At present the target sends back registers in target byte order format > : vis: > : T0525:c4060280ffffffff;1d:c0ffff81ffffffff; > : I'd like to think about a [tweak] to this part of the protocol so that the > : format: > : T0525=ffffffff80020664;1d=ffffffff81ffffc0; > : is accepted. [...] > > How are gdb and the target supposed to pick the right scheme? Do you > imagine some sort of prior negotiation? The ``='' vs the ``:''. Andrew >From ac131313@cygnus.com Tue Dec 05 16:24:00 2000 From: Andrew Cagney To: Jim Blandy Cc: GDB Discussion Subject: Re: [remote] Make registers network byteordered? Date: Tue, 05 Dec 2000 16:24:00 -0000 Message-id: <3A2D84F3.48F372E@cygnus.com> References: <3A2C4305.6D9E53B3@cygnus.com> X-SW-Source: 2000-12/msg00028.html Content-length: 975 Jim Blandy wrote: > > Andrew Cagney writes: > > > > > Hello, > > > > At present the target sends back registers in target byte order format > > vis: > > > > T0525:c4060280ffffffff;1d:c0ffff81ffffffff; > > > > I'd like to think about a tweek to this part of the protocol so that the > > format: > > > > T0525=ffffffff80020664;1d=ffffffff81ffffc0; > > > > is accepted. The thing I can't figure out is now to also change the > > [pP] packets so that GDB can correctly detect targets that support this > > format when writing registers. > > > > General comments? > > What's the point? Simply that registers don't have an endianness? Several motivations: o there is no robust way of communicating a change in endianess through the protocol. This should be trivial. Fetch the status register and check the endian bit. Nope. o I've had it with trying to read what are endian independant values backwards. enjoy, Andrew >From cadamuro@lit.cpdtt.cefetpr.br Wed Dec 06 03:22:00 2000 From: João Cadamuro Junior To: gdb Subject: Re: GDB for powerpc-eabi under cygwin Date: Wed, 06 Dec 2000 03:22:00 -0000 Message-id: <3A2E2311.16CFC078@lit.cpdtt.cefetpr.br> References: <3A27C7CC.F75AE735@lit.cpdtt.cefetpr.br> X-SW-Source: 2000-12/msg00029.html Content-length: 2343 After "fighting and fighting", I fix the problem in building GDB under cygwin 1.1.6. Firstly, the problem was cygwin, not GDB. This was discovered when I tried to build the insight-5.0 release and it fail in the same point as 2000-11-30 snapshot. So, after a number of workarounds without success, I decide to work as a typical Windows user - remove cygwin and install it all again. After that, I rebuild all my tools (binutils, cross compiler, libraries and debugger) and ... works!!! Also the second problem described with breakpoints in the SDS target disappeared (for now I'm using SDS target for 2 days without seeing the problem again...). After all, I think I have a corruption in some cygwin upgrade, because since version 1.1.2 I only upgrade my cygwin installation. Thank you for all the people who inverst their precious time in taking a look into my problem. Special thanks to Michael Chastain for the help with the PowerPC simulator, whose problem wasn't cygwin. I hope this can help more cygwin users in the future... Best Regards, João Cadamuro Junior LIT / CPDTT / CEFET-PR URL.: http://www.lit.cpdtt.cefetpr.br > I have a little questions about debugging powerpc targets and I'll be > grateful for any help... > > I'm using gdb+insight to debug my PowerPC target. The debugger was built > using option "--target=powerpc-eabi" and under cygwin (Pentium III > machine with Windows2000 (SP 1) Operating System). > > The last successful built for me was 2000-08-16. After this version I > tryied to build a certain number of snapshots without success. > > I have two reasons for build a newer gdb version: > > 1. PowerPC simulator don't work for snapshot 2000-08-16. > > If you compile a simple "Hello Word" for the simulator and try to debug > it with GDB, you'll be "ejected"... > > 2. Sometimes when the target reports a breakpoint to GDB host with a > Breakpoint Signal (SDS monitor target...) gdb "eject" me too. The point > here is that target stop execution, repots the breakpoint signal, and > GDB crashes receiving this signal. Because this problem is not > deterministic, I cannot fix it... > > With this problems, my last try to build gdb+insight was 2000-11-30 > snapshot, under cygwin-1.1.6 . > ............. > > > João Cadamuro Junior > LIT / CPDTT / CEFET-PR > URL.: http://www.lit.cpdtt.cefetpr.br