Re: Fix stack backtraces on 26-bit ARM

Re: Fix stack backtraces on 26-bit ARM

[Andrew Cagney]

> I'm trying to make GDB 5.0 work on NetBSD/arm26.  One problem I've run
> into is that even with "set apcs32 0", stack backtraces include flags in
> the program counter for all frames apart from the top one.  I think this
> patch fixes the problem by using arm_addr_bits_remove() to clean up the
> PC fetched from a stack frame.  I'm not in a position to check this still
> works on arm32 and thumb.

Hmm, this could get interesting.  A NetBSD/arm port of GDB would 
certainly help improve the quality of the Arm GDB target.  Your 
contribution are going to be most welcome.  Problem is, I can't find a 
copyright assignment for you (you'll get a separate e-mail about this). 
  Can you please clarify your assignment status?  Not having an 
assignment can make things, er, interesting.  At present your submitting 
small simple bugs that can be described in simple english.

The other thing to know is that patches should be against the current 
trunk rather than the last release.  5.0 is just so old ...

Anyway I'm sure you'll be hearing from the relevant target maintainers soon.

enjoy,
Andrew

Re: Fix stack backtraces on 26-bit ARM

[Ben Harris]

On Sat, 20 Oct 2001, Andrew Cagney wrote:

> Hmm, this could get interesting.  A NetBSD/arm port of GDB would
> certainly help improve the quality of the Arm GDB target.  Your
> contribution are going to be most welcome.  Problem is, I can't find a
> copyright assignment for you (you'll get a separate e-mail about this).
>   Can you please clarify your assignment status?  Not having an
> assignment can make things, er, interesting.  At present your submitting
> small simple bugs that can be described in simple english.

I've signed assignments for GCC and Binutils.  I'm happy to sign one for
GDB as well.  I haven't worked out quite who wrote our existing ARM GDB
stuff: it was checked in by Todd Vierling, but I think the work was mostly
done by Mark Brinicombe.

> The other thing to know is that patches should be against the current
> trunk rather than the last release.  5.0 is just so old ...

Unfortunately, 5.0 is what NetBSD is currently working towards using, so
all my patches are likely to start life there.  I'll do what I can to
ensure they're still relevant to the trunk, though.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL: http://www.netbsd.org/Ports/arm26/ >

Re: Fix stack backtraces on 26-bit ARM

[Andrew Cagney]

> On Sat, 20 Oct 2001, Andrew Cagney wrote:
> 
> 
>> Hmm, this could get interesting.  A NetBSD/arm port of GDB would
>> certainly help improve the quality of the Arm GDB target.  Your
>> contribution are going to be most welcome.  Problem is, I can't find a
>> copyright assignment for you (you'll get a separate e-mail about this).
>> Can you please clarify your assignment status?  Not having an
>> assignment can make things, er, interesting.  At present your submitting
>> small simple bugs that can be described in simple english.
> 
> 
> I've signed assignments for GCC and Binutils.  I'm happy to sign one for
> GDB as well.  I haven't worked out quite who wrote our existing ARM GDB
> stuff: it was checked in by Todd Vierling, but I think the work was mostly
> done by Mark Brinicombe.

Yes, please get an assignment.  It makes everyones life soooo much easier.

If you're not sure where the code came from and/or it isn't clear that 
the original contributors have an assignment then you'll need to 
``ignore'' it.  Most recent *BSD contributors have ended up abandoning 
their old branch, instead starting anew.

Having said that, the approach you appear to be taking looks to be the 
right one - identify individual bugs and get them submitted/fixed.

>> The other thing to know is that patches should be against the current
>> trunk rather than the last release.  5.0 is just so old ...
> 
> 
> Unfortunately, 5.0 is what NetBSD is currently working towards using, so
> all my patches are likely to start life there.  I'll do what I can to
> ensure they're still relevant to the trunk, though.

Hmm, something additional to note, GDB 5.1-branch and current both work 
on many more NetBSD systems than 5.0.  You man want to consider getting 
current working first.

good luck!
Andrew

Re: Fix stack backtraces on 26-bit ARM

[Richard Earnshaw]

> If you're not sure where the code came from and/or it isn't clear that 
> the original contributors have an assignment then you'll need to 
> ``ignore'' it.  Most recent *BSD contributors have ended up abandoning 
> their old branch, instead starting anew.

Hmm, I have the bones of a completely clean NetBSD/arm port.  It isn't 
complete, but it was written without reference to the existing NetBSD code.

The reason I never submitted it before was that at the time I didn't have 
a relevant disclaimer for gdb on file.

However, now that ARM has signed a disclaimer covering GDB, I'll dust it 
off and post it.

R.

Re: Fix stack backtraces on 26-bit ARM

[Richard Earnshaw]

> Hmm, I have the bones of a completely clean NetBSD/arm port.  It isn't 
> complete, but it was written without reference to the existing NetBSD code.
> 

Ok, attached is most of the code.  There's one more patch, which I'll send
separately, that allows ARM targets to be single-stepped when there is no
kernel/hw support for single stepping.

R.

<date> Richard Earnshaw <rearnsha@arm.com>

	* config/arm/nbsd.mh config/arm/nbsd.mt config/arm/tm-nbsd.h
	config/arm/nm-nbsd.h config/arm/xm-nbsd.h: New files.
	* armbsd-nat.c: New file.
	* Makefile.in: Build it.
	* configure.host configure.tgt: Support NetBSD/arm.

[patch]: Software single-stepping on ARMs

[Richard Earnshaw]

This patch enables support for software single-stepping on ARM processors.  This is required for NetBSD, and a good idea on some older linux kernels, where single-stepping tended to work erratically.

<date> Richard Earnshaw <rearnsha@arm.com>

	* arm-tdep.c (arm_software_single_step): New function.
	(arm_get_next_pc, thumb_get_next_pc, bitcount, shifted_reg_val): Only
	needed for software single-stepping.
	

Re: [patch]: Software single-stepping on ARMs

[Fernando Nasser]

I haven't heard from GNU/Linux native ARM folks (Scott?), so if this do not
break my remote target testsuite run I will check it in.

Fernando

Richard Earnshaw wrote:
> 
> This patch enables support for software single-stepping on ARM processors.  This is required for NetBSD, and a good idea on some older linux kernels, where single-stepping tended to work erratically.
> 
> <date> Richard Earnshaw <rearnsha@arm.com>
> 
>         * arm-tdep.c (arm_software_single_step): New function.
>         (arm_get_next_pc, thumb_get_next_pc, bitcount, shifted_reg_val): Only
>         needed for software single-stepping.
> 
> 
>                                                   ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                         Name: gdb.step.patch
>    gdb.step.patch       Type: application/x-patch
>                  Description: gdb.step.patch

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [patch]: Software single-stepping on ARMs

[Fernando Nasser]

This one is in.

Richard Earnshaw wrote:
> 
> This patch enables support for software single-stepping on ARM processors.  This is required for NetBSD, and a good idea on some older linux kernels, where single-stepping tended to work erratically.
> 
> <date> Richard Earnshaw <rearnsha@arm.com>
> 
>         * arm-tdep.c (arm_software_single_step): New function.
>         (arm_get_next_pc, thumb_get_next_pc, bitcount, shifted_reg_val): Only
>         needed for software single-stepping.
> 
> 
>                                                   ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                         Name: gdb.step.patch
>    gdb.step.patch       Type: application/x-patch
>                  Description: gdb.step.patch

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Fix stack backtraces on 26-bit ARM

[Andrew Cagney]

>> Hmm, I have the bones of a completely clean NetBSD/arm port.  It isn't 
>> complete, but it was written without reference to the existing NetBSD code.
>> 
> 
> 
> Ok, attached is most of the code.  There's one more patch, which I'll send
> separately, that allows ARM targets to be single-stepped when there is no
> kernel/hw support for single stepping.
> 
> R.
> 
> <date> Richard Earnshaw <rearnsha@arm.com>
> 
> * config/arm/nbsd.mh config/arm/nbsd.mt config/arm/tm-nbsd.h
> 	config/arm/nm-nbsd.h config/arm/xm-nbsd.h: New files.
> 	* armbsd-nat.c: New file.
> 	* Makefile.in: Build it.
> 	* configure.host configure.tgt: Support NetBSD/arm.

(There has been some out of band assignment e-mail which has left me 
pretty confused :-)

Lets see.

RichardE, the above was developed while you were at ARM and is hence 
covered, solely, by an ARM assignment? [yes | no]

If this is true, can I suggest to the Arm maintainers that this be 
considered.  Then BenH can apply fixes to it (always easier and less 
likely to have assignment problems) then new code.  (I understand, third 
hand this is kind of BenH's plan already).

I think this is preferable as it gives GDB's NetBSD/ARM support a clear 
and auditable paper trail.

enjoy,
Andrew

Re: Fix stack backtraces on 26-bit ARM

[Ben Harris]

On Wed, 24 Oct 2001, Andrew Cagney wrote:

> If this is true, can I suggest to the Arm maintainers that this be
> considered.

I'd suggest that, for consistency with the other NetBSD ports,
armbsd-nat.c be renamed armnbsd-nat.c

> Then BenH can apply fixes to it (always easier and less
> likely to have assignment problems) then new code.  (I understand, third
> hand this is kind of BenH's plan already).

This is my plan, yes, to the extent that I've already removed Mark's code
from our in-tree GDB 5.0 and replaced it with Richard's.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL: http://www.netbsd.org/Ports/arm26/ >

Re: Fix stack backtraces on 26-bit ARM

[Fernando Nasser]

I understood from BenH response and from a private conversation with
Andrew that it was OK to check this in, so I did it (although this is
a little borderline w.r.t. maintainership -- see below).

Note that this is rather a new target (although an ARM one) so we would 
need a maintainer for it.  You can see that it is basically new files
and I don't have a NetBSR ARM machine around here (nor does Scott, I guess).

I believe we would need to add the following to gdb/MAINTAINERS until
this is decided:

Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.133
diff -c -p -r1.133 MAINTAINERS
*** MAINTAINERS	2001/12/15 17:09:04	1.133
--- MAINTAINERS	2001/12/17 16:30:31
*************** hurd native		Mark Kettenis		kettenis@gnu
*** 207,212 ****
--- 207,213 ----
  NetBSD native & host	J.T. Conklin		jtc@redback.com
  SCO/Unixware		Robert Lipe		rjl@sco.com
  GNU/Linux ARM native	Scott Bambrough		scottb@netwinder.org
+ NetBSD ARM native	(vacant)
  Solaris/x86 native & host (devolved)
  			Peter Schauer		Peter.Schauer@regent.e-technik.tu-muenchen.de
  Solaris/SPARC native & host (devolved)
                                                                               





Andrew Cagney wrote:
> 
> >> Hmm, I have the bones of a completely clean NetBSD/arm port.  It isn't
> >> complete, but it was written without reference to the existing NetBSD code.
> >>
> >
> >
> > Ok, attached is most of the code.  There's one more patch, which I'll send
> > separately, that allows ARM targets to be single-stepped when there is no
> > kernel/hw support for single stepping.
> >
> > R.
> >
> > <date> Richard Earnshaw <rearnsha@arm.com>
> >
> > * config/arm/nbsd.mh config/arm/nbsd.mt config/arm/tm-nbsd.h
> >       config/arm/nm-nbsd.h config/arm/xm-nbsd.h: New files.
> >       * armbsd-nat.c: New file.
> >       * Makefile.in: Build it.
> >       * configure.host configure.tgt: Support NetBSD/arm.
> 
> (There has been some out of band assignment e-mail which has left me
> pretty confused :-)
> 
> Lets see.
> 
> RichardE, the above was developed while you were at ARM and is hence
> covered, solely, by an ARM assignment? [yes | no]
> 
> If this is true, can I suggest to the Arm maintainers that this be
> considered.  Then BenH can apply fixes to it (always easier and less
> likely to have assignment problems) then new code.  (I understand, third
> hand this is kind of BenH's plan already).
> 
> I think this is preferable as it gives GDB's NetBSD/ARM support a clear
> and auditable paper trail.
> 
> enjoy,
> Andrew

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9