* Re: Status of Gdb support for new ABI?
[not found] <m2d7dg1mnt.fsf@kelso.bothner.com>
@ 2001-01-29 4:54 ` Jason Merrill
2001-01-29 12:18 ` Trond Eivind Glomsrød
0 siblings, 1 reply; 2+ messages in thread
From: Jason Merrill @ 2001-01-29 4:54 UTC (permalink / raw)
To: Per Bothner; +Cc: gcc-sc, gdb
>>>>> "Per" == Per Bothner <per@bothner.com> writes:
> How well does Gdb handle the new ABI? This is actually two questions:
> (1) How well does cvs trunk of Gdb handle the new ABI?
It handles the mangling properly. I don't think there is any specific
support for the new ABI object model yet, and the dwarf2 output hasn't yet
been expanded to give the debugger a more complete idea of, say, how to
find virtual bases.
> (2) How well does the current Gdb release handle the new ABI?
It doesn't handle the new mangling at all.
> I'm guessing that the answer to (1) is 'ok' and that of (2) is 'not'.
> One could argue that it is not acceptable for the current Gdb to
> be unable to (reasonably) debug C++ programs generated by the current Gcc.
> The implication is: We need to make sure Gdb 5.1 is released on
> or before GCC 3.0 is released. Is this possible? Am I wrong?
If necessary, we could make a minor release of GDB that just updates the
demangler. That would be pretty straightforward.
Jason
From \x03joel.brenner@tchip.com Mon Jan 29 08:34:00 2001
From: Joel Brenner <\x03joel.brenner@tchip.com>
To: Nicolas.Thery@Symbian.com
Cc: gdb@sources.redhat.com
Subject: Re: Does GDB suports mixed ARM_code (ARM+Thumb) debugging?
Date: Mon, 29 Jan 2001 08:34:00 -0000
Message-id: <3A759BB1.A496464E@tchip.com>
References: <OFC19A9A36.829A7E77-ON802569DF.0048275F@Symbian.com>
X-SW-Source: 2001-01/msg00201.html
Content-length: 3005
Nicolas.Thery@Symbian.com wrote:
> Joel Brenner <\x03joel.brenner@tchip.com> wrote:
>
> > does gdb 2.95.2 configured for arm-elf supports debuggin of objects
> > generated by linking together ARM-code (32 bit) and Thumb-code (16 bit)?
>
> GDB 4.17 does. So I guess more recent versions do too.
>
> *******************************************************************************************************************
> Symbian Limited (Co.No.3173352) Registered Office: Sentinel House, 16 Harcourt Street, London, W1H 4AD, UK.
> This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify postmaster@symbian.com and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
> *******************************************************************************************************************
I've now installed gcc-20010122 to generate thumb-code and it works.
At debugging time (gdb 5.0) there are some problems.
ARM-code compiled with -c -g -O2 -mcpu=arm7tdmi -mthumb-interwork and placed ad address (00100c50 g F .text 00000014 MainApp)
int MainApp( void )
{
for (;;)
{
thumb_func();
};
return(TRUE);
}
Dump of assembler code for function MainApp:
0x100c50 <MainApp>: mov r12, sp
0x100c54 <MainApp+4>: stmdb sp!, {r11, r12, lr, pc}
0x100c58 <MainApp+8>: sub r11, r12, #4 ; 0x4
0x100c5c <MainApp+12>: bl 0x10143c <__thumb_func_from_arm>
0x100c60 <MainApp+16>: b 0x100c5c <MainApp+12>
End of assembler dump.
Thumb-code compiled with -c -g -O2 -mcpu=arm7tdmi -mthumb -mthumb-interwork and placed at address(00100ef4 g .text 00000012 thumb_func)
void thumb_func(void)
{
unsigned char channel;
for(channel=0;channel < 4; channel ++);
}
Dump of assembler code for function thumb_func:
0x100efc <thumb_func>: push {lr}
0x100efe <thumb_func+2>: mov r3, #0
0x100f00 <thumb_func+4>: add r3, #1
0x100f02 <thumb_func+6>: lsl r3, r3, #24
0x100f04 <thumb_func+8>: lsr r3, r3, #24
0x100f06 <thumb_func+10>: cmp r3, #3
0x100f08 <thumb_func+12>: bls 0x100f00 <thumb_func+4>
0x100f0a <thumb_func+14>: pop {r0}
0x100f0c <thumb_func+16>: bx r0
End of assembler dump.
If I begin a dubugging session with gdb there are no preblems if I never try to enter (step) in Thumb_func(), if I do this gdb never comes bak.
My questions are:
-are the compilation flags the right one?
-can I'use a standard linker script or a midified one for interworking conde?
-where is the problem ?
-gdb automaticly swith betwen 16 and 32 bit code ?
tanks joel brenner
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Status of Gdb support for new ABI?
2001-01-29 4:54 ` Status of Gdb support for new ABI? Jason Merrill
@ 2001-01-29 12:18 ` Trond Eivind Glomsrød
0 siblings, 0 replies; 2+ messages in thread
From: Trond Eivind Glomsrød @ 2001-01-29 12:18 UTC (permalink / raw)
To: Jason Merrill; +Cc: Per Bothner, gcc-sc, gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 24927 bytes --]
Jason Merrill <jason@redhat.com> writes:
> >>>>> "Per" == Per Bothner <per@bothner.com> writes:
>
> > How well does Gdb handle the new ABI? This is actually two questions:
> > (1) How well does cvs trunk of Gdb handle the new ABI?
>
> It handles the mangling properly. I don't think there is any specific
> support for the new ABI object model yet, and the dwarf2 output hasn't yet
> been expanded to give the debugger a more complete idea of, say, how to
> find virtual bases.
>
> > (2) How well does the current Gdb release handle the new ABI?
>
> It doesn't handle the new mangling at all.
>
> > I'm guessing that the answer to (1) is 'ok' and that of (2) is 'not'.
> > One could argue that it is not acceptable for the current Gdb to
> > be unable to (reasonably) debug C++ programs generated by the current Gcc.
> > The implication is: We need to make sure Gdb 5.1 is released on
> > or before GCC 3.0 is released. Is this possible? Am I wrong?
>
> If necessary, we could make a minor release of GDB that just updates the
> demangler. That would be pretty straightforward.
Could you please add the patches so it works on IA64 and alpha as
well? :)
--
Trond Eivind Glomsrød
Red Hat, Inc.
From ac131313@cygnus.com Mon Jan 29 13:43:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: should xfer_memory vector functions perform multiple transfers?
Date: Mon, 29 Jan 2001 13:43:00 -0000
Message-id: <3A75E33B.4C95C935@cygnus.com>
References: <5mu26nl1cj.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00203.html
Content-length: 760
"J.T. Conklin" wrote:
>
> In many (most? (all?)) cases, the xfer_memory vector functions will
> perform multiple transfers if the size of the transfer is too large
> to do in one. The high level logic in target_xfer_memory() will do
> the same.
(Ah, yes, that ...)
> Is there a rule about whether a too-large transfer should be split by
> xfer_memory vector functions or target_xfer_memory()? If it can be
> done by vector functions, the value of target_xfer_memory_partial()
> is limited. (target_xfer_memory_partial() is used (indirectly) in
> generic_load() so that GDB is not completely stalled during large
> transfers.
My strong preference is for the target_xfer() to just move as much data
as can be copied in a single atomic operation.
Andrew
From ac131313@cygnus.com Mon Jan 29 13:46:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote protocol extension for memory access width
Date: Mon, 29 Jan 2001 13:46:00 -0000
Message-id: <3A75E406.347480D4@cygnus.com>
References: <5md7dbkr6i.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00204.html
Content-length: 197
Side topic. If the attributes are going to be nailed down then perhaphs
segments should also be included as a guideline. Hmm, perhaphs better,
we can just make the segment an attribute.
Andrew
From ac131313@cygnus.com Mon Jan 29 13:48:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote protocol extension for step out of range
Date: Mon, 29 Jan 2001 13:48:00 -0000
Message-id: <3A75E47C.D2419ADA@cygnus.com>
References: <5mwvbjj7k8.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00205.html
Content-length: 851
"J.T. Conklin" wrote:
> Step-out-of-range only commands might look like:
>
> ENN,SS..SS,EE..EE[,AA...AA]
> or:
> eSS...SS,EE..EE[,AA..AA]
>
> Which would step from the PC and repeat until it moved out of the
> range described by SS..SS and EE..EE. I've also preserved the ability
> to set the initial PC like the existing step commands for parallelism;
> I don't expect that GDB will use it either.
>
> To be able to successfully probe for this command, there should be a
> return value. An OK or EXX response should do. Older stubs would
> return "" as they do for all unrecognized commands.
>
> Btw, I chose 'E/e' because that was the only letter in the word 'step'
> that isn't already used.
Would an addition to the breakpoint packet work? Rather than break when
in this range, break when outside of this range.
Andrew
From ac131313@cygnus.com Mon Jan 29 13:52:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote protocol extension for memory access width
Date: Mon, 29 Jan 2001 13:52:00 -0000
Message-id: <3A75E55D.696C4303@cygnus.com>
References: <5md7dbkr6i.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00206.html
Content-length: 311
"J.T. Conklin" wrote:
> Rather than add new commands, my thought is to add attribute support
> like:
> mAA..AA,LLLL[,attr=val[,attr=val[,...]]]
> MAA..AA,LLLL[,attr=val[,attr=val[,...]]]:DDDD...
How do you expect to detect the presence or lack of support for this in
a remote target?
Andrew
From ac131313@cygnus.com Mon Jan 29 13:56:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Jason Merrill <jason@redhat.com>
Cc: Per Bothner <per@bothner.com>, gcc-sc@goof.com, gdb@sources.redhat.com
Subject: Re: Status of Gdb support for new ABI?
Date: Mon, 29 Jan 2001 13:56:00 -0000
Message-id: <3A75E680.194E1CE7@cygnus.com>
References: <m2d7dg1mnt.fsf@kelso.bothner.com> <u9elxvlebv.fsf@casey.cambridge.redhat.com>
X-SW-Source: 2001-01/msg00207.html
Content-length: 161
Jason Merrill wrote:
> If necessary, we could make a minor release of GDB that just updates the
> demangler. That would be pretty straightforward.
Who could?
From jtc@redback.com Mon Jan 29 14:21:00 2001
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote protocol extension for step out of range
Date: Mon, 29 Jan 2001 14:21:00 -0000
Message-id: <5mn1caf19k.fsf@jtc.redback.com>
References: <5mwvbjj7k8.fsf@jtc.redback.com> <3A75E47C.D2419ADA@cygnus.com>
X-SW-Source: 2001-01/msg00208.html
Content-length: 1524
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> Step-out-of-range only commands might look like:
>>
>> ENN,SS..SS,EE..EE[,AA...AA]
>> or:
>> eSS...SS,EE..EE[,AA..AA]
>>
>> Which would step from the PC and repeat until it moved out of the
>> range described by SS..SS and EE..EE. I've also preserved the ability
>> to set the initial PC like the existing step commands for parallelism;
>> I don't expect that GDB will use it either.
>>
>> To be able to successfully probe for this command, there should be a
>> return value. An OK or EXX response should do. Older stubs would
>> return "" as they do for all unrecognized commands.
>>
>> Btw, I chose 'E/e' because that was the only letter in the word 'step'
>> that isn't already used.
Andrew> Would an addition to the breakpoint packet work? Rather than
Andrew> break when in this range, break when outside of this range.
If we tried, we could probably come up with something that would work.
However, the point at which we know the bounds of the step region is
"right before" we issue the step command. If we were to use a varient
of the breakpoint packet, we'd have to issue two commands. I'd rather
avoid this unnecessary command/response latency. After all, that is
the primary reason for this extension.
The only other option that appeals to me is to completely depricate
the step command and have a new command that supports either step or
step out of range depending on its arguments.
--jtc
--
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Mon Jan 29 17:18:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Grant Edwards <grante@visi.com>
Cc: gdb@sources.redhat.com
Subject: Re: can't print structures w/ 5.0 (worked w/ 4.18)
Date: Mon, 29 Jan 2001 17:18:00 -0000
Message-id: <3A7615CF.89C65F36@cygnus.com>
References: <20000928171514.A1226@visi.com>
X-SW-Source: 2001-01/msg00209.html
Content-length: 505
Grant Edwards wrote:
>
> Using gdb 5.0 (insight), I can no longer print structures.
>
> (gdb) print serverState
>
> In 4.18, it prints out the elements of serverState (it's an
> array of structures). With 5.0, It just prints a number.
>
> Both of these are arm-elf target built on Inte RH6.2
>
> Why won't 5.0 print structures?
FYI,
For someone to figure out what the problem is, a lot more information is
going to be needed. For instance a simple test program, the exact
compiler used.
Andrew
From grante@visi.com Mon Jan 29 17:20:00 2001
From: Grant Edwards <grante@visi.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: can't print structures w/ 5.0 (worked w/ 4.18)
Date: Mon, 29 Jan 2001 17:20:00 -0000
Message-id: <20010129192430.A21301@visi.com>
References: <20000928171514.A1226@visi.com> <3A7615CF.89C65F36@cygnus.com>
X-SW-Source: 2001-01/msg00210.html
Content-length: 664
On Mon, Jan 29, 2001 at 05:15:59PM -0800, Andrew Cagney wrote:
> > Using gdb 5.0 (insight), I can no longer print structures.
> >
> > (gdb) print serverState
> >
> > In 4.18, it prints out the elements of serverState (it's an
> > array of structures). With 5.0, It just prints a number.
> >
> > Both of these are arm-elf target built on Inte RH6.2
> >
> > Why won't 5.0 print structures?
>
> For someone to figure out what the problem is, a lot more information is
> going to be needed. For instance a simple test program, the exact
> compiler used.
I'll try to come up with a small program that duplicates the
problem.
--
Grant Edwards
grante@visi.com
From fjh@cs.mu.oz.au Mon Jan 29 21:25:00 2001
From: Fergus Henderson <fjh@cs.mu.oz.au>
To: gcc@gcc.gnu.org, gdb@sources.redhat.com, mercury-developers@cs.mu.oz.au
Subject: gdb & Mercury (was: live range splitting)
Date: Mon, 29 Jan 2001 21:25:00 -0000
Message-id: <20010130162502.A27072@hg.cs.mu.oz.au>
References: <20010130035143.596FD34D80@nile.gnat.com>
X-SW-Source: 2001-01/msg00211.html
Content-length: 4432
This originated on the gcc list. I'm cross-posting to the gdb
and mercury-developers lists.
On 29-Jan-2001, dewar@gnat.com <dewar@gnat.com> wrote:
> <<For the Mercury front-end, inhibiting optimizations because they might
> break gdb seems like a very bad idea, since gdb is in most cases
> pretty useless for ordinary Mercury developers. The main problem is
> that gdb doesn't know how to print out Mercury data structures.
> >>
>
> Two comments.
>
> 1. You could certainly make GDB Mecury data structure aware, as we have
> for GNAT. (we are working hard on getting these patches checked into the
> main gdb tree ASAP).
It would certainly be *possible*. The question is whether the large
amount of effort required to do so would be worth it. Since gdb
doesn't understand Mercury's nondet procedures, merely fixing it to
understand Mercury data structures still wouldn't be satisfactory.
I suspect that getting gdb to handle Mercury data structures will be
quite difficult, because of two aspects of Mercury which AFAIK are not
present in any of the languages that gdb currently supports:
1. Tagged pointers.
The Mercury compiler represents discriminated unions
using the low bits of word-aligned pointers as tag
bits.
2. Parametric polymorphism.
Mercury supports parametric polymorphism with shared
code (unlike e.g. C++ templates).
In the code that we generate, the *type* of one
parameter can depend on the *value* of another
parameter.
Furthermore, mdb supports a `retry' command, which allows you to
restart a function call after it just has returned.
This feature is so useful that it is considered almost essential.
gdb doesn't support this, and adding it would be a non-trivial task.
Finally, the Mercury compiler has a number of different back-ends.
The GCC back-end is just one of those. It makes more sense for us to
work on a debugger that will support all our different back-ends, or
at least as many as possible, rather than working on which will only
support the GCC back-end. The advantage of using gdb is that work
done on it is amortized over different languages, but for us it may
make better sense to amortize over different back-ends.
> 2. Even if that is not done, it is quite wrong to think that gdb is
> not usable. A very common debugging technique is to write debug
> callable routines that write out results at an appropriate level
> of abstraction (e.g. when debugging the gcc backend, you do not
> dump raw tree structures, you use the appropriate debug routines).
I have used that technique when debugging the Mercury compiler.
Indeed the Mercury standard library provides a routine that will
print out any value, given the value and the appropriate type descriptor.
However, figuring out the type descriptors by hand is very hard,
even for me, and if you get it wrong the result is a seg fault,
which generally means you have to restart debugging from the start
of the program. I would not want to recommend this technique to
ordinary Mercury programmers. `mdb' is much much easier to use.
> <<was. Instead, we have our own debugger `mdb', which uses our own
> format of debug information that we put in the executable as ordinary
> read-only static constants (i.e. .rodata). We plan to adapt mdb to
> work with the GCC back-end version of the Mercury compiler.
> >>
>
> Surely it would be much better to use an appropriate Dwarf-2 section.
> You don't want to unconditionally load debug data.
That would only be portable to systems that use Dwarf-2. Putting the
debug info in ordinary read-only static constants is more portable.
With demand loading, the cost of this is not so bad. And you only pay
it when you compile with debugging enabled. Actually our debugging
scheme has some other costs which are worse. But note that for
debugging you want to inhibit tail recursion and sibling call
optimization, so performance of Mercury programs compiled with
debugging enabled is never going to be great anyway.
P.S. If you want to know more about the Mercury debugger, there's a paper
"The implementation technology of the Mercury debugger" on our web site
at < http://www.cs.mu.oz.au/mercury/information/papers.html >.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh > | -- the last words of T. S. Garp.
From dewar@gnat.com Mon Jan 29 22:02:00 2001
From: dewar@gnat.com
To: fjh@cs.mu.oz.au, gcc@gcc.gnu.org, gdb@sources.redhat.com, mercury-developers@cs.mu.oz.au
Subject: Re: gdb & Mercury (was: live range splitting)
Date: Mon, 29 Jan 2001 22:02:00 -0000
Message-id: <20010130060215.A446534D80@nile.gnat.com>
X-SW-Source: 2001-01/msg00212.html
Content-length: 219
<<That would only be portable to systems that use Dwarf-2. Putting the
debug info in ordinary read-only static constants is more portable.
>>
I think that all systems support Dwarf-2 in the sense that matters here ..
From jason@redhat.com Tue Jan 30 04:32:00 2001
From: Jason Merrill <jason@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Per Bothner <per@bothner.com>, gdb@sources.redhat.com
Subject: Re: Status of Gdb support for new ABI?
Date: Tue, 30 Jan 2001 04:32:00 -0000
Message-id: <u9puh5dxym.fsf@casey.cambridge.redhat.com>
References: <m2d7dg1mnt.fsf@kelso.bothner.com> <u9elxvlebv.fsf@casey.cambridge.redhat.com> <3A75E680.194E1CE7@cygnus.com>
X-SW-Source: 2001-01/msg00213.html
Content-length: 279
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> Jason Merrill wrote:
>> If necessary, we could make a minor release of GDB that just updates the
>> demangler. That would be pretty straightforward.
> Who could?
Er, my wonderful friends on the GDB team.
Jason
From ac131313@cygnus.com Tue Jan 30 11:33:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Jason Merrill <jason@redhat.com>
Cc: Per Bothner <per@bothner.com>, gdb@sources.redhat.com
Subject: Re: Status of Gdb support for new ABI?
Date: Tue, 30 Jan 2001 11:33:00 -0000
Message-id: <3A771649.48A38590@cygnus.com>
References: <m2d7dg1mnt.fsf@kelso.bothner.com> <u9elxvlebv.fsf@casey.cambridge.redhat.com> <3A75E680.194E1CE7@cygnus.com> <u9puh5dxym.fsf@casey.cambridge.redhat.com>
X-SW-Source: 2001-01/msg00214.html
Content-length: 844
Jason Merrill wrote:
>
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>
> > Jason Merrill wrote:
> >> If necessary, we could make a minor release of GDB that just updates the
> >> demangler. That would be pretty straightforward.
Mumble something about debug info.
> > Who could?
>
> Er, my wonderful friends on the GDB team.
Roll on floor laughing. The 5.0 branch is about a year old so you're
not going to get a straight forward mini-release out of that. Besides,
C++ support in 5.0 sucked.
The most useful thing that could happen is for GCC's C++ group to test
current GCC against current GDB and then help track the two (by
submitting patches). That way if/when a 5.1 release is done it is going
to be close to working.
At present Dan, the sole C++ GDB maintainer, is only just managing to
tread water.
Andrew
From ac131313@cygnus.com Tue Jan 30 12:19:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: James Cownie <jcownie@etnus.com>
Cc: gdb@sourceware.cygnus.com, Jamie Guinan <guinan@bluebutton.com>
Subject: Re: Asynchronous GDB
Date: Tue, 30 Jan 2001 12:19:00 -0000
Message-id: <3A772124.14D58AD6@cygnus.com>
References: <14EU7B-0mE-00@etnus.com>
X-SW-Source: 2001-01/msg00215.html
Content-length: 600
> In other words the only thing you can do via ptrace to an unstopped
> process is kill it.
Unless the target has several processes and one is dedicated to
debugging that will always be the case. Some code somewhere will need
to stop the system just long enough to capture the required information
and then resume it.
The main thing is that it is pushed down towards the target and away
from the debug core.
In terms of async debugging, its been demoed working with single
threaded remote target but not much else. There are still some fairly
fundamental design problems in the way :-(
Andrew
From jtc@redback.com Tue Jan 30 20:32:00 2001
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: Re: remote protocol extension for step out of range
Date: Tue, 30 Jan 2001 20:32:00 -0000
Message-id: <5mvgqw8hpt.fsf@jtc.redback.com>
References: <5mwvbjj7k8.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00216.html
Content-length: 6175
>>>>> "jtc" == J T Conklin <jtc@redback.com> writes:
jtc> Step-out-of-range only commands might look like:
jtc>
jtc> ENN,SS..SS,EE..EE[,AA...AA]
jtc> or:
jtc> eSS...SS,EE..EE[,AA..AA]
jtc>
jtc> Which would step from the PC and repeat until it moved out of the
jtc> range described by SS..SS and EE..EE. I've also preserved the ability
jtc> to set the initial PC like the existing step commands for parallelism;
jtc> I don't expect that GDB will use it either.
jtc>
jtc> To be able to successfully probe for this command, there should be a
jtc> return value. An OK or EXX response should do. Older stubs would
jtc> return "" as they do for all unrecognized commands.
It turned out to be trival to implement the above. I've enclosed a
patch for review. The guts are ~50 lines, including comments. The
rest is required for the CLI so the user can enable and disable the
new packets.
I welcome any comments,
--jtc
Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.35
diff -c -r1.35 remote.c
*** remote.c 2001/01/23 22:48:56 1.35
--- remote.c 2001/01/31 04:20:08
***************
*** 662,667 ****
--- 662,701 ----
}
}
+ /* Should we try the 'e' (step over range) request? */
+ static struct packet_config remote_protocol_e;
+
+ static void
+ set_remote_protocol_e_packet_cmd (char *args, int from_tty,
+ struct cmd_list_element *c)
+ {
+ update_packet_config (&remote_protocol_e);
+ }
+
+ static void
+ show_remote_protocol_e_packet_cmd (char *args, int from_tty)
+ {
+ show_packet_config_cmd (&remote_protocol_e);
+ }
+
+
+ /* Should we try the 'E' (step over range / w signal #) request? */
+ static struct packet_config remote_protocol_E;
+
+ static void
+ set_remote_protocol_E_packet_cmd (char *args, int from_tty,
+ struct cmd_list_element *c)
+ {
+ update_packet_config (&remote_protocol_E);
+ }
+
+ static void
+ show_remote_protocol_E_packet_cmd (char *args, int from_tty)
+ {
+ show_packet_config_cmd (&remote_protocol_E);
+ }
+
+
/* Should we try the 'P' (set register) request? */
static struct packet_config remote_protocol_P;
***************
*** 2030,2035 ****
--- 2064,2071 ----
init_all_packet_configs (void)
{
int i;
+ update_packet_config (&remote_protocol_e);
+ update_packet_config (&remote_protocol_E);
update_packet_config (&remote_protocol_P);
for (i = 0; i < NR_Z_PACKET_TYPES; i++)
update_packet_config (&remote_protocol_Z[i]);
***************
*** 2293,2298 ****
--- 2329,2335 ----
remote_resume (int pid, int step, enum target_signal siggnal)
{
char *buf = alloca (PBUFSIZ);
+ char *p;
if (pid == -1)
set_thread (0, 0); /* run any thread */
***************
*** 2307,2317 ****
if (target_resume_hook)
(*target_resume_hook) ();
if (siggnal != TARGET_SIGNAL_0)
{
buf[0] = step ? 'S' : 'C';
buf[1] = tohex (((int) siggnal >> 4) & 0xf);
! buf[2] = tohex ((int) siggnal & 0xf);
buf[3] = '\0';
}
else
--- 2344,2409 ----
if (target_resume_hook)
(*target_resume_hook) ();
+
+ /* The s/S/c/C packets do not return status. So if the target does
+ not support the S or C packets, the debug agent returns an empty
+ string which is detected in remote_wait(). This protocol defect
+ is fixed in the e/E packets. */
+
+ if (step && step_range_end)
+ {
+ /* If the target does not support the 'E' packet, we try the 'S'
+ packet. Ideally we would fall back to the 'e' packet if that
+ too is not supported. But that would require another copy of
+ the code to issue the 'e' packet (and fall back to 's' if not
+ supported) in remote_wait(). */
+
+ if (siggnal != TARGET_SIGNAL_0)
+ {
+ if (remote_protocol_E.support != PACKET_DISABLE)
+ {
+ p = buf;
+ *p++ = 'E';
+ *p++ = tohex (((int) siggnal >> 4) & 0xf);
+ *p++ = tohex (((int) siggnal) & 0xf);
+ *p++ = ',';
+ p += hexnumstr (p, (ULONGEST) step_range_start);
+ *p++ = ',';
+ p += hexnumstr (p, (ULONGEST) step_range_end);
+ *p++ = 0;
+
+ putpkt (buf);
+ getpkt (buf, PBUFSIZ, 0);
+
+ if (packet_ok(buf, &remote_protocol_E) == PACKET_OK)
+ return;
+ }
+ }
+ else
+ {
+ if (remote_protocol_e.support != PACKET_DISABLE)
+ {
+ p = buf;
+ *p++ = 'e';
+ p += hexnumstr (p, (ULONGEST) step_range_start);
+ *p++ = ',';
+ p += hexnumstr (p, (ULONGEST) step_range_end);
+ *p++ = 0;
+
+ putpkt (buf);
+ getpkt (buf, PBUFSIZ, 0);
+
+ if (packet_ok(buf, &remote_protocol_e) == PACKET_OK)
+ return;
+ }
+ }
+ }
+
if (siggnal != TARGET_SIGNAL_0)
{
buf[0] = step ? 'S' : 'C';
buf[1] = tohex (((int) siggnal >> 4) & 0xf);
! buf[2] = tohex (((int) siggnal) & 0xf);
buf[3] = '\0';
}
else
***************
*** 5497,5503 ****
--- 5589,5598 ----
static void
show_remote_cmd (char *args, int from_tty)
{
+
show_remote_protocol_Z_packet_cmd (args, from_tty);
+ show_remote_protocol_e_packet_cmd (args, from_tty);
+ show_remote_protocol_E_packet_cmd (args, from_tty);
show_remote_protocol_P_packet_cmd (args, from_tty);
show_remote_protocol_binary_download_cmd (args, from_tty);
}
***************
*** 5641,5646 ****
--- 5736,5755 ----
add_info ("remote-process", remote_info_process,
"Query the remote system for process info.");
+
+ add_packet_config_cmd (&remote_protocol_e,
+ "e", "step-over-range",
+ set_remote_protocol_e_packet_cmd,
+ show_remote_protocol_e_packet_cmd,
+ &remote_set_cmdlist, &remote_show_cmdlist,
+ 0);
+
+ add_packet_config_cmd (&remote_protocol_E,
+ "E", "step-over-range-w-signal",
+ set_remote_protocol_E_packet_cmd,
+ show_remote_protocol_E_packet_cmd,
+ &remote_set_cmdlist, &remote_show_cmdlist,
+ 0);
add_packet_config_cmd (&remote_protocol_P,
"P", "set-register",
--
J.T. Conklin
RedBack Networks
From \x03joel.brenner@tchip.com Wed Jan 31 01:35:00 2001
From: Joel Brenner <\x03joel.brenner@tchip.com>
To: gdb@sources.redhat.com
Subject: Does GDB suports mixed ARM_code (ARM+Thumb) debugging?
Date: Wed, 31 Jan 2001 01:35:00 -0000
Message-id: <3A77DC9D.FA1C95B5@tchip.com>
X-SW-Source: 2001-01/msg00217.html
Content-length: 0
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2001-01-29 12:18 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <m2d7dg1mnt.fsf@kelso.bothner.com>
2001-01-29 4:54 ` Status of Gdb support for new ABI? Jason Merrill
2001-01-29 12:18 ` Trond Eivind Glomsrød
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox