Re: bug in arm_push_arguments()

Re: bug in arm_push_arguments()

[Andrew Cagney]

Scott Bambrough wrote:
> 
> Hi guys,
> 

>           /* Convert the double to TARGET byte order and swap things to
>              conform to the ARM floating point layout.  */
>           memcpy (bufd, bufo + len / 2, len / 2);
>           SWAP_TARGET_AND_HOST (bufd, len / 2);  /* adjust endianess */
>           memcpy (bufd + len / 2, bufo, len / 2);
>           SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */
>           val = (char *) &dbl_arg;
> 
> This is ok, but the code for the last step is unnecessarily complex.  I think
> something similar to the following should suffice.
> 
>           int tmp;
>	    int *buf = &d;
>           SWAP_TARGET_AND_HOST (&d, sizeof (double));
>           tmp = buf[0];
>           buf[0] = buf[1];
>           buf[1] = tmp;
> 
> I think this will result in better code from the compiler.  There are a couple
> of problems though with this code.  First what happens if sizeof (TARGET_DOUBLE)
> != sizeof (HOST_DOUBLE).  Second, this breaks in the native case, because the
> double is already in the right format. This is why I have regressions I believe
> (I have yet to test my theory).  Is there a clean way to solve these problems?

FYI, my guess would be that the author didn't want to make any
assumptions about sizeof(int), sizeof(double) and their ratios.  Those
things are just too changeable.

(The cast/memory poke ``(f = *(float*)d)'' is also non-portable but I
won't mention that :-)

Kevin Buttner wrote:
> It seems to me that you should be able to use store_floating() to do
> what you want.  It'll handle both the conversion and the byte swapping.

Yes, that looks correct. I'm just not 100% sure on it working - would
one of those if()'s before the TARGET_EXTRACT_FLOATING() get in the way?

	Andrew
From ac131313@cygnus.com Mon Feb 28 04:08:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: P.Leggett@gre.ac.uk
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb functionality query
Date: Mon, 28 Feb 2000 04:08:00 -0000
Message-id: <38BA6506.241FCCF4@cygnus.com>
References: <20000228114844.A3717@gre.ac.uk>
X-SW-Source: 2000-02/msg00040.html
Content-length: 1664

Peter Leggett wrote:
> 
> Hello,
> 
> I hope that this list is the appropriate one to ask a general
> gdb question. If not please excuse this mail.
> 
> The research group I work in uses the Sun debugger/dbx which has some
> these extremly useful features without which we would find debugging
> our codes much harder. We are now also running on linux boxes
> and are exploring the possibilites of gdb.
> 
> I would very much appreciate it if anyone could tell me if gdb has
> the following specific functionality:-
> 
> a) Ability to pop program call frame stack and then continue. I know one
>    can browse up and down the frames in gdb but can one pop it and
>    continue from a calling frame up the stack.

Yes:

(gdb) help return
Make selected stack frame return to its caller.
Control remains in the debugger, but when you continue
execution will resume in the frame above the one now selected.
If an argument is given, it is an expression for the value to return.

(gdb) help finish
Execute until selected stack frame returns.
Upon return, the value returned is printed and put in the value history.

> b) make an arbitary call to user code (with possibly arguments and
>    expressions) from gdb  and break point within that call etc..
>    e.g.
> 
>    gdb-> break usersub
>    gdb-> call usersub(a,fred+2,jim*2+1)
>    ...
> 
>    where a, fred and kim are user variables.

Yes:

The commands are even identical.

(gdb) help call
Call a function in the program.
The argument is the function name and arguments, in the notation of the
current working language.  The result is printed and saved in the value
history, if it is not void.

	enjoy,
		Andrew
From xbestel@aplio.fr Mon Feb 28 06:44:00 2000
From: "Xavier Bestel" <xbestel@aplio.fr>
To: <gdb@sourceware.cygnus.com>
Subject: single-step
Date: Mon, 28 Feb 2000 06:44:00 -0000
Message-id: <03a601bf81fa$3eed2800$30fd62c2@aplio.fr>
X-SW-Source: 2000-02/msg00041.html
Content-length: 453

Hi !

I have and ARM dev board hooked to a Jeeni, controlled via ethernet. It
doesn't singl-step, it only stops at breakpoints. When I issue a "info
target", gdb replies that "Target can't single-step".
However I would greatly appreciate it to single step to debug my apps ...
So do you know how to fix it ? Is it a hardware non-feature or a simple
software misconfiguration ? Can gdb emulate singlestepping transparently
using breakpoints ?

    Xav

store_floating() rewrite (was Re: bug in arm_push_arguments())

[Kevin Buettner]

On Feb 28, 11:03pm, Andrew Cagney wrote:

> Kevin Buttner wrote:
> > It seems to me that you should be able to use store_floating() to do
> > what you want.  It'll handle both the conversion and the byte swapping.
> 
> Yes, that looks correct. I'm just not 100% sure on it working - would
> one of those if()'s before the TARGET_EXTRACT_FLOATING() get in the way?
                                 ^^^^^^^^^^^^^^^^^^^^^^^

Did you mean TARGET_STORE_FLOATING?

The part that bothers me about the way that store_floating() is
implemented is that we're comparing the size of the thing we're trying
to store into (on the target) against sizes of the host formats.  I.e,
the following lines bother me.

  if (len == sizeof (float))
  else if (len == sizeof (double))
  else if (len == sizeof (DOUBLEST))

I think we should be comparing against the sizes of the target formats.

Suppose, for example, that we have the following configuration

    host float:		32 bits
    host double		64 bits
    target float	64 bits
    target double	128 bits

and that we enter store_floating with len == 8.

This'll cause us to wind up in the following code:

  else if (len == sizeof (double))
    {
      if (HOST_DOUBLE_FORMAT == TARGET_DOUBLE_FORMAT)
	{
	  double doubleval = val;

	  memcpy (addr, &doubleval, sizeof (doubleval));
	}
      else
	floatformat_from_doublest (TARGET_DOUBLE_FORMAT, &val, addr);
    }

Because the sizes of the doubles are different, HOST_DOUBLE_FORMAT
will not be the same as TARGET_DOUBLE_FORMAT.  This means that we'll
execute the floatformat_from_doublest call which attempts to store a
(target) double.

But this is wrong since the size of a target double is 16 bytes and we
were attempting to store a floating point value whose size is 8 bytes.

Here is my rewrite of this function:

void
store_floating (void *addr, int len, DOUBLEST val)
{
  if (HOST_FLOAT_FORMAT == TARGET_FLOAT_FORMAT)
    {
      float floatval = val;

      memcpy (addr, &floatval, sizeof (floatval));
    }
  else if (HOST_DOUBLE_FORMAT == TARGET_DOUBLE_FORMAT)
    {
      double doubleval = val;

      memcpy (addr, &doubleval, sizeof (doubleval));
    }
  else if (HOST_LONG_DOUBLE_FORMAT == TARGET_LONG_DOUBLE_FORMAT)
    memcpy (addr, &val, sizeof (val));
  else if (len * TARGET_CHAR_BIT == TARGET_FLOAT_BIT)
    floatformat_from_doublest (TARGET_FLOAT_FORMAT, &val, addr);
  else if (len * TARGET_CHAR_BIT == TARGET_DOUBLE_BIT)
    floatformat_from_doublest (TARGET_DOUBLE_FORMAT, &val, addr);
  else if (len * TARGET_CHAR_BIT == TARGET_LONG_DOUBLE_BIT)
    floatformat_from_doublest (TARGET_LONG_DOUBLE_FORMAT, &val, addr);
#ifdef TARGET_STORE_FLOATING
  else if (TARGET_STORE_FLOATING (addr, len, val))
    return;
#endif 
  else
    error ("Can't deal with a floating point number of %d bytes.", len);
}

Re: store_floating() rewrite (was Re: bug in arm_push_arguments())

[Mark Kettenis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 49150 bytes --]

   Date: Mon, 28 Feb 2000 11:11:42 -0700
   From: Kevin Buettner <kevinb@cygnus.com>

   On Feb 28, 11:03pm, Andrew Cagney wrote:

   > Kevin Buttner wrote:
   > > It seems to me that you should be able to use store_floating() to do
   > > what you want.  It'll handle both the conversion and the byte swapping.
   > 
   > Yes, that looks correct. I'm just not 100% sure on it working - would
   > one of those if()'s before the TARGET_EXTRACT_FLOATING() get in the way?
				    ^^^^^^^^^^^^^^^^^^^^^^^

   Did you mean TARGET_STORE_FLOATING?

Andrew was probably looking at extract_floating() which suffers from
the same braindamage as you describe.  This needs to be fixed,
and I think your patch is basically right.  Apart from store_floating
and extract_floating, there are probably some other functions where
the same assumptions are made.

However, keep in mind that we must guard for loss of precision.  What
should store_floating do if DOUBLEST (which "lives" on the host) has
less precision than the target type in which it is being stored?  This
is also a problem with a somewhat wider scope.  There is no explicit
policy in GDB on which operations are allowed to lose precision, and
which operations are not supposed to lose precision.  I think that if
we're going to address the issues raised here, we must determine such
a policy, and document it.

Please also keep in mind that TARGET_STORE_FLOATING and
TARGET_EXTRACT_FLOATING really should be eliminated.  They are part of
a workaround for the problem that's being adressed now and are only
used on Linux/i386.

Mark
From tromey@cygnus.com Mon Feb 28 11:43:00 2000
From: Tom Tromey <tromey@cygnus.com>
To: Gdb List <gdb@sourceware.cygnus.com> 
Subject: breakpoint ignore counts
Date: Mon, 28 Feb 2000 11:43:00 -0000
Message-id: <87k8jpcduv.fsf@cygnus.com>
X-SW-Source: 2000-02/msg00049.html
Content-length: 874

A while back I asked whether it would be ok to make this code in
target.c unconditional:

  /* It is confusing to the user for ignore counts to stick around
     from previous runs of the inferior.  So clear them.  */
  /* However, it is more confusing for the ignore counts to disappear when
     using hit counts.  So don't clear them if we're counting hits.  */
  if (!show_breakpoint_hit_counts)
    breakpoint_clear_ignore_counts ();

I wanted this because I accidentally typed "c 57" instead of "b 57"
one day, and was suprised when my next "r" command just ran past my
breakpoints.

Today I figured out why I don't want this change -- lately I've taken
to using "ignore <bp> <count>" followed by "r".  So really what I want
is for a hit count to be cleared if it was set by "c", but to remain
if it was set by "ignore".  I imagine this is too magical for gdb...

Tom
From kingdon@redhat.com Mon Feb 28 12:45:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: store_floating() rewrite (was Re: bug in arm_push_arguments())
Date: Mon, 28 Feb 2000 12:45:00 -0000
Message-id: <bln453w9f.fsf@rtl.cygnus.com>
References: <38B6C4A1.7A1461C4@netwinder.org> <38BA642A.6F358273@cygnus.com> <1000228181141.ZM26089@ocotillo.lan> <200002281929.UAA03907@landau.wins.uva.nl>
X-SW-Source: 2000-02/msg00050.html
Content-length: 804

> There is no explicit policy in GDB on which operations are allowed to
> lose precision, and which operations are not supposed to lose
> precision.  I think that if we're going to address the issues raised
> here, we must determine such a policy, and document it.

Well, I think the intended policy (which probably isn't 100% true of
the current implementation) is that precision should be kept when it
is possible/feasible to do so, and that otherwise GDB can lose
precision.

That's bad in the sense that the user doesn't get a clear expectation,
but what's the alternative?  Give an error if we would lose precision
(is there even a general enough way to detect this?  I don't see the
machinery for it now)?

P.S. Kevin Buettner's store_floating rewrite looked about right to me
too.
From jimb@cygnus.com Mon Feb 28 13:14:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: patch database proposal
Date: Mon, 28 Feb 2000 13:14:00 -0000
Message-id: <np4satni7a.fsf@zwingli.cygnus.com>
References: <200002251827.NAA09955@zwingli.cygnus.com> <200002281631.RAA03314@landau.wins.uva.nl>
X-SW-Source: 2000-02/msg00051.html
Content-length: 1401

>    Here's a tentative proposal for how the patch database should work.
>    In reality, a good part of this is set up and ready to go, but there's
>    nothing we can't revise, in the presence of good ideas or persuasive
>    criticism.
> 
>    Please let me know what you think; post your comments to the list.
> 
> Looks good to me.  We'll probably want to phase out gdb-patches in
> favour of gdb-patches-prs.
> 
> It is hard to estimate the amount of work the patch secretary has to
> do, but if it's a lot, we could have multiple secretaries.  A bit like
> multiple maintainers but with the difference that all of them can work
> together.  GNATS locking should take care of avoiding duplicate work.
> 
> I think it should also be possible for maintainers to enter patches as
> `applied' by sending a *single* message, without the need of further
> manipulation of the database (to replace the current practice of
> maintainers sending a patch to gdb-patches for work they did
> themselves).

Yes, these are the two open questions:

- What happens to gdb-patches?  It seems to me that since gdb-patches
  is for conversations about specific patches (or we could define it
  that way), so it gets replaced by gdb-patches-prs.

- Given that every state change generates a message to
  gdb-patches-prs, is it possible and convenient to keep the number of
  messages down to the minimum necessary?
From jimb@cygnus.com Mon Feb 28 13:29:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: Schlosser Lukas <lukas.schlosser@siemens.at>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Symbolic Interpretation in GNU world.
Date: Mon, 28 Feb 2000 13:29:00 -0000
Message-id: <np1z5xnhhp.fsf@zwingli.cygnus.com>
References: <200002251926.OAA20810@mescaline.gnu.org>
X-SW-Source: 2000-02/msg00052.html
Content-length: 4623

GDB could do what you want, but it seems like an awfully painful and
indirect way to do something pretty simple.

The painful way:

Assuming that the architecture of your VxWorks board is something GDB
supports, and has a simulator for (check the sim directory of the GDB
source tree), you could:

- build a full cross toolchain --- compiler, assembler, libraries,
  debugger --- for your VxWorks board's architecture
- write your dummy program
- run your dummy program on the simulator

The easy way:

It seems to me it'd take twenty minutes to hack up a Perl script that
uses 'unpack' to print out your log.



> 
> Hello,
> 
> I posted the attached mail on February 2nd, 2000 to 'bug-gdb@gnu.org' 
> - but I didn't get any response till now. I have to reach a decision, please
> help me!
> Due to the fact, that this was the only gdb newsgoup I found, I hope that
> you can name me a correct contact person to find the answer onto the
> following
> urgent questions:
> 
> (1)
> Does GNU somehow provide the "offline symbolic interpretation"
> functionality described below? (incl. big endian / little endian problem -
> meanwhile
> solved by disabling the appropriate #DEFINE!)
> 
> (2)
> If it is not provided and we realize the described approach, what
> exactly is the further proceeding? Do you centrally manage such
> enhancements?
> 
> 
> Mit freundlichen Grüßen / Best regards,
> Lukas Schlosser
> 
> --
> 
> Siemens AG Österreich
> Siemensstraße 88-92 / Bau 16
> A-1211 Wien
> 
> PSE TN SES15 (SIE)
> Tel: +43 51707 / 25262, Fax: +43 51707 / 55241
> Mail: Lukas.Schlosser@siemens.at < mailto:Lukas.Schlosser@siemens.at >
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Schlosser Lukas 
> > Gesendet am: Mittwoch, 02. Februar 2000 16:49
> > An: bug-gdb@gnu.org < mailto:bug-gdb@gnu.org >
> > Betreff: gdb extension?
> > Wichtigkeit: Hoch
> > 
> > Hello,
> > 
> > I have to find out (very urgently), whether I can extend the 
> > gdb for offline symbolic interpretation, but I have a big 
> > problem with "Big Endian" and "Little Endian" format:
> > 
> > I collect trace data (more or less C-structs) on a "big 
> > endian" machine (running on VxWorks) and write it to a buffer. 
> > This buffer is transferred to an NT PC ("little endian"), 
> > where it should be symbolically interpreted. 
> > (Please see attached example for details).
> > 
> > I thought of using the functionality of gdb in the following way:
> > .) I start the gdb under WinNT and load a simple program "dummy.exe".
> > .) Then I load the debug information, which was produced for 
> > the original machine ("big endian"). I tried already, and 
> > this is possible.
> > .) Then I set a breakpoint at a certain place in "dummy.exe", 
> > whose functionality is to read the whole trace buffer into 
> > the memory. 
> > .) I run the program and it automatically stops after having 
> > read the whole buffer into memory.
> > .) I can determine where this memory region starts, I know 
> > which datatype was traced at which position in my buffer -> 
> > by means of simple type casts giving a certain address 
> > (offset in buffer combined with start address of memory 
> > area), gdb automtically shows the detailed structure of the 
> > given data, just in the wrong format.
> > 
> > ==> The only problem is: How is it possible to let gdb 
> > interpret the raw data as "Big Endian" although it is running 
> > on an "Little Endian" Machine. The command "set endian big" 
> > does not work, it gives error message: "Byte order is not selectable".
> > 
> > Thanks for your help,
> > Lukas Schlosser.
> > 
> > Example:
> > <file://----------------------->
> > class MyClass
> > {
> > private:
> > int m_i ; // Integer Data with size as 4Bytes
> > bool m_b ; // Boolean data with size as 1Byte
> > };
> > <file://--------------------->
> > 
> > When this module is compiled by GNU C++, all the 
> > debugging information
> > (like, the class name, names of each data member, 
> > their types,size etc)
> > are stored in the \"stabs\".
> > 
> > Now, I get the following string from a dump tool:
> > H\'000FFF00
> > 
> > Now I want to map these values to the corresponding 
> > data members in MyClass. 
> > i.e.. A tool should load the \"stabs\", read the 
> > information for class
> > MyClass. It finds that there is a data member named 
> > \"m_i\" which is of
> > type int. It means, its size will be 4Bytes. So from 
> > the hex dump, it
> > extracts 4 Bytes and assign to the data member. So the 
> > output of this
> > tool should be:
> >
> > <file://-------->
> > m_i = H\'000FFF
> > m_b = H\'00
> > <file://-------->
> 
> 
From kevinb@cygnus.com Mon Feb 28 18:20:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: Re: store_floating() rewrite (was Re: bug in arm_push_arguments())
Date: Mon, 28 Feb 2000 18:20:00 -0000
Message-id: <1000229022012.ZM15262@ocotillo.lan>
References: <38B6C4A1.7A1461C4@netwinder.org> <38BA642A.6F358273@cygnus.com> <1000228181141.ZM26089@ocotillo.lan> <kevinb@cygnus.com>
X-SW-Source: 2000-02/msg00053.html
Content-length: 1524

I'm not sure whether the following was being considered as a patch,
but if so, it is withdrawn.  I've sent a proper patch to gdb-patches
which fix the problems that this rewrite was trying to address.  (As
written, the code below does not take into account the size of the
float type for doing the memcpy in the event that the host and target
float formats are the same.)

On Feb 28, 11:11am, Kevin Buettner wrote:

> Here is my rewrite of this function:
> 
> void
> store_floating (void *addr, int len, DOUBLEST val)
> {
>   if (HOST_FLOAT_FORMAT == TARGET_FLOAT_FORMAT)
>     {
>       float floatval = val;
> 
>       memcpy (addr, &floatval, sizeof (floatval));
>     }
>   else if (HOST_DOUBLE_FORMAT == TARGET_DOUBLE_FORMAT)
>     {
>       double doubleval = val;
> 
>       memcpy (addr, &doubleval, sizeof (doubleval));
>     }
>   else if (HOST_LONG_DOUBLE_FORMAT == TARGET_LONG_DOUBLE_FORMAT)
>     memcpy (addr, &val, sizeof (val));
>   else if (len * TARGET_CHAR_BIT == TARGET_FLOAT_BIT)
>     floatformat_from_doublest (TARGET_FLOAT_FORMAT, &val, addr);
>   else if (len * TARGET_CHAR_BIT == TARGET_DOUBLE_BIT)
>     floatformat_from_doublest (TARGET_DOUBLE_FORMAT, &val, addr);
>   else if (len * TARGET_CHAR_BIT == TARGET_LONG_DOUBLE_BIT)
>     floatformat_from_doublest (TARGET_LONG_DOUBLE_FORMAT, &val, addr);
> #ifdef TARGET_STORE_FLOATING
>   else if (TARGET_STORE_FLOATING (addr, len, val))
>     return;
> #endif 
>   else
>     error ("Can't deal with a floating point number of %d bytes.", len);
> }
From france@crl.dec.com Tue Feb 29 08:15:00 2000
From: George France <france@crl.dec.com>
To: "'Xavier Bestel'" <xbestel@aplio.fr>, gdb@sourceware.cygnus.com
Subject: RE: single-step
Date: Tue, 29 Feb 2000 08:15:00 -0000
Message-id: <D1674834F25BD3118B3208002BB90CD424AAC9@yen.crl.dec.com>
X-SW-Source: 2000-02/msg00054.html
Content-type: multipart/mixed; boundary="----------=_1583534238-23286-0"

This is a multi-part message in MIME format...

------------=_1583534238-23286-0
Content-length: 1102

Hello Xavier;

Which ARM dev board do you have??  I have attached a patch for ptrace.c for
Linux 2.2.14 that will allow you to single step on the armv4l architecture.
The patch implements PTRACE_GETREGS, PTRACE_SETREGS, PTRACE_GETFPREGS &
PTRACE_SETREGS, with PTRACE_SET_BPT etc....

Best Regards,



--George

George France,      france@crl.dec.com
Cambridge Research Laboratory, Compaq Computer Corporation
One Kendall Square, Building 700     MS: CRL
Cambridge, MA 02139 USA



-----Original Message-----
From: Xavier Bestel [ mailto:xbestel@aplio.fr ]
Sent: Monday, February 28, 2000 9:44 AM
To: gdb@sourceware.cygnus.com
Subject: single-step


Hi !

I have and ARM dev board hooked to a Jeeni, controlled via ethernet. It
doesn't singl-step, it only stops at breakpoints. When I issue a "info
target", gdb replies that "Target can't single-step".
However I would greatly appreciate it to single step to debug my apps ...
So do you know how to fix it ? Is it a hardware non-feature or a simple
software misconfiguration ? Can gdb emulate singlestepping transparently
using breakpoints ?

    Xav



------------=_1583534238-23286-0
Content-Type: text/x-diff; charset=us-ascii; name="ptrace-for-2.2.14-patch"
Content-Disposition: inline; filename="ptrace-for-2.2.14-patch"
Content-Transfer-Encoding: base64
Content-Length: 18780

LS0tIC9za2lmZi9qYW1leS9saW51eC0yLjIuMTQtcm1rMy1jcmwxL2luY2x1
ZGUvYXNtLWFybS9wdHJhY2UuaAlUdWUgSmFuIDE4IDE4OjEzOjA5IDIwMDAK
KysrIC91c3Ivc3JjL2xpbnV4L2luY2x1ZGUvYXNtLWFybS9wdHJhY2UuaAlX
ZWQgSmFuIDI2IDAxOjIxOjM3IDIwMDAKQEAgLTMsNiArMywxMyBAQAogCiAj
aW5jbHVkZSA8YXNtL3Byb2MvcHRyYWNlLmg+CiAKKworI2RlZmluZSBQVFJB
Q0VfR0VUUkVHUwkJMTIKKyNkZWZpbmUgUFRSQUNFX1NFVFJFR1MJCTEzCisj
ZGVmaW5lIFBUUkFDRV9HRVRGUFJFR1MJMTQKKyNkZWZpbmUgUFRSQUNFX1NF
VEZQUkVHUwkxNQorCisKICNpZmRlZiBfX0tFUk5FTF9fCiBleHRlcm4gdm9p
ZCBzaG93X3JlZ3Moc3RydWN0IHB0X3JlZ3MgKik7CiAjZW5kaWYKLS0tIC9z
a2lmZi9qYW1leS9saW51eC0yLjIuMTQtcm1rMy1jcmwxL2luY2x1ZGUvYXNt
LWFybS9wcm9jZXNzb3IuaAlUdWUgSmFuIDE4IDE4OjEzOjA5IDIwMDAKKysr
IC91c3Ivc3JjL2xpbnV4L2luY2x1ZGUvYXNtLWFybS9wcm9jZXNzb3IuaAlX
ZWQgSmFuIDI2IDAxOjIxOjUxIDIwMDAKQEAgLTMyLDEyICszMiwyMCBAQAog
I2luY2x1ZGUgPGFzbS9hcmNoL3Byb2Nlc3Nvci5oPgogI2luY2x1ZGUgPGFz
bS9wcm9jL3Byb2Nlc3Nvci5oPgogCitzdHJ1Y3QgZGVidWdfaW5mbyB7CisJ
aW50CQkJCW5zYXZlZDsKKwlzdHJ1Y3QgeworCQl1bnNpZ25lZCBsb25nCQlh
ZGRyZXNzOworCQl1bnNpZ25lZCBsb25nCQlpbnNuOworCX0gYnBbMl07Cit9
OworCiBzdHJ1Y3QgdGhyZWFkX3N0cnVjdCB7CiAJdW5zaWduZWQgbG9uZwkJ
CWFkZHJlc3M7CSAgLyogQWRkcmVzcyBvZiBmYXVsdAkqLwogCXVuc2lnbmVk
IGxvbmcJCQl0cmFwX25vOwkgIC8qIFRyYXAgbnVtYmVyCSovCiAJdW5zaWdu
ZWQgbG9uZwkJCWVycm9yX2NvZGU7CSAgLyogRXJyb3IgY29kZSBvZiB0cmFw
CSovCiAJdW5pb24gZnBfc3RhdGUJCQlmcHN0YXRlOwkgIC8qIEZQRSBzYXZl
IHN0YXRlCSovCi0JdW5zaWduZWQgbG9uZwkJCWRlYnVnW05SX0RFQlVHU107
IC8qIERlYnVnL3B0cmFjZQkqLworCXN0cnVjdCBkZWJ1Z19pbmZvCQlkZWJ1
ZzsgICAgICAgICAgICAvKiBEZWJ1Zy9wdHJhY2UJKi8KIAlzdHJ1Y3QgY29u
dGV4dF9zYXZlX3N0cnVjdAkqc2F2ZTsJCSAgLyogY29udGV4dCBzYXZlCSov
CiAJdW5zaWduZWQgbG9uZwkJCW1lbW1hcDsJCSAgLyogcGFnZSB0YWJsZXMJ
Ki8KIAlFWFRSQV9USFJFQURfU1RSVUNUCi0tLSAvc2tpZmYvamFtZXkvbGlu
dXgtMi4yLjE0LXJtazMtY3JsMS9hcmNoL2FybS9rZXJuZWwvcHRyYWNlLmMJ
VHVlIEphbiAxOCAxODowNjoxMyAyMDAwCisrKyAvdXNyL3NyYy9saW51eC9h
cmNoL2FybS9rZXJuZWwvcHRyYWNlLmMJV2VkIEphbiAyNiAwMToyMTozOCAy
MDAwCkBAIC0xMiwxMCArMTIsMTMgQEAKICNpbmNsdWRlIDxsaW51eC9wdHJh
Y2UuaD4KICNpbmNsdWRlIDxsaW51eC91c2VyLmg+CiAKKwogI2luY2x1ZGUg
PGFzbS91YWNjZXNzLmg+CiAjaW5jbHVkZSA8YXNtL3BndGFibGUuaD4KICNp
bmNsdWRlIDxhc20vc3lzdGVtLmg+CiAKKworCiAvKgogICogZG9lcyBub3Qg
eWV0IGNhdGNoIHNpZ25hbHMgc2VudCB3aGVuIHRoZSBjaGlsZCBkaWVzLgog
ICogaW4gZXhpdC5jIG9yIGluIHNpZ25hbC5jLgpAQCAtMjYsMzcgKzI5LDkg
QEAKICAqLwogI2RlZmluZSBCUkVBS0lOU1QJMHhlZjlmMDAwMQogCi0vKgot
ICogdGhpcyByb3V0aW5lIHdpbGwgZ2V0IGEgd29yZCBvZmYgb2YgdGhlIHBy
b2Nlc3NlcyBwcml2aWxlZ2VkIHN0YWNrLgotICogdGhlIG9mZnNldCBpcyBo
b3cgZmFyIGZyb20gdGhlIGJhc2UgYWRkciBhcyBzdG9yZWQgaW4gdGhlIFRT
Uy4KLSAqIHRoaXMgcm91dGluZSBhc3N1bWVzIHRoYXQgYWxsIHRoZSBwcml2
aWxlZ2VkIHN0YWNrcyBhcmUgaW4gb3VyCi0gKiBkYXRhIHNwYWNlLgotICov
Ci1zdGF0aWMgaW5saW5lIGxvbmcgZ2V0X3N0YWNrX2xvbmcoc3RydWN0IHRh
c2tfc3RydWN0ICp0YXNrLCBpbnQgb2Zmc2V0KQotewotCXVuc2lnbmVkIGNo
YXIgKnN0YWNrOwogCi0Jc3RhY2sgPSAodW5zaWduZWQgY2hhciAqKSgodW5z
aWduZWQgbG9uZyl0YXNrICsgODE5MiAtIHNpemVvZihzdHJ1Y3QgcHRfcmVn
cykpOwotCXN0YWNrICs9IG9mZnNldCA8PCAyOwotCXJldHVybiAqKHVuc2ln
bmVkIGxvbmcgKilzdGFjazsKLX0KIAotLyoKLSAqIHRoaXMgcm91dGluZSB3
aWxsIHB1dCBhIHdvcmQgb24gdGhlIHByb2Nlc3NlcyBwcml2aWxlZ2VkIHN0
YWNrLgotICogdGhlIG9mZnNldCBpcyBob3cgZmFyIGZyb20gdGhlIGJhc2Ug
YWRkciBhcyBzdG9yZWQgaW4gdGhlIFRTUy4KLSAqIHRoaXMgcm91dGluZSBh
c3N1bWVzIHRoYXQgYWxsIHRoZSBwcml2aWxlZ2VkIHN0YWNrcyBhcmUgaW4g
b3VyCi0gKiBkYXRhIHNwYWNlLgotICovCi1zdGF0aWMgaW5saW5lIGxvbmcg
cHV0X3N0YWNrX2xvbmcoc3RydWN0IHRhc2tfc3RydWN0ICp0YXNrLCBpbnQg
b2Zmc2V0LAotCXVuc2lnbmVkIGxvbmcgZGF0YSkKLXsKLQl1bnNpZ25lZCBj
aGFyICpzdGFjazsKIAotCXN0YWNrID0gKHVuc2lnbmVkIGNoYXIgKikoKHVu
c2lnbmVkIGxvbmcpdGFzayArIDgxOTIgLSBzaXplb2Yoc3RydWN0IHB0X3Jl
Z3MpKTsKLQlzdGFjayArPSBvZmZzZXQgPDwgMjsKLQkqKHVuc2lnbmVkIGxv
bmcgKikgc3RhY2sgPSBkYXRhOwotCXJldHVybiAwOwotfQogCiAvKgogICog
VGhpcyByb3V0aW5lIGdldHMgYSBsb25nIGZyb20gYW55IHByb2Nlc3Mgc3Bh
Y2UgYnkgZm9sbG93aW5nIHRoZSBwYWdlCkBAIC0xNzMsNiArMTQ4LDcgQEAK
IAkJZm9yY2Vfc2lnKFNJR0tJTEwsIHRzayk7CiB9CiAKKwogc3RhdGljIHN0
cnVjdCB2bV9hcmVhX3N0cnVjdCAqIGZpbmRfZXh0ZW5kX3ZtYShzdHJ1Y3Qg
dGFza19zdHJ1Y3QgKiB0c2ssIHVuc2lnbmVkIGxvbmcgYWRkcikKIHsKIAlz
dHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKiB2bWE7CkBAIC0xOTIsNiArMTY4LDQy
IEBACiAJcmV0dXJuIHZtYTsKIH0KIAorCisKKy8qCisgKiB0aGlzIHJvdXRp
bmUgd2lsbCBnZXQgYSB3b3JkIG9mZiBvZiB0aGUgcHJvY2Vzc2VzIHByaXZp
bGVnZWQgc3RhY2suCisgKiB0aGUgb2Zmc2V0IGlzIGhvdyBmYXIgZnJvbSB0
aGUgYmFzZSBhZGRyIGFzIHN0b3JlZCBpbiB0aGUgVEhSRUFELgorICogdGhp
cyByb3V0aW5lIGFzc3VtZXMgdGhhdCBhbGwgdGhlIHByaXZpbGVnZWQgc3Rh
Y2tzIGFyZSBpbiBvdXIKKyAqIGRhdGEgc3BhY2UuCisgKi8KK3N0YXRpYyBp
bmxpbmUgbG9uZyBnZXRfc3RhY2tfbG9uZyhzdHJ1Y3QgdGFza19zdHJ1Y3Qg
KnRhc2ssIGludCBvZmZzZXQpCit7CisJc3RydWN0IHB0X3JlZ3MgKnJlZ3M7
CisKKwlyZWdzID0gKHN0cnVjdCBwdF9yZWdzICopKCh1bnNpZ25lZCBsb25n
KXRhc2sgKyA4MTkyIC0gc2l6ZW9mKHN0cnVjdCBwdF9yZWdzKSk7CisKKwly
ZXR1cm4gcmVncy0+dXJlZ3Nbb2Zmc2V0XTsKK30KKworLyoKKyAqIHRoaXMg
cm91dGluZSB3aWxsIHB1dCBhIHdvcmQgb24gdGhlIHByb2Nlc3NlcyBwcml2
aWxlZ2VkIHN0YWNrLgorICogdGhlIG9mZnNldCBpcyBob3cgZmFyIGZyb20g
dGhlIGJhc2UgYWRkciBhcyBzdG9yZWQgaW4gdGhlIFRIUkVBRC4KKyAqIHRo
aXMgcm91dGluZSBhc3N1bWVzIHRoYXQgYWxsIHRoZSBwcml2aWxlZ2VkIHN0
YWNrcyBhcmUgaW4gb3VyCisgKiBkYXRhIHNwYWNlLgorICovCitzdGF0aWMg
aW5saW5lIGxvbmcgcHV0X3N0YWNrX2xvbmcoc3RydWN0IHRhc2tfc3RydWN0
ICp0YXNrLCBpbnQgb2Zmc2V0LAorCXVuc2lnbmVkIGxvbmcgZGF0YSkKK3sK
KwlzdHJ1Y3QgcHRfcmVncyAqcmVnczsKKworCXJlZ3MgPSAoc3RydWN0IHB0
X3JlZ3MgKikoKHVuc2lnbmVkIGxvbmcpdGFzayArIDgxOTIgLSBzaXplb2Yo
c3RydWN0IHB0X3JlZ3MpKTsKKworCXJlZ3MtPnVyZWdzW29mZnNldF0gPSBk
YXRhOworCisJcmV0dXJuIDA7Cit9CisKKwogLyoKICAqIFRoaXMgcm91dGlu
ZSBjaGVja3MgdGhlIHBhZ2UgYm91bmRhcmllcywgYW5kIHRoYXQgdGhlIG9m
ZnNldCBpcwogICogd2l0aGluIHRoZSB0YXNrIGFyZWEuIEl0IHRoZW4gY2Fs
bHMgZ2V0X2xvbmcoKSB0byByZWFkIGEgbG9uZy4KQEAgLTI4Niw2ICsyOTgs
OCBAQAogCXJldHVybiAwOwogfQogCisKKwogLyoKICAqIEdldCB2YWx1ZSBv
ZiByZWdpc3RlciBgcm4nIChpbiB0aGUgaW5zdHJ1Y3Rpb24pCiAgKi8KQEAg
LTI5OSw3ICszMTMsNiBAQAogCWVsc2UKIAkJdmFsID0gZ2V0X3N0YWNrX2xv
bmcgKGNoaWxkLCByZWcpOwogCi1wcmludGsgKCJyJTAyZD0lMDhsWCAiLCBy
ZWcsIHZhbCk7CiAJcmV0dXJuIHZhbDsKIH0KIApAQCAtMzEyLDEyICszMjUs
MTAgQEAKIAlpbnQgc2hpZnQ7CiAJaW50IHR5cGU7CiAKLXByaW50ayAoIm9w
Mj0iKTsKIAlpZiAoaW5zbiAmIDEgPDwgMjUpIHsKIAkJdmFsID0gaW5zbiAm
IDI1NTsKIAkJc2hpZnQgPSAoaW5zbiA+PiA4KSAmIDE1OwogCQl0eXBlID0g
MzsKLXByaW50ayAoIihpbW0pIik7CiAJfSBlbHNlIHsKIAkJdmFsID0gZ2V0
X3N0YWNrX2xvbmcgKGNoaWxkLCBpbnNuICYgMTUpOwogCkBAIC0zMjcsOSAr
MzM4LDcgQEAKIAkJCXNoaWZ0ID0gKGluc24gPj4gNykgJiAzMTsKIAogCQl0
eXBlID0gKGluc24gPj4gNSkgJiAzOwotcHJpbnRrICgiKHIlMDJsZCkiLCBp
bnNuICYgMTUpOwogCX0KLXByaW50ayAoInNoJWR4JWQiLCB0eXBlLCBzaGlm
dCk7CiAJc3dpdGNoICh0eXBlKSB7CiAJY2FzZSAwOgl2YWwgPDw9IHNoaWZ0
OwlicmVhazsKIAljYXNlIDE6CXZhbCA+Pj0gc2hpZnQ7CWJyZWFrOwpAQCAt
MzM3LDEwICszNDYsOSBAQAogCQl2YWwgPSAoKChzaWduZWQgbG9uZyl2YWwp
ID4+IHNoaWZ0KTsKIAkJYnJlYWs7CiAJY2FzZSAzOgotCQlfX2FzbV9fIF9f
dm9sYXRpbGVfXygibW92ICUwLCAlMCwgcm9yICUxIiA6ICI9ciIgKHZhbCkg
OiAiMCIgKHZhbCksICJyIiAoc2hpZnQpKTsKKyAJCXZhbCA9ICh2YWwgPj4g
c2hpZnQpIHwgKHZhbCA8PCAoMzIgLSBzaGlmdCkpOwogCQlicmVhazsKIAl9
Ci1wcmludGsgKCI9JTA4bFggIiwgdmFsKTsKIAlyZXR1cm4gdmFsOwogfQog
CkBAIC0zNTcsNyArMzY1LDYgQEAKIAlzaGlmdCA9IChpbnNuID4+IDcpICYg
MzE7CiAJdHlwZSA9IChpbnNuID4+IDUpICYgMzsKIAotcHJpbnRrICgib3Ay
PXIlMDJsZHNoJWR4JWQiLCBpbnNuICYgMTUsIHNoaWZ0LCB0eXBlKTsKIAlz
d2l0Y2ggKHR5cGUpIHsKIAljYXNlIDA6CXZhbCA8PD0gc2hpZnQ7CWJyZWFr
OwogCWNhc2UgMToJdmFsID4+PSBzaGlmdDsJYnJlYWs7CkBAIC0zNjUsMzMg
KzM3MiwyMiBAQAogCQl2YWwgPSAoKChzaWduZWQgbG9uZyl2YWwpID4+IHNo
aWZ0KTsKIAkJYnJlYWs7CiAJY2FzZSAzOgotCQlfX2FzbV9fIF9fdm9sYXRp
bGVfXygibW92ICUwLCAlMCwgcm9yICUxIiA6ICI9ciIgKHZhbCkgOiAiMCIg
KHZhbCksICJyIiAoc2hpZnQpKTsKKyAJCXZhbCA9ICh2YWwgPj4gc2hpZnQp
IHwgKHZhbCA8PCAoMzIgLSBzaGlmdCkpOwogCQlicmVhazsKIAl9Ci1wcmlu
dGsgKCI9JTA4bFggIiwgdmFsKTsKIAlyZXR1cm4gdmFsOwogfQotI3VuZGVm
IHBjX3BvaW50ZXIKLSNkZWZpbmUgcGNfcG9pbnRlcih4KSAoKHgpICYgMHgw
M2ZmZmZmYykKLWludCBwdHJhY2Vfc2V0X2JwdCAoc3RydWN0IHRhc2tfc3Ry
dWN0ICpjaGlsZCkKLXsKLQl1bnNpZ25lZCBsb25nIGluc24sIHBjLCBhbHQ7
Ci0JaW50IGksIG5zYXZlZCA9IDAsIHJlczsKLQotCXBjID0gcGNfcG9pbnRl
ciAoZ2V0X3N0YWNrX2xvbmcgKGNoaWxkLCAxNS8qUkVHX1BDKi8pKTsKIAot
CXJlcyA9IHJlYWRfbG9uZyAoY2hpbGQsIHBjLCAmaW5zbik7Ci0JaWYgKHJl
cyA8IDApCi0JCXJldHVybiByZXM7CitzdGF0aWMgdW5zaWduZWQgbG9uZwor
Z2V0X2JyYW5jaF9hZGRyZXNzKHN0cnVjdCB0YXNrX3N0cnVjdCAqY2hpbGQs
IHVuc2lnbmVkIGxvbmcgcGMsIHVuc2lnbmVkIGxvbmcgaW5zbikKK3sKKwl1
bnNpZ25lZCBsb25nIGFsdCA9IDA7CiAKLQljaGlsZC0+dHNzLmRlYnVnW25z
YXZlZCsrXSA9IGFsdCA9IHBjICsgNDsKLXByaW50ayAoInB0cmFjZV9zZXRf
YnB0OiBpbnNuPSUwOGxYIHBjPSUwOGxYICIsIGluc24sIHBjKTsKIAlzd2l0
Y2ggKGluc24gJiAweDBlMTAwMDAwKSB7CiAJY2FzZSAweDAwMDAwMDAwOgog
CWNhc2UgMHgwMDEwMDAwMDoKIAljYXNlIDB4MDIwMDAwMDA6CiAJY2FzZSAw
eDAyMTAwMDAwOiAvKiBkYXRhIHByb2Nlc3NpbmcgKi8KLQkJcHJpbnRrICgi
ZGF0YSAiKTsKIAkJc3dpdGNoIChpbnNuICYgMHgwMWUwZjAwMCkgewogCQlj
YXNlIDB4MDAwMGYwMDA6CiAJCQlhbHQgPSBwdHJhY2VfZ2V0cm4oY2hpbGQs
IGluc24pICYgcHRyYWNlX2dldGFsdW9wMihjaGlsZCwgaW5zbik7CkBAIC00
MzUsOSArNDMxLDggQEAKIAkJfQogCQlicmVhazsKIAotCWNhc2UgMHgwNDEw
MDAwMDogLyogbGRyICovCisJY2FzZSAweDA2MTAwMDAwOiAvKiBsZHIgKi8K
IAkJaWYgKChpbnNuICYgMHhmMDAwKSA9PSAweGYwMDApIHsKLXByaW50ayAo
ImxkciAiKTsKIAkJCWFsdCA9IHB0cmFjZV9nZXRybihjaGlsZCwgaW5zbik7
CiAJCQlpZiAoaW5zbiAmIDEgPDwgMjQpIHsKIAkJCQlpZiAoaW5zbiAmIDEg
PDwgMjMpCkBAIC00NDYsMTUgKzQ0MSwxNCBAQAogCQkJCQlhbHQgLT0gcHRy
YWNlX2dldGxkcm9wMiAoY2hpbGQsIGluc24pOwogCQkJfQogCQkJaWYgKHJl
YWRfbG9uZyAoY2hpbGQsIGFsdCwgJmFsdCkgPCAwKQotCQkJCWFsdCA9IHBj
ICsgNDsgLyogbm90IHZhbGlkICovCisJCQkJYWx0ID0gMDsgLyogbm90IHZh
bGlkICovCiAJCQllbHNlCiAJCQkJYWx0ID0gcGNfcG9pbnRlciAoYWx0KTsK
IAkJfQogCQlicmVhazsKIAotCWNhc2UgMHgwNjEwMDAwMDogLyogbGRyIGlt
bSAqLworCWNhc2UgMHgwNDEwMDAwMDogLyogbGRyIGltbSAqLwogCQlpZiAo
KGluc24gJiAweGYwMDApID09IDB4ZjAwMCkgewotcHJpbnRrICgibGRyaW1t
ICIpOwogCQkJYWx0ID0gcHRyYWNlX2dldHJuKGNoaWxkLCBpbnNuKTsKIAkJ
CWlmIChpbnNuICYgMSA8PCAyNCkgewogCQkJCWlmIChpbnNuICYgMSA8PCAy
MykKQEAgLTQ2Myw3ICs0NTcsNyBAQAogCQkJCQlhbHQgLT0gaW5zbiAmIDB4
ZmZmOwogCQkJfQogCQkJaWYgKHJlYWRfbG9uZyAoY2hpbGQsIGFsdCwgJmFs
dCkgPCAwKQotCQkJCWFsdCA9IHBjICsgNDsgLyogbm90IHZhbGlkICovCisJ
CQkJYWx0ID0gMDsgLyogbm90IHZhbGlkICovCiAJCQllbHNlCiAJCQkJYWx0
ID0gcGNfcG9pbnRlciAoYWx0KTsKIAkJfQpAQCAtNDczLDcgKzQ2Nyw2IEBA
CiAJCWlmIChpbnNuICYgKDEgPDwgMTUpKSB7CiAJCQl1bnNpZ25lZCBsb25n
IGJhc2U7CiAJCQlpbnQgbnJfcmVnczsKLXByaW50ayAoImxkbSAiKTsKIAog
CQkJaWYgKGluc24gJiAoMSA8PCAyMykpIHsKIAkJCQlucl9yZWdzID0gaW5z
biAmIDY1NTM1OwpAQCAtNDk2LDcgKzQ4OSw3IEBACiAJCQliYXNlID0gcHRy
YWNlX2dldHJuIChjaGlsZCwgaW5zbik7CiAKIAkJCWlmIChyZWFkX2xvbmcg
KGNoaWxkLCBiYXNlICsgbnJfcmVncywgJmFsdCkgPCAwKQotCQkJCWFsdCA9
IHBjICsgNDsgLyogbm90IHZhbGlkICovCisJCQkJYWx0ID0gMDsgLyogbm90
IHZhbGlkICovCiAJCQllbHNlCiAJCQkJYWx0ID0gcGNfcG9pbnRlciAoYWx0
KTsKIAkJCWJyZWFrOwpAQCAtNTA2LDcgKzQ5OSw2IEBACiAJY2FzZSAweDBh
MDAwMDAwOgogCWNhc2UgMHgwYTEwMDAwMDogeyAvKiBibCBvciBiICovCiAJ
CXNpZ25lZCBsb25nIGRpc3BsOwotcHJpbnRrICgiYi9ibCAiKTsKIAkJLyog
SXQncyBhIGJyYW5jaC9icmFuY2ggbGluazogaW5zdGVhZCBvZiB0cnlpbmcg
dG8KIAkJICogZmlndXJlIG91dCB3aGV0aGVyIHRoZSBicmFuY2ggd2lsbCBi
ZSB0YWtlbiBvciBub3QsCiAJCSAqIHdlJ2xsIHB1dCBhIGJyZWFrcG9pbnQg
YXQgZWl0aGVyIGxvY2F0aW9uLiAgVGhpcyBpcwpAQCAtNTIxLDQxICs1MTMs
OTcgQEAKIAkgICAgfQogCSAgICBicmVhazsKIAl9Ci1wcmludGsgKCI9JTA4
bFhcbiIsIGFsdCk7Ci0JaWYgKGFsdCAhPSBwYyArIDQpCi0JCWNoaWxkLT50
c3MuZGVidWdbbnNhdmVkKytdID0gYWx0OwogCi0JZm9yIChpID0gMDsgaSA8
IG5zYXZlZDsgaSsrKSB7Ci0JCXJlcyA9IHJlYWRfbG9uZyAoY2hpbGQsIGNo
aWxkLT50c3MuZGVidWdbaV0sICZpbnNuKTsKLQkJaWYgKHJlcyA+PSAwKSB7
Ci0JCQljaGlsZC0+dHNzLmRlYnVnW2kgKyAyXSA9IGluc247Ci0JCQlyZXMg
PSB3cml0ZV9sb25nIChjaGlsZCwgY2hpbGQtPnRzcy5kZWJ1Z1tpXSwgQlJF
QUtJTlNUKTsKKwlyZXR1cm4gYWx0OwogCQl9Ci0JCWlmIChyZXMgPCAwKSB7
Ci0JCQljaGlsZC0+dHNzLmRlYnVnWzRdID0gMDsKKworc3RhdGljIGludAor
YWRkX2JyZWFrcG9pbnQoc3RydWN0IHRhc2tfc3RydWN0ICpjaGlsZCwgc3Ry
dWN0IGRlYnVnX2luZm8gKmRiZywgdW5zaWduZWQgbG9uZyBhZGRyKQorewor
CWludCBuciA9IGRiZy0+bnNhdmVkOworCWludCByZXMgPSAtRUlOVkFMOwor
CisJaWYgKG5yIDwgMikgeworCQlyZXMgPSByZWFkX2xvbmcoY2hpbGQsIGFk
ZHIsICZkYmctPmJwW25yXS5pbnNuKTsKKwkJaWYgKHJlcyA9PSAwKQorCQkJ
cmVzID0gd3JpdGVfbG9uZyhjaGlsZCwgYWRkciwgQlJFQUtJTlNUKTsKKwor
CQlpZiAocmVzID09IDApIHsKKwkJCWRiZy0+YnBbbnJdLmFkZHJlc3MgPSBh
ZGRyOworCQkJZGJnLT5uc2F2ZWQgKz0gMTsKKwkJfQorCX0gZWxzZQorCQlw
cmludGsoS0VSTl9ERUJVRyAiYWRkX2JyZWFrcG9pbnQ6IHRvbyBtYW55IGJy
ZWFrcG9pbnRzXG4iKTsKKwogCQkJcmV0dXJuIHJlczsKIAkJfQorCisjZGVm
aW5lIHByZWRpY2F0ZSh4KQkoeCAmIDB4ZjAwMDAwMDApCisKK2ludCBwdHJh
Y2Vfc2V0X2JwdCAoc3RydWN0IHRhc2tfc3RydWN0ICpjaGlsZCkKK3sKKwlz
dHJ1Y3QgZGVidWdfaW5mbyAqZGJnID0gJmNoaWxkLT50c3MuZGVidWc7CisJ
dW5zaWduZWQgbG9uZyBpbnNuLCBwYywgYWx0OworCWludCByZXM7CisKKwlw
YyA9IHBjX3BvaW50ZXIgKGdldF9zdGFja19sb25nIChjaGlsZCwgMTUvKlJF
R19QQyovKSk7CisKKwlyZXMgPSByZWFkX2xvbmcoY2hpbGQsIHBjLCAmaW5z
bik7CisJaWYgKHJlcyA+PSAwKSB7CisJCXJlcyA9IDA7CisKKwkJZGJnLT5u
c2F2ZWQgPSAwOworCisJCWFsdCA9IGdldF9icmFuY2hfYWRkcmVzcyhjaGls
ZCwgcGMsIGluc24pOworCQlpZiAoYWx0KQorCQkJcmVzID0gYWRkX2JyZWFr
cG9pbnQoY2hpbGQsIGRiZywgYWx0KTsKKworCQlpZiAoIXJlcyAmJiAoIWFs
dCB8fCAocHJlZGljYXRlKGluc24pICE9IDB4ZTAwMDAwMDApKSkKKwkJCXJl
cyA9IGFkZF9icmVha3BvaW50KGNoaWxkLCBkYmcsIHBjICsgNCk7CiAJfQot
CWNoaWxkLT50c3MuZGVidWdbNF0gPSBuc2F2ZWQ7Ci0JcmV0dXJuIDA7CisK
KwlyZXR1cm4gcmVzOwogfQogCi0vKiBFbnN1cmUgbm8gc2luZ2xlLXN0ZXAg
YnJlYWtwb2ludCBpcyBwZW5kaW5nLiAgUmV0dXJucyBub24temVybwotICog
dmFsdWUgaWYgY2hpbGQgd2FzIGJlaW5nIHNpbmdsZS1zdGVwcGVkLgorLyog
RW5zdXJlIG5vIHNpbmdsZS1zdGVwIGJyZWFrcG9pbnQgaXMgcGVuZGluZy4K
ICAqLwotaW50IHB0cmFjZV9jYW5jZWxfYnB0IChzdHJ1Y3QgdGFza19zdHJ1
Y3QgKmNoaWxkKQordm9pZCBwdHJhY2VfZG9fY2FuY2VsX2JwdCAoc3RydWN0
IHRhc2tfc3RydWN0ICpjaGlsZCkKIHsKLQlpbnQgaSwgbnNhdmVkID0gY2hp
bGQtPnRzcy5kZWJ1Z1s0XTsKKwlzdHJ1Y3QgZGVidWdfaW5mbyAqZGJnID0g
JmNoaWxkLT50c3MuZGVidWc7CisJdW5zaWduZWQgbG9uZyB0bXA7CisJaW50
IGksIG5zYXZlZCA9IGRiZy0+bnNhdmVkOwogCi0JY2hpbGQtPnRzcy5kZWJ1
Z1s0XSA9IDA7CisJZGJnLT5uc2F2ZWQgPSAwOwogCiAJaWYgKG5zYXZlZCA+
IDIpIHsKIAkJcHJpbnRrICgicHRyYWNlX2NhbmNlbF9icHQ6IGJvZ3VzIG5z
YXZlZDogJWQhXG4iLCBuc2F2ZWQpOwogCQluc2F2ZWQgPSAyOwogCX0KLQlm
b3IgKGkgPSAwOyBpIDwgbnNhdmVkOyBpKyspCi0JCXdyaXRlX2xvbmcgKGNo
aWxkLCBjaGlsZC0+dHNzLmRlYnVnW2ldLCBjaGlsZC0+dHNzLmRlYnVnW2kg
KyAyXSk7Ci0JcmV0dXJuIG5zYXZlZCAhPSAwOworCisJZm9yIChpID0gMDsg
aSA8IG5zYXZlZDsgaSsrKSB7CisJCXJlYWRfbG9uZyhjaGlsZCwgZGJnLT5i
cFtpXS5hZGRyZXNzLCAmdG1wKTsKKwkJaWYgKHRtcCAhPSBCUkVBS0lOU1Qp
CisJCQlwcmludGsoS0VSTl9FUlIgInB0cmFjZV9jYW5jZWxfYnB0OiB3ZWly
ZG5lc3NcbiIpOworCQl3cml0ZV9sb25nKGNoaWxkLCBkYmctPmJwW2ldLmFk
ZHJlc3MsIGRiZy0+YnBbaV0uaW5zbik7CisJfQorfQorCisKK3N0YXRpYyBp
bmxpbmUgaW50IAorcHRyYWNlX3F1ZXJ5X2JwdCAoc3RydWN0IHRhc2tfc3Ry
dWN0ICpjaGlsZCkKK3sKKwlyZXR1cm4gKGNoaWxkLT50c3MuZGVidWcubnNh
dmVkICE9IDApOworfQorCitpbnQKK3B0cmFjZV9jYW5jZWxfYnB0IChzdHJ1
Y3QgdGFza19zdHJ1Y3QgKmNoaWxkKQoreworCWludCByOworCWlmIChyID0g
cHRyYWNlX3F1ZXJ5X2JwdCAoY2hpbGQpLCByID09IDApCisJCXJldHVybiAw
OworCisJcHRyYWNlX2RvX2NhbmNlbF9icHQgKGNoaWxkKTsKKwlyZXR1cm4g
cjsKIH0KIAogYXNtbGlua2FnZSBpbnQgc3lzX3B0cmFjZShsb25nIHJlcXVl
c3QsIGxvbmcgcGlkLCBsb25nIGFkZHIsIGxvbmcgZGF0YSkKQEAgLTU4OSw2
ICs2MzcsNyBAQAogCQkgICAgKGN1cnJlbnQtPnVpZCAhPSBjaGlsZC0+dWlk
KSB8fAogCSAJICAgIChjdXJyZW50LT5naWQgIT0gY2hpbGQtPmVnaWQpIHx8
CiAJIAkgICAgKGN1cnJlbnQtPmdpZCAhPSBjaGlsZC0+c2dpZCkgfHwKKwkJ
ICAgICghY2FwX2lzc3Vic2V0KGNoaWxkLT5jYXBfcGVybWl0dGVkLCBjdXJy
ZW50LT5jYXBfcGVybWl0dGVkKSkgfHwKIAkgCSAgICAoY3VycmVudC0+Z2lk
ICE9IGNoaWxkLT5naWQpKSAmJiAhY2FwYWJsZShDQVBfU1lTX1BUUkFDRSkp
CiAJCQlnb3RvIG91dDsKIAkJLyogdGhlIHNhbWUgcHJvY2VzcyBjYW5ub3Qg
YmUgYXR0YWNoZWQgbWFueSB0aW1lcyAqLwpAQCAtNjIwLDcgKzY2OSw3IEBA
CiAJCQl1bnNpZ25lZCBsb25nIHRtcDsKIAogCQkJcmV0ID0gcmVhZF9sb25n
KGNoaWxkLCBhZGRyLCAmdG1wKTsKLQkJCWlmIChyZXQgPj0gMCkKKwkJCWlm
ICghcmV0KQogCQkJCXJldCA9IHB1dF91c2VyKHRtcCwgKHVuc2lnbmVkIGxv
bmcgKilkYXRhKTsKIAkJCWdvdG8gb3V0OwogCQl9CkBAIC02ODcsMTIgKzcz
Niw1NCBAQAogCQkJcmV0ID0gLUVJTzsKIAkJCWlmICgodW5zaWduZWQgbG9u
ZykgZGF0YSA+IF9OU0lHKQogCQkJCWdvdG8gb3V0OwotCQkJY2hpbGQtPnRz
cy5kZWJ1Z1s0XSA9IC0xOworCQkJY2hpbGQtPnRzcy5kZWJ1Zy5uc2F2ZWQg
PSAtMTsKIAkJCWNoaWxkLT5mbGFncyAmPSB+UEZfVFJBQ0VTWVM7CiAJCQl3
YWtlX3VwX3Byb2Nlc3MoY2hpbGQpOwogCQkJY2hpbGQtPmV4aXRfY29kZSA9
IGRhdGE7CiAJCQkvKiBnaXZlIGl0IGEgY2hhbmNlIHRvIHJ1bi4gKi8KIAkJ
CXJldCA9IDA7CisJCQlnb3RvIG91dDsKKworCQljYXNlIFBUUkFDRV9HRVRS
RUdTOgorCQl7CS8qIEdldCBhbGwgZ3AgcmVncyBmcm9tIHRoZSBjaGlsZC4g
Ki8KKwkJCXVuc2lnbmVkIGNoYXIgKnN0YWNrOworCisJCQlyZXQgPSAwOwor
CQkJc3RhY2sgPSAodW5zaWduZWQgY2hhciAqKSgodW5zaWduZWQgbG9uZylj
aGlsZCArIDgxOTIgLSBzaXplb2Yoc3RydWN0IHB0X3JlZ3MpKTsKKwkJCWlm
IChjb3B5X3RvX3VzZXIoKHZvaWQgKilkYXRhLCBzdGFjaywKKwkJCQkJIHNp
emVvZihzdHJ1Y3QgcHRfcmVncykpKQorCQkJCXJldCA9IC1FRkFVTFQ7CisK
KwkJCWdvdG8gb3V0OworCQl9OworCisJCWNhc2UgUFRSQUNFX1NFVFJFR1M6
CisJCXsKKwkJCS8qIFNldCBhbGwgZ3AgcmVncyBpbiB0aGUgY2hpbGQuICov
CisJCQl1bnNpZ25lZCBjaGFyICpzdGFjazsKKworCQkJcmV0ID0gMDsKKwkJ
CXN0YWNrID0gKHVuc2lnbmVkIGNoYXIgKikoKHVuc2lnbmVkIGxvbmcpY2hp
bGQgKyA4MTkyIC0gc2l6ZW9mKHN0cnVjdCBwdF9yZWdzKSk7CisJCQlpZiAo
Y29weV9mcm9tX3VzZXIoc3RhY2ssICh2b2lkICopZGF0YSwKKwkJCQkJICAg
c2l6ZW9mKHN0cnVjdCBwdF9yZWdzKSkpCisJCQkJcmV0ID0gLUVGQVVMVDsK
KwkJCWdvdG8gb3V0OworCQkgIH07CisKKwkJY2FzZSBQVFJBQ0VfR0VURlBS
RUdTOiAKKwkJCS8qIEdldCB0aGUgY2hpbGQgRlBVIHN0YXRlLiAqLworCQkJ
cmV0ID0gMDsKKwkJCWlmIChjb3B5X3RvX3VzZXIoKHZvaWQgKilkYXRhLCAm
Y2hpbGQtPnRzcy5mcHN0YXRlLAorCQkJCQkgc2l6ZW9mKHN0cnVjdCB1c2Vy
X2ZwKSkpCisJCQkJcmV0ID0gLUVGQVVMVDsKKwkJCWdvdG8gb3V0OworCQkK
KwkJY2FzZSBQVFJBQ0VfU0VURlBSRUdTOgorCQkJLyogU2V0IHRoZSBjaGls
ZCBGUFUgc3RhdGUuICovCisJCQlyZXQgPSAwOworCQkJaWYgKGNvcHlfZnJv
bV91c2VyKCZjaGlsZC0+dHNzLmZwc3RhdGUsICh2b2lkICopZGF0YSwKKwkJ
CQkJICAgc2l6ZW9mKHN0cnVjdCB1c2VyX2ZwKSkpCisJCQkJcmV0ID0gLUVG
QVVMVDsKIAkJCWdvdG8gb3V0OwogCiAJCWNhc2UgUFRSQUNFX0RFVEFDSDoJ
CQkJLyogZGV0YWNoIGEgcHJvY2VzcyB0aGF0IHdhcyBhdHRhY2hlZC4gKi8K
LS0tIC9za2lmZi9qYW1leS9saW51eC0yLjIuMTQtcm1rMy1jcmwxL2FyY2gv
YXJtL2tlcm5lbC9wcm9jZXNzLmMJVHVlIEphbiAxOCAxODowNjozMiAyMDAw
CisrKyAvdXNyL3NyYy9saW51eC9hcmNoL2FybS9rZXJuZWwvcHJvY2Vzcy5j
CVR1ZSBKYW4gMjUgMDI6MzM6NDYgMjAwMApAQCAtMjA4LDEwICsyMDgsOCBA
QAogCiB2b2lkIGZsdXNoX3RocmVhZCh2b2lkKQogewotCWludCBpOwotCi0J
Zm9yIChpID0gMDsgaSA8IE5SX0RFQlVHUzsgaSsrKQotCQljdXJyZW50LT50
c3MuZGVidWdbaV0gPSAwOworCW1lbXNldCgmY3VycmVudC0+dHNzLmRlYnVn
LCAwLCBzaXplb2YoY3VycmVudC0+dHNzLmRlYnVnKSk7CisJbWVtc2V0KCZj
dXJyZW50LT50c3MuZnBzdGF0ZSwgMCwgc2l6ZW9mKGN1cnJlbnQtPnRzcy5m
cHN0YXRlKSk7CiAJY3VycmVudC0+dXNlZF9tYXRoID0gMDsKIAljdXJyZW50
LT5mbGFncyAmPSB+UEZfVVNFREZQVTsKIH0KQEAgLTI1Niw3ICsyNTQsNiBA
QAogICovCiB2b2lkIGR1bXBfdGhyZWFkKHN0cnVjdCBwdF9yZWdzICogcmVn
cywgc3RydWN0IHVzZXIgKiBkdW1wKQogewotCWludCBpOwogCiAJZHVtcC0+
bWFnaWMgPSBDTUFHSUM7CiAJZHVtcC0+c3RhcnRfY29kZSA9IGN1cnJlbnQt
Pm1tLT5zdGFydF9jb2RlOwpAQCAtMjY2LDggKzI2MywxMSBAQAogCWR1bXAt
PnVfZHNpemUgPSAoY3VycmVudC0+bW0tPmJyayAtIGN1cnJlbnQtPm1tLT5z
dGFydF9kYXRhICsgUEFHRV9TSVpFIC0gMSkgPj4gUEFHRV9TSElGVDsKIAlk
dW1wLT51X3NzaXplID0gMDsKIAotCWZvciAoaSA9IDA7IGkgPCBOUl9ERUJV
R1M7IGkrKykKLQkJZHVtcC0+dV9kZWJ1Z3JlZ1tpXSA9IGN1cnJlbnQtPnRz
cy5kZWJ1Z1tpXTsgIAorCWR1bXAtPnVfZGVidWdyZWdbMF0gPSBjdXJyZW50
LT50c3MuZGVidWcuYnBbMF0uYWRkcmVzczsKKwlkdW1wLT51X2RlYnVncmVn
WzFdID0gY3VycmVudC0+dHNzLmRlYnVnLmJwWzFdLmFkZHJlc3M7CisJZHVt
cC0+dV9kZWJ1Z3JlZ1syXSA9IGN1cnJlbnQtPnRzcy5kZWJ1Zy5icFswXS5p
bnNuOworCWR1bXAtPnVfZGVidWdyZWdbM10gPSBjdXJyZW50LT50c3MuZGVi
dWcuYnBbMV0uaW5zbjsKKwlkdW1wLT51X2RlYnVncmVnWzRdID0gY3VycmVu
dC0+dHNzLmRlYnVnLm5zYXZlZDsKIAogCWlmIChkdW1wLT5zdGFydF9zdGFj
ayA8IDB4MDQwMDAwMDApCiAJCWR1bXAtPnVfc3NpemUgPSAoMHgwNDAwMDAw
MCAtIGR1bXAtPnN0YXJ0X3N0YWNrKSA+PiBQQUdFX1NISUZUOwo=

------------=_1583534238-23286-0--
From scottb@netwinder.org Tue Feb 29 11:48:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: ARM Port...
Date: Tue, 29 Feb 2000 11:48:00 -0000
Message-id: <38BC213C.CAD0726A@netwinder.org>
X-SW-Source: 2000-02/msg00055.html
Content-length: 911

Hi guys,

I have slowly been reviewing the merge of my changes for ARM Linux into GDB and
have the following minor observations:

1) TARGET_BYTE_ORDER_SELECTABLE is deprecated according to gdbint.texi. 
TARGET_BYTE_ORDER_SELECTABLE_P is the preferred macro to use.  Both are defined
in tm-arm.h.  Shouldn't TARGET_BYTE_ORDER_SELECTABLE be removed?

2) In tm-embed.h, the Thumb breakpoints are redefined?  Why?  The Linux port
doesn't care.  If they have been changed, why not just change them in tm-arm.h? 
Seems simpler and less confusing.  Perhaps I had them wrong?

3) LOWEST_PC is defined in tm-arm.h.  It is redefined in tm-embed.h.  A similar
thing happened in tm-linux.h and it generated a compiler warning on every file. 
Undefining it before redefining it helps clean up the build.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From jimb@cygnus.com Tue Feb 29 13:34:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Try out the patch database
Date: Tue, 29 Feb 2000 13:34:00 -0000
Message-id: <200002292134.QAA10095@zwingli.cygnus.com>
X-SW-Source: 2000-02/msg00056.html
Content-length: 858

Take a look at http://sourceware.cygnus.com/gdb/contribute.html , and
let me know what you think.

I'd like to incorporate the text of that page itself into the main GDB
page, http://sourceware.cygnus.com/gdb/ .

contribute.html refers to three new pages:

- patch-db.html, which is supposed to be everything a new contributor
  needs to know to add a patch to the patch database.

- patch-checklist.html, a checklist for submitting patches via
  E-mail.  Originally, I was going to do a template, but it seems like
  GNATS will do everything that's important automatically, so I don't
  think a template offers much benefit over simple instructions.

- assigning.html, a page explaining the copyright situation, and
  directing people to talk to me.  Eventually, of course, we'll want a
  role mail address for this, but I want to get things going quickly.
From kevinb@cygnus.com Tue Feb 29 14:13:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: Try out the patch database
Date: Tue, 29 Feb 2000 14:13:00 -0000
Message-id: <1000229221310.ZM16579@ocotillo.lan>
References: <200002292134.QAA10095@zwingli.cygnus.com> <jimb@cygnus.com>
X-SW-Source: 2000-02/msg00057.html
Content-length: 567

On Feb 29,  4:34pm, Jim Blandy wrote:

> Take a look at http://sourceware.cygnus.com/gdb/contribute.html , and
> let me know what you think.

I see two patches in the gdb database.  (There was only one a little
while ago.)  I'd like to see how the attachment mechanism works.  I
downloaded the Kublai Khan poem, but it's in html.  I'd like to see
a real patch that I can download.

Also, I think it'd be useful to be able to view a patch in the web
browser as well as download it to a file.  It's not clear to me that
both of these capabilities are available.

Kevin
From ac131313@cygnus.com Tue Feb 29 15:12:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: gdb web re-arrage
Date: Tue, 29 Feb 2000 15:12:00 -0000
Message-id: <38BC5206.21224C1A@cygnus.com>
X-SW-Source: 2000-02/msg00058.html
Content-length: 240

Jim,

In prep for 5.0 what do you think of changing the gdb web pages so that
there is the url:

	http://sourceware.cygnus.com/gdb/5/

for all the 5.0 release information.  (I'd also move the 4.17 and 4.18
to their own directory).

	Andrew
From tromey@cygnus.com Tue Feb 29 15:15:00 2000
From: Tom Tromey <tromey@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Try out the patch database
Date: Tue, 29 Feb 2000 15:15:00 -0000
Message-id: <87itz7bofe.fsf@cygnus.com>
References: <200002292134.QAA10095@zwingli.cygnus.com>
X-SW-Source: 2000-02/msg00059.html
Content-length: 591

Jim> - patch-db.html, which is supposed to be everything a new contributor
Jim>   needs to know to add a patch to the patch database.

Make the URL that points to Gnats look like this:

http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?user=guest&password=guest&database=gdb-patches&cmd=login

This will take people directly to the gdb-patches page without having
to log in.

I think it will also do the right thing if you've logged in with a
non-guest account (but I'm not 100% sure; anyway if it doesn't, it
should, and we can send a report to the gnatsweb maintainers).

Tom
From kingdon@redhat.com Tue Feb 29 15:20:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb web re-arrage
Date: Tue, 29 Feb 2000 15:20:00 -0000
Message-id: <200002292320.SAA31967@devserv.devel.redhat.com>
References: <38BC5206.21224C1A@cygnus.com>
X-SW-Source: 2000-02/msg00060.html
Content-length: 465

> In prep for 5.0 what do you think of changing the gdb web pages so that
> there is the url:
> 
> 	http://sourceware.cygnus.com/gdb/5/

OK with me.  And you can replace issues50.html with a "Page Moved"
kind of thing.

> (I'd also move the 4.17 and 4.18 to their own directory).

I'd rather not do this.  I haven't looked at the logs to see if anyone
has linked to the current URL's, but I guess I don't see any
particularly compelling reason to change the URL's.
From ac131313@cygnus.com Tue Feb 29 16:15:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb web re-arrage
Date: Tue, 29 Feb 2000 16:15:00 -0000
Message-id: <38BC60B2.D0169FE7@cygnus.com>
References: <38BC5206.21224C1A@cygnus.com> <200002292320.SAA31967@devserv.devel.redhat.com>
X-SW-Source: 2000-02/msg00061.html
Content-length: 581

Jim Kingdon wrote:
> 
> > In prep for 5.0 what do you think of changing the gdb web pages so that
> > there is the url:
> >
> >       http://sourceware.cygnus.com/gdb/5/
> 
> OK with me.  And you can replace issues50.html with a "Page Moved"
> kind of thing.

Ok.

> > (I'd also move the 4.17 and 4.18 to their own directory).
> 
> I'd rather not do this.  I haven't looked at the logs to see if anyone
> has linked to the current URL's, but I guess I don't see any
> particularly compelling reason to change the URL's.

Yes, good point.  Old links never go away .... :-)

	Andrew
From kettenis@wins.uva.nl Tue Feb 29 16:39:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jimb@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Try out the patch database
Date: Tue, 29 Feb 2000 16:39:00 -0000
Message-id: <200003010038.e210cd100247@delius.kettenis.local>
References: <200002292134.QAA10095@zwingli.cygnus.com>
X-SW-Source: 2000-02/msg00062.html
Content-length: 269

   Date: Tue, 29 Feb 2000 16:34:42 -0500 (EST)
   From: Jim Blandy <jimb@cygnus.com>

   Take a look at http://sourceware.cygnus.com/gdb/contribute.html , and
   let me know what you think.

Looks like it is hell of a lot more usable than the FSF gnats
database.

Mark
From ac131313@cygnus.com Tue Feb 29 18:35:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT/RFC] Start devolving maintenance responsibility
Date: Tue, 29 Feb 2000 18:35:00 -0000
Message-id: <38BC81A0.17D25C8@cygnus.com>
X-SW-Source: 2000-02/msg00063.html
Content-length: 3150

Hello,

GDB's been on sourceware for a whole month so its now probably time time
to start devolving more responsibility :-)
With that in mind, I'm proposing the attatched change.  It hopefully
achieves the following:

	o	allows the maintainers
		within a domain to self
		organize

	o	clearly identify who
		is ultimately responsible
		for a maintenace domain
		(where the buck stops :-)

	o	provides a suggested fraomewor
		within which domain maintainers
		can work.

Comments?  I'm going to leave this tabled for at lest a week as I know
of at least two maintainers that are off line right now.

	Andrew

Wed Mar  1 12:29:35 2000  Andrew Cagney  <cagney@b1.cygnus.com>

        * MAINTAINERS: Devolve responsibility for domain maintenance to
        the domain maintainers.
? diffs
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.88
diff -p -r1.88 ChangeLog
*** ChangeLog	2000/03/01 00:45:18	1.88
--- ChangeLog	2000/03/01 02:31:28
***************
*** 1,3 ****
--- 1,8 ----
+ Wed Mar  1 12:29:35 2000  Andrew Cagney  <cagney@b1.cygnus.com>
+ 
+ 	* MAINTAINERS: Devolve responsibility for domain maintenance to
+  	the domain maintainers.
+ 
  2000-03-01  Mark Kettenis  <kettenis@gnu.org>
  
  	* MAINTAINERS: Correct my own mail address.
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.16
diff -p -r1.16 MAINTAINERS
*** MAINTAINERS	2000/03/01 00:45:18	1.16
--- MAINTAINERS	2000/03/01 02:31:31
*************** Stan Shebs			shebs@cygnus.com
*** 8,24 ****
  
  			Various Maintainers
  
! Note individuals who maintain parts of the debugger need approval to
! check in changes outside of the immediate domain that they maintain.
  
! If there is no maintainer for a given domain then the problem falls to
! the head maintainer.
  
! If there are several maintainers for a given domain then the problem
! falls to the first maintainer.  The second and third maintainers are
! firstly known to have expertise in the given domain and secondly are
! available to step in if the first maintainer is to be absent for any
! reason.
  
  
  Target/Architecture:
--- 8,29 ----
  
  			Various Maintainers
  
! Individuals who make changes to the debugger need approval from all
! relevant domain maintainers before those changed can be checked in.
  
! If there is no maintainer for a given maintenance domain then approval
! is the responsibility of the head maintainer.
  
! If there are several maintainers for a given maintenance domain then
! approval is the responsibility of the first maintainer.  How exactly
! that responsibility is administered is also the responsibility of the
! first maintainer.
! 
! Typically, when there are several maintainers, the first maintainer
! will devolve all responsibility for that domain to that domains
! maintainers.  Individuals making changes within their domain would
! have major changes approved through consensus (with their peers) while
! minor tweaks would not need approval.
  
  
  Target/Architecture:
From ac131313@cygnus.com Tue Feb 29 19:14:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Scott Bambrough <scottb@netwinder.org>, Chris Faylor <cgf@cygnus.com>
Cc: GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: Re: ARM Port...
Date: Tue, 29 Feb 2000 19:14:00 -0000
Message-id: <38BC8AB4.6AAA64E3@cygnus.com>
References: <38BC213C.CAD0726A@netwinder.org>
X-SW-Source: 2000-02/msg00064.html
Content-length: 2653

Scott Bambrough wrote:
> 
> Hi guys,
> 
> I have slowly been reviewing the merge of my changes for ARM Linux into GDB and
> have the following minor observations:

(Fernando is away.  I know JimI is very busy).

> 1) TARGET_BYTE_ORDER_SELECTABLE is deprecated according to gdbint.texi.
> TARGET_BYTE_ORDER_SELECTABLE_P is the preferred macro to use.  Both are defined
> in tm-arm.h.  Shouldn't TARGET_BYTE_ORDER_SELECTABLE be removed?

Yes, almost:

cagney@b1.cygnus.com$ find * | grep TARGET_BYTE_ORDER_SELECTABLE | grep
-v TARGET_BYTE_ORDER_SELECTABLE_P
config/arc/tm-arc.h:#define     TARGET_BYTE_ORDER_SELECTABLE
config/arm/tm-arm.h:#define TARGET_BYTE_ORDER_SELECTABLE
config/arm/tm-wince.h:#undef TARGET_BYTE_ORDER_SELECTABLE
config/mips/tm-wince.h:#undef TARGET_BYTE_ORDER_SELECTABLE
config/sh/tm-sh.h:#define TARGET_BYTE_ORDER_SELECTABLE
config/sh/tm-wince.h:#undef TARGET_BYTE_ORDER_SELECTABLE
config/sparc/tm-sparclet.h:#define TARGET_BYTE_ORDER_SELECTABLE
config/sparc/tm-sparclite.h:#define TARGET_BYTE_ORDER_SELECTABLE
doc/gdbint.texinfo:@var{TARGET_BYTE_ORDER_SELECTABLE} which is
deprecated.
gdbarch.c:#ifdef TARGET_BYTE_ORDER_SELECTABLE
gdbarch.h:#ifdef TARGET_BYTE_ORDER_SELECTABLE
gdbarch.h:#ifdef TARGET_BYTE_ORDER_SELECTABLE
gdbarch.h:/* compat - Catch old targets that define
TARGET_BYTE_ORDER_SELECTABLE
gdbarch.sh:#ifdef TARGET_BYTE_ORDER_SELECTABLE
gdbarch.sh:#ifdef TARGET_BYTE_ORDER_SELECTABLE
gdbarch.sh:/* compat - Catch old targets that define
TARGET_BYTE_ORDER_SELECTABLE
gdbarch.sh:#ifdef TARGET_BYTE_ORDER_SELECTABLE
gdbserver/low-sim.c:#ifdef TARGET_BYTE_ORDER_SELECTABLE
gdbserver/low-sim.c:#ifdef TARGET_BYTE_ORDER_SELECTABLE

arm/tm-wince.h would need to be tweeked.

Chris - any reason to not have arm/wince bi-endian but little endian by
default.  When it's multi-arched it will be that way regardless.

Scott - if you feel luck (:-) you could submit a number of patches to
purge target_byte_order_selectable.


> 2) In tm-embed.h, the Thumb breakpoints are redefined?  Why?  The Linux port
> doesn't care.  If they have been changed, why not just change them in tm-arm.h?
> Seems simpler and less confusing.  Perhaps I had them wrong?

Check the mail archives for this one.  I remember several discussions
about what the embedded breakpoint should be but no details.

> 3) LOWEST_PC is defined in tm-arm.h.  It is redefined in tm-embed.h.  A similar
> thing happened in tm-linux.h and it generated a compiler warning on every file.
> Undefining it before redefining it helps clean up the build.

I assume you mean:

#undef LOWEST_PC
#define LOWEST_PC

Yes.  If you post a patch I'll just auto approve it.

	Andrew
From ac131313@cygnus.com Tue Feb 29 20:56:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT] x86 maintainers .....
Date: Tue, 29 Feb 2000 20:56:00 -0000
Message-id: <38BCA2B9.3BDE66AD@cygnus.com>
X-SW-Source: 2000-02/msg00065.html
Content-length: 318

Hello,

I'd like to put forward the following:


x86 target		Mark Kettenis		kettenis@gnu.org

GNU/Linux/x86 native & host
			Jim Blandy		jimb@cygnus.com
			Mark Kettenis		kettenis@gnu.org

Solaris/x86 native & host
			Nick Duffek		nsd@cygnus.com
			Peter Schauer		Peter.Schauer@regent.e-technik.tu-muenchen.de

Andrew
From cshihpin@dso.org.sg Tue Feb 29 22:08:00 2000
From: Chan Shih-Ping Richard <cshihpin@dso.org.sg>
To: gdb@sourceware.cygnus.com
Subject: CVS: Cannot overload resolve std::string.size() in valops.c (fwd)
Date: Tue, 29 Feb 2000 22:08:00 -0000
Message-id: <Pine.LNX.4.10.10003011407170.11100-100000@vermeer.dso.org.sg>
X-SW-Source: 2000-02/msg00066.html
Content-length: 520

Hi all,

There seems to be an off-by-one error in valops.c that prevents
overload resolution of 
	string s.size();
	string s.length();

Didn't Dan Berlin point this out sometime ago (?)- wonder have
I missed a fix in the CVS. When comparing "goodness-of-fit"
nparms = 0 and nargs = 1. In function find_overload_match 
either
	nargs should be 0
or 
	rank_function should use nargs-1.

Comments?







-- 

Chan Shih-Ping (Richard) <cshihpin@dso.org.sg>
DSO National Laboratories
20 Science Park Drive
Singapore 118230