Merge of ARM Linux port with existing ARM code...

Merge of ARM Linux port with existing ARM code...

[Scott Bambrough]

[-- Attachment #1: Type: text/plain, Size: 5989 bytes --]

Jim,

I have finished merging the ARM code.  It will require another round of
patches to fix a few warts, but I would appreciate having it looked at. 
It has regressed a little from my previous version, but I'm almost back
to where I was.  I've attached a patch, and placed a tarball of the
source on netwinder.org at:

ftp://ftp.netwinder.org/users/s/scottb/gdb-991103.tar.gz

I've made two targets in the configure scripts for ARM: linux and
embedded.  Basically I have:

in gdb/config/arm:

embed.mh, embed.mt, nm-embed.h, tm-embed.h, xm-embed.h
linux.mh, linux.mt, nm-linux.h, tm-linux.h, xm-linux.h
tm-arm.h

Most files are very short.  The bulk of the definitions are in tm-arm.h.
tm-linux.h and tm-embed.h both include this and add/override anything
necessary.

in gdb:

arm-tdep.c, armlinux-nat.c, arm-xdep.o

Again, the bulk of the code is in arm-tdep.c.  armlinux-nat.c contains
stuff specific to linux.  I'm not sure what to make of the code in
arm-xdep.c.  The Linux target makes no use of it, but the embedded
target does.  Much of it seems geared towards an Acorn machines.
I have left it alone.  You should have a look at it.

If something doesn't seem right, or you don't like what I have done,
please say so.  Nothing is written in stone.  I took the liberty of
converting all the code to ANSI (except arm-xdep.c) and started
converting all the macros in tm-arm.h to functions in preparation for
being multi-arch friendly.  I'm certain I have missed a few though.  I
intend to revisit the code.

I have compiled, linked, and run the testsuite for GDB successfully for
build = host = target=arm-unknown-linux-gnu.

               === gdb Summary ===

# of expected passes            6009
# of unexpected failures        48
# of unexpected successes       2
# of expected failures          195
# of unresolved testcases       3

I have compiled and linked for GDB successfully for:

	build=host=arm-unknown-linux-gnu, target=arm-elf
	build=host=arm-unknown-linux-gnu, target=arm-coff

	build=host=i586-pc-linux-gnu, target=arm-unknown-linux-gnu.
	build=host=i586-pc-linux-gnu, target=arm-elf
	build=host=i586-pc-linux-gnu, target=arm-coff

This verifies there are no outstanding syntax errors or unresolved
externals at least.  The testsuite fails in all cases due to the lack of
suitable cross compilers and target hardware.  I don't believe I will be
able to run the testsuites successfully for the embedded targets. 
The x86 builds wouldn't compile correctly due to the implementations of
convert_from_extended(), convert_to_extended().  I have ifdef'd them out
ATM, and replaced them with stubs, until I can resolve the problems.

I don't have suitable environments to test:

	build=host=sparc-sun-solaris2.5
	build=host=i686-cygwin32

TO DO:

Shared library support:
Both targets make use of IN_SOLIB_CALL_TRAMPOLINE.  This needs to be
resolved for ARM-Thumb compatibility.  At the moment this is not
implemented on Linux, and Thumb is not an issue on Linux (at this very
moment at least).  I have to get this support going, and I will resolve
it then.

Thread support:
This has been waiting for Cygnus to integrate the threading patches, so
I don't redo their efforts.

Multi-arch readiness:
	1) Remove EXTRA_FRAME_INFO.  
	2) Replace FRAME_FIND_SAVED_REGS with FRAME_INIT_SAVED_REGS.
	3) Convert REGISTER_NAME to a function.
	4) Convert to new CALL_DUMMY scheme.
	5) Verify functions maintain name space purity.

Note: There is code in arm-tdep.c for the new call dummy scheme.  It was
written by Cygnus, and I think Cygnus should enable it and verify its
correctness.

Breakpoints:
I believe I have resolved Andrew Cagney's objections regarding the
breakpoint code.  The global BREAKPOINT macros are gone, and have been
replaced by arm_breakpoint_from_pc(), and macros used to define the
various types of breakpoints.  I have added commments as he suggested
indicating why things are as they are.  The following problem with
breakpoints still needs to be resolved however:

Consider the following code and the generated instructions:

1       int foo (int a)
2       {
3         int b;
4       
5         if (a == 3)
6           b = 10;
7         else
8           b = 20;
9
10        return b;
11      }

00000000 <foo>:
   0:   e1a0c00d        mov     ip, sp
   4:   e92dd800        stmdb   sp!, {fp, ip, lr, pc}
   8:   e24cb004        sub     fp, ip, #4
   c:   e3500003        cmp     r0, #3
  10:   13a00014        movne   r0, #20
  14:   03a0000a        moveq   r0, #10
  18:   e91ba800        ldmdb   fp, {fp, sp, pc}

The ARM uses a predicated instruction set (the condition in which it
will execute is an integral part of the instruction; in the case of the
ARM, the 4 most significant bits) which allows the following code:

   c:   e3500003        cmp     r0, #3
  10:   13a00014        movne   r0, #20
  14:   03a0000a        moveq   r0, #10

In the current scheme in GDB, "break 6" will set a breakpoint on line 6
of the C code.  This corresponds to the instruction at address 14: being
replaced by the breakpoint instruction.  Unfortunately it means that GDB
stops at line 6 on the ARM all the time, even when a != 3.

This could be solved by having breakpoint_from_pc() read the instruction
at the PC, and merge the condition bits into the breakpoint.  Then the
breakpoint will only be executed under the same conditions as the
original instruction.

This will present a problem for single stepping, particularly with
stepping using undefined instructions as breakpoints.  What happens if
the target of the step is an instruction that is not going to be
executed due to its condition failing.

Another problem is semantic.  The user types "break 0x10" to break at
address 10.  If I am looking at an assembly dump I usually want the
breakpoint to be unconditional.  This could lead to unexpected results
for the user.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
gdb.patch.gz


[-- Attachment #2: gdb.patch.gz --]
[-- Type: application/x-gzip, Size: 28785 bytes --]

Re: Merge of ARM Linux port with existing ARM code...

[Stan Shebs]

   Date: Wed, 03 Nov 1999 14:57:47 -0500
   From: Scott Bambrough <scottb@netwinder.org>

   I've made two targets in the configure scripts for ARM: linux and
   embedded.  Basically I have:

   in gdb/config/arm:

   embed.mh, embed.mt, nm-embed.h, tm-embed.h, xm-embed.h
   linux.mh, linux.mt, nm-linux.h, tm-linux.h, xm-linux.h
   tm-arm.h

Actually, the embed config doesn't need .mh, nm, or xm files, so I'm
leaving those out.  The rest of these files look fine, and I'm basically
putting them in verbatim.

   Most files are very short.  The bulk of the definitions are in tm-arm.h.
   tm-linux.h and tm-embed.h both include this and add/override anything
   necessary.

   in gdb:

   arm-tdep.c, armlinux-nat.c, arm-xdep.o

   Again, the bulk of the code is in arm-tdep.c.  armlinux-nat.c contains
   stuff specific to linux.  I'm not sure what to make of the code in
   arm-xdep.c.  The Linux target makes no use of it, but the embedded
   target does.  Much of it seems geared towards an Acorn machines.
   I have left it alone.  You should have a look at it.

I'm going to be marking arm-xdep.c as obsolete, as I've done with
other files.  They'll be around for the next releases, then disappear
sometime after that.

   If something doesn't seem right, or you don't like what I have done,
   please say so.  Nothing is written in stone.  I took the liberty of
   converting all the code to ANSI (except arm-xdep.c) and started
   converting all the macros in tm-arm.h to functions in preparation for
   being multi-arch friendly.  I'm certain I have missed a few though.  I
   intend to revisit the code.

That's a great start in the right direction.  We can always come back
and polish the code later on.  I'll get the basic stuff in, then you
can check it over in the next snap and tell me what I missed.

   I don't have suitable environments to test:

	   build=host=sparc-sun-solaris2.5

I'll be testing this, for crosses.

   Shared library support:
   Both targets make use of IN_SOLIB_CALL_TRAMPOLINE.  This needs to be
   resolved for ARM-Thumb compatibility.  At the moment this is not
   implemented on Linux, and Thumb is not an issue on Linux (at this very
   moment at least).  I have to get this support going, and I will resolve
   it then.

Embedded ARM won't care about this one.

   Note: There is code in arm-tdep.c for the new call dummy scheme.  It was
   written by Cygnus, and I think Cygnus should enable it and verify its
   correctness.

OK.

   Breakpoints:
   I believe I have resolved Andrew Cagney's objections regarding the
   breakpoint code.  The global BREAKPOINT macros are gone, and have been
   replaced by arm_breakpoint_from_pc(), and macros used to define the
   various types of breakpoints.  I have added commments as he suggested
   indicating why things are as they are.  The following problem with
   breakpoints still needs to be resolved however:

I suspect this issue has always been around, but nobody has noticed
because you don't get the move+condition in unoptimized code.  Optimized
code debugging will be squirrelly like it always is.

   This could be solved by having breakpoint_from_pc() read the instruction
   at the PC, and merge the condition bits into the breakpoint.  Then the
   breakpoint will only be executed under the same conditions as the
   original instruction.

The usual approach to solving this kind of problem is to copy the
instructions somewhere else and execute them there.  It's really hairy
to make work, usually implementors try to avoid the situation.  But in
the ARM case, you would break the instruction into a multi-instruction
sequence consisting of simpler instructions, then put the breakpoint
at the simpler instruction that best corresponds to the source location.
There would be some guessing as to which instruction was meant...

								Stan
From ac131313@cygnus.com Fri Dec 10 20:20:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Quality Quorum <qqi@world.std.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: another bug in remote.c
Date: Fri, 10 Dec 1999 20:20:00 -0000
Message-id: <3851D0A6.26306004@cygnus.com>
References: <Pine.SGI.3.95.991210221737.22433A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00366.html
Content-length: 750

[cc set to gdb-patches]

Quality Quorum wrote:
> 
> Hi,
> 
> I got another bug. This time I do not know how to fix it.
> It is possible to get into following sequence of of events:
> 
> gdb:       $m4000ab70,c8#22        -- asks for 200 bytes of memory
> stub:      $<400 chars>#XX         -- stub responds correctly, packet
>                                       length 404 bytes
> gdb:       Remote packet too long  -- gdb unhappy
> 
> I suspect that PBUFSIZ should not be used to determine
> max_buf_size in remote_read_bytes(). It seems like there are
> more places where similar problem may occur.

Just a quick check. How up-to-date are your sources.  Does the ChangeLog
contain entries from me where I drop a buffer from 400 to 399?

	Andrew
From qqi@world.std.com Fri Dec 10 20:44:00 1999
From: Quality Quorum <qqi@world.std.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: another bug in remote.c
Date: Fri, 10 Dec 1999 20:44:00 -0000
Message-id: <Pine.SGI.3.95.991210234247.27447B-100000@world.std.com>
References: <3851D0A6.26306004@cygnus.com>
X-SW-Source: 1999-q4/msg00367.html
Content-length: 942

On Sat, 11 Dec 1999, Andrew Cagney wrote:

> [cc set to gdb-patches]
> 
> Quality Quorum wrote:
> > 
> > Hi,
> > 
> > I got another bug. This time I do not know how to fix it.
> > It is possible to get into following sequence of of events:
> > 
> > gdb:       $m4000ab70,c8#22        -- asks for 200 bytes of memory
> > stub:      $<400 chars>#XX         -- stub responds correctly, packet
> >                                       length 404 bytes
> > gdb:       Remote packet too long  -- gdb unhappy
> > 
> > I suspect that PBUFSIZ should not be used to determine
> > max_buf_size in remote_read_bytes(). It seems like there are
> > more places where similar problem may occur.
> 
> Just a quick check. How up-to-date are your sources.  Does the ChangeLog
> contain entries from me where I drop a buffer from 400 to 399?

No, it does not. I suspect dropping PBUFSIZ would not help 
in the case anyway.

> 
> 	Andrew
> 

Thanks,

Aleksey

Re: Merge of ARM Linux port with existing ARM code...

[Scott Bambrough]

Stan Shebs wrote:

> Actually, the embed config doesn't need .mh, nm, or xm files, so I'm
> leaving those out.  The rest of these files look fine, and I'm basically
> putting them in verbatim.

That's great.  Thanks.

> I'm going to be marking arm-xdep.c as obsolete, as I've done with
> other files.  They'll be around for the next releases, then disappear
> sometime after that.

Ok.

> That's a great start in the right direction.  We can always come back
> and polish the code later on.  I'll get the basic stuff in, then you
> can check it over in the next snap and tell me what I missed.

It doesn't seem to be in this weeks snapshot, will it be in next weeks?

>    Shared library support:
>    Both targets make use of IN_SOLIB_CALL_TRAMPOLINE.  This needs to be
>    resolved for ARM-Thumb compatibility.  At the moment this is not
>    implemented on Linux, and Thumb is not an issue on Linux (at this very
>    moment at least).  I have to get this support going, and I will resolve
>    it then.
> 
> Embedded ARM won't care about this one.

Are you sure?  If the embedded Linux project takes off, this may become
an issue.

> I suspect this issue has always been around, but nobody has noticed
> because you don't get the move+condition in unoptimized code.  Optimized
> code debugging will be squirrelly like it always is.

There is no point in debugging unoptimized code.  The generated code for
-O0/-O2 is so different, it rarely suffers from the same problems.  This
has been my experience.

> The usual approach to solving this kind of problem is to copy the
> instructions somewhere else and execute them there.  It's really hairy
> to make work, usually implementors try to avoid the situation.  But in
> the ARM case, you would break the instruction into a multi-instruction
> sequence consisting of simpler instructions, then put the breakpoint
> at the simpler instruction that best corresponds to the source location.
> There would be some guessing as to which instruction was meant...

This sounds like a horrible hack.  I'll think about it.

Scott
-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From Philip.Blundell@pobox.com Wed Dec 15 10:31:00 1999
From: Philip Blundell <Philip.Blundell@pobox.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: Stan Shebs <shebs@cygnus.com>, jingham@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Merge of ARM Linux port with existing ARM code... 
Date: Wed, 15 Dec 1999 10:31:00 -0000
Message-id: <E11yJCG-0005dx-00@kings-cross.london.uk.eu.org>
References: <199912110049.QAA11719@andros.cygnus.com> <3857DC13.438069C4@netwinder.org>
X-SW-Source: 1999-q4/msg00389.html
Content-length: 752

>> The usual approach to solving this kind of problem is to copy the
>> instructions somewhere else and execute them there.  It's really hairy
>> to make work, usually implementors try to avoid the situation.  But in
>> the ARM case, you would break the instruction into a multi-instruction
>> sequence consisting of simpler instructions, then put the breakpoint
>> at the simpler instruction that best corresponds to the source location.
>> There would be some guessing as to which instruction was meant...
>
>This sounds like a horrible hack.  I'll think about it.

For the benefit of those of us who didn't see your original message (I guess 
it wasn't posted to the list), could you explain what the problem in question 
actually is?

Thanks

p.

Re: Merge of ARM Linux port with existing ARM code...

[Scott Bambrough]

Philip Blundell wrote:
> 
> For the benefit of those of us who didn't see your original message (I guess
> it wasn't posted to the list), could you explain what the problem in question
> actually is?

We have actually discussed the problem before Phil.  It is the problem
with predicated instructions and breakpoints.  The messages actually did
go to the list.  I have included the archive urls below.

These are the messages in question:

http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00163.html
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00365.html

Cheers,

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From shebs@cygnus.com Wed Dec 15 11:54:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: Philip.Blundell@pobox.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Merge of ARM Linux port with existing ARM code...
Date: Wed, 15 Dec 1999 11:54:00 -0000
Message-id: <199912151954.LAA07033@andros.cygnus.com>
References: <E11yJCG-0005dx-00@kings-cross.london.uk.eu.org>
X-SW-Source: 1999-q4/msg00393.html
Content-length: 1024

   Date: Wed, 15 Dec 1999 18:30:43 +0000
   From: Philip Blundell <Philip.Blundell@pobox.com>

   >> The usual approach to solving this kind of problem is to copy the
   >> instructions somewhere else and execute them there.  It's really hairy
   >> to make work, usually implementors try to avoid the situation.  But in
   >> the ARM case, you would break the instruction into a multi-instruction
   >> sequence consisting of simpler instructions, then put the breakpoint
   >> at the simpler instruction that best corresponds to the source location.
   >> There would be some guessing as to which instruction was meant...
   >
   >This sounds like a horrible hack.  I'll think about it.

   For the benefit of those of us who didn't see your original message (I guess 
   it wasn't posted to the list), could you explain what the problem in question 
   actually is?

The original was posted to gdb-patches by Scott B on 3 November; URL is
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00163.html .

								Stan
From shebs@cygnus.com Wed Dec 15 14:06:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: scottb@netwinder.org
Cc: jingham@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Merge of ARM Linux port with existing ARM code...
Date: Wed, 15 Dec 1999 14:06:00 -0000
Message-id: <199912152124.NAA07105@andros.cygnus.com>
References: <3857DC13.438069C4@netwinder.org>
X-SW-Source: 1999-q4/msg00394.html
Content-length: 3309

   Date: Wed, 15 Dec 1999 13:21:07 -0500
   From: Scott Bambrough <scottb@netwinder.org>

   > That's a great start in the right direction.  We can always come back
   > and polish the code later on.  I'll get the basic stuff in, then you
   > can check it over in the next snap and tell me what I missed.

   It doesn't seem to be in this weeks snapshot, will it be in next weeks?

Yes.  It took longer than I expected to separate the cosmetic changes
from the functional changes; in general we don't like to put in mixes
of both, because it becomes very difficult to track down the causes of
problems later on.  ARM is getting a lot of attention right now, so I
need to be careful not to crumble anything...

   >    Shared library support:
   >    Both targets make use of IN_SOLIB_CALL_TRAMPOLINE.  This needs to be
   >    resolved for ARM-Thumb compatibility.  At the moment this is not
   >    implemented on Linux, and Thumb is not an issue on Linux (at this very
   >    moment at least).  I have to get this support going, and I will resolve
   >    it then.
   > 
   > Embedded ARM won't care about this one.

   Are you sure?  If the embedded Linux project takes off, this may become
   an issue.

By "embedded ARM" I meant the arm-{elf,coff} configs, which are mainly
for bare boards with little or no OS.  Embedded ARM Linux is an
interesting issue though; should the GDB for it be the generic arm-elf
GDB or a new and different config?  At this point I don't know; for
EL/IX experimentation I think they're using a standard cross GDB, but
that will need to change to accommodate all four levels of the EL/IX
API. ( http://sourceware.cygnus.com/elix for EL/IX info)

   > I suspect this issue has always been around, but nobody has noticed
   > because you don't get the move+condition in unoptimized code.  Optimized
   > code debugging will be squirrelly like it always is.

   There is no point in debugging unoptimized code.  The generated code for
   -O0/-O2 is so different, it rarely suffers from the same problems.  This
   has been my experience.

You're right about the size of the descrepancy between -O0 and -O2,
but I think it's going a bit far to say "there is no point in
debugging unoptimized code".  Almost all of my own debugging work is
done on unoptimized code.

GDB's official position on optimized code is to allow the debugger to
work with it, but not to promise very much functionality.  -O2 in GCC
includes ever-more-aggressive optimizations, and it's going to be hard
or impossible for GDB to reconstruct the original code in all cases.
Conditional moves are a primo example - you have a single instruction
that is an amalgam of several source lines, and you want GDB to
present the illusion that it can do several statement-level steps,
when the actual hardware will do only one instruction-level step.  For
GDB, an instruction-level step is an atomic operation.  How do you
divide up an atom?  (Use a cyclotron, of course :-) )

The problems here are very deep and common to all debugging.  If you
review the research literature, it's clear that while there's been
some progress, it's still too limited in scope to be really useful for
GDB.  Still, it would be cool for someone to extend the state of the
art and demo it in GDB first - any volunteers?

								Stan

Re: Merge of ARM Linux port with existing ARM code...

[Stan Shebs]

   Date: Wed, 15 Dec 1999 13:21:07 -0500
   From: Scott Bambrough <scottb@netwinder.org>

   > That's a great start in the right direction.  We can always come back
   > and polish the code later on.  I'll get the basic stuff in, then you
   > can check it over in the next snap and tell me what I missed.

   It doesn't seem to be in this weeks snapshot, will it be in next weeks?

Just to confirm, I've pasted in your ARM GNU/Linux changes.  They're
not put in verbatim; I tweaked some names and usages to conform better
to the coding standards, and didn't apply some changes that only
rearranged code, so as to simplify the diffs.  I didn't (intentionally
anyway :-) ) discard anything substantive, so you should get the next
snap and try patching in any changes you may have made since the
beginning of November.  I also wrote ChangeLog entry and NEWS item.

Since I don't have a native to test on, the ARM GNU/Linux config
testing is up to you; but your tweaks in inferior function call code
results in four more passes in the testsuite, and no additional fails.

So thanks again for the contribution, and let me know how it all works
on the Netwinder!

								Stan
From taylor@cygnus.com Fri Dec 17 16:02:00 1999
From: David Taylor <taylor@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: (patch) hpjyg03: (buildsym|language).[ch]
Date: Fri, 17 Dec 1999 16:02:00 -0000
Message-id: <199912172347.SAA29264@texas.cygnus.com>
X-SW-Source: 1999-q4/msg00405.html
Content-length: 1385

It has been noticed that the language.c portion of this patch causes
additional noise at startup.  Namely:

    warning: Unrecognized range check setting: "auto; currently off"

I'm curious as to whether this message gets printed at HP (or are
there other language.c patches not yet submitted that get rid of it).

In any case, here's a patch to eliminate that noise:

taylor@texas 548: cvs diff -c language.c
Index: language.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/language.c,v
retrieving revision 2.68
diff -c -r2.68 language.c
*** language.c  1999/12/13 18:00:13     2.68
--- language.c  1999/12/17 23:26:48
***************
*** 1578,1589 ****
    add_language (&auto_language_defn);
  
    language = savestring ("auto", strlen ("auto"));
-   range = savestring ("auto", strlen ("auto"));
-   type = savestring ("auto", strlen ("auto"));
- 
-   /* Have the above take effect */
- 
    set_language_command (language, 0);
    set_type_command (NULL, 0);
    set_range_command (NULL, 0);
  }
--- 1578,1588 ----
    add_language (&auto_language_defn);
  
    language = savestring ("auto", strlen ("auto"));
    set_language_command (language, 0);
+ 
+   type = savestring ("auto", strlen ("auto"));
    set_type_command (NULL, 0);
+ 
+   range = savestring ("auto", strlen ("auto"));
    set_range_command (NULL, 0);
  }
From guo@cup.hp.com Fri Dec 17 17:03:00 1999
From: Jimmy Guo <guo@cup.hp.com>
To: David Taylor <taylor@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: (patch) hpjyg03: (buildsym|language).[ch]
Date: Fri, 17 Dec 1999 17:03:00 -0000
Message-id: <Pine.LNX.4.10.9912171658310.8681-100000@hpcll168.cup.hp.com>
References: <199912172347.SAA29264@texas.cygnus.com>
X-SW-Source: 1999-q4/msg00406.html
Content-length: 1597

Oops.

Yes what was submitted in this patch wasn't the complete thing -- the
language.c changes in the hpjyg20 patch fixes this problem.

- Jimmy Guo, guo@cup.hp.com

>It has been noticed that the language.c portion of this patch causes
>additional noise at startup.  Namely:
>
>    warning: Unrecognized range check setting: "auto; currently off"
>
>I'm curious as to whether this message gets printed at HP (or are
>there other language.c patches not yet submitted that get rid of it).
>
>In any case, here's a patch to eliminate that noise:
>
>taylor@texas 548: cvs diff -c language.c
>Index: language.c
>===================================================================
>RCS file: /cvs/cvsfiles/devo/gdb/language.c,v
>retrieving revision 2.68
>diff -c -r2.68 language.c
>*** language.c  1999/12/13 18:00:13     2.68
>--- language.c  1999/12/17 23:26:48
>***************
>*** 1578,1589 ****
>    add_language (&auto_language_defn);
>  
>    language = savestring ("auto", strlen ("auto"));
>-   range = savestring ("auto", strlen ("auto"));
>-   type = savestring ("auto", strlen ("auto"));
>- 
>-   /* Have the above take effect */
>- 
>    set_language_command (language, 0);
>    set_type_command (NULL, 0);
>    set_range_command (NULL, 0);
>  }
>--- 1578,1588 ----
>    add_language (&auto_language_defn);
>  
>    language = savestring ("auto", strlen ("auto"));
>    set_language_command (language, 0);
>+ 
>+   type = savestring ("auto", strlen ("auto"));
>    set_type_command (NULL, 0);
>+ 
>+   range = savestring ("auto", strlen ("auto"));
>    set_range_command (NULL, 0);
>  }

Re: Merge of ARM Linux port with existing ARM code...

[Scott Bambrough]

Stan Shebs wrote:
> 
> You're right about the size of the descrepancy between -O0 and -O2,
> but I think it's going a bit far to say "there is no point in
> debugging unoptimized code".  Almost all of my own debugging work is
> done on unoptimized code.

I agree with you in fact.  But in many cases when I had problems they
only occurred in optimized code.   The problem goes away or never
occurred in unoptimized code.  Which was really the point I wanted to
make.

> GDB's official position on optimized code is to allow the debugger to
> work with it, but not to promise very much functionality.  -O2 in GCC
> includes ever-more-aggressive optimizations, and it's going to be hard
> or impossible for GDB to reconstruct the original code in all cases.
> Conditional moves are a primo example - you have a single instruction
> that is an amalgam of several source lines, and you want GDB to
> present the illusion that it can do several statement-level steps,
> when the actual hardware will do only one instruction-level step.  For
> GDB, an instruction-level step is an atomic operation.  How do you
> divide up an atom?  (Use a cyclotron, of course :-) )

The problem is much more general on the ARM.  Every instruction is
conditional, or can be anyway.  If you put a breakpoint on such an
instruction the breakpoint is executed unconditionally currently even if
the execution is conditional.  If you ignore high level languages
altogether and assume only assembler source.

cmp 	r0, #0
suble	r1, r2, r3
addgt	r1, r2, r3

If the above construct is part of a loop, placing a breakpoint on the
subtraction operation causes it to break once per loop.  What if you are
only interested in the case when the instruction is actually executed? 
Say it is only executed once in a million iterations of the loop.  You
can hit a lot of breakpoints before you get to the point the instruction
is actually executed.  Why not let the CPU decide if a breakpoint is
required by using the condition predicate for the instruction in the
breakpoint instruction?

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From jimb@cygnus.com Wed Dec 15 23:52:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: law@cygnus.com
Cc: Srikanth Adayapalam <srikanth@cup.hp.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: (patch) hpjyg09: bcache optimizations
Date: Wed, 15 Dec 1999 23:52:00 -0000
Message-id: <npogbr5nmr.fsf@zwingli.cygnus.com>
References: <970.945248225@upchuck>
X-SW-Source: 1999-q4/msg00396.html
Content-length: 1101

>   > > 	While it is true that it is not tied to the microprocessor,
>   > > (and the placement of the macro is not ideal perhaps,) it is tied 
>   > > somewhat to the HP-UX platform in that :
>   > 
>   > Ahh.  That, I didn't know.  So it would be correct to put the flag in
>   > a file associated with a particular toolchain.
> Not in this case.  While HP's tools arrange (via pxdb) to avoid duplicates,
> other HP toolchains do not.
> 
> Short term none of the GNU toolchains on the PA remove duplicates.  That will
> likely change for the PA64 toolchain (dwarf2 + elf), but it is unlikely to 
> ever change for the PA32 toolchain (stabs + som).
> 
> In general, if we find ourselves tuning towards one particular
> toolchain, then we are probably going down the wrong road.

As it turned out, I rewrote the bcache so it works better.  I haven't
heard back from HP on this, but I suspect its overhead is now low
enough that they wouldn't have noticed it to begin with.  So, as
symtab maintainer, hpjyg09 is now dead, until I hear an explanation of
why the changes to the bcache were insufficient.
From law@cygnus.com Thu Dec 16 00:03:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com, dnovillo@cygnus.com
Subject: Re: getting patches organized 
Date: Thu, 16 Dec 1999 00:03:00 -0000
Message-id: <4586.945331241@upchuck>
References: <199911172343.SAA28254@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00397.html
Content-length: 1872

  In message < 199911172343.SAA28254@zwingli.cygnus.com >you write:
  > 
  > As folks have probably figured out, I'm beginning to have a hard time
  > keeping track of the patches that I'm responsible for reviewing, which
  > patches I have reviewed, whether the submitter has gotten back to me
  > about my comments, etc.
  > 
  > This situation is worsened when some urgent issue appears on some
  > Cygnus project I'm responsible for, and I have to focus on that for a
  > few weeks.  When I come back, it's difficult for me to recover all the
  > state I'd built up before I was drawn away.
  > 
  > It's been suggested that we could use a bug-tracking system like GNATS
  > or Bugzilla as a patch-tracking system.  We'd change the status values
  > to some set like "Awaiting-Review", "Awaiting-Revision", "Approved",
  > "Applied", "Rejected", "Withdrawn", or whatever.
  > 
  > The only system I'm really familiar with is GNATS.  GNATS can
  > automatically stash E-mail conversation related to a patch in the
  > patch record ("PR"), which is exactly what we want.  It's got web
  > interfaces, a decent query ability, and so on.  So I think it would
  > work great.
  > 
  > What would the folks on this list who are actually submitting patches
  > want from such a system?  Certainly all the data would be public.
  > What else should we worry about?
Note that we're looking into setting something similar up for GCC;  we
were going to initially try to deploy something for use internally within 
Cygnus's GCC group first, tune it, then try to deploy it for all GCC patches.

There isn't anything directly designed for patch tracking, but like y'all we
came to the conclusion that packages with do a good job at bug tracking
ought to be adaptable.

Diego -- can you forward that initial summary you sent to the Cygnus GCC team
to the Jim & the GDB folks.

jeff