Re: changelog rotation...

Re: changelog rotation...

[Kevin Buettner]

On Jan 12, 11:33am, J.T. Conklin wrote:

> >> If we do put each version on its own ChangeLog, we could have
> >> ChangeLog.418, ChangeLog.500, etc.
> 
> Stan> I really like this idea.
> 
> I actually like the split-by-year scheme.  This tends to place about
> the right number of entries in each file regardless of whether there
> are six months or two years between GDB releases.  It makes it easy 
> to go from the mailing list archives to the cooresponding ChangeLog
> file without any guessing.

I agree with J.T.

(I don't normally like "me too" mail, so just consider this as a vote
against any split-by-version scheme.)

Kevin
From jtc@redback.com Fri Jan 12 14:19:00 2001
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: step out of range
Date: Fri, 12 Jan 2001 14:19:00 -0000
Message-id: <5mpuhsza5c.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00069.html
Content-length: 1113

I've encounter monitors and ICEs that have a "step out of range"
command where execution continues until a instruction outside of a
range of instructions is about to be executed or a breakpoint is
triggered.  If GDB is able to take advantage of this feature, it won't
have to do multiple single-steps for step, next, until, etc. commands.

This could siginficantly improve interactive debugging performance, as
it eliminates most of the latency from the "step an instruction/ query
registers to check whether we're within the address range/yep we
are/repeat" sequence.

GDB already computes a range of instructions (step_range_start,
step_range_end) that it uses internally when stepping through a range
of instructions.  So it seems that all we need to do is to expose/use
these variables in the target layer.  In fact, the vxWorks RDB target
(remote-vx.c) does exactly this.  But it seems that these values
should be passed through to target_remote() instead of being globals.

Any thoughts?  I'd like to add a step out of range command to the
remote protocol.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From fnasser@cygnus.com Fri Jan 12 14:27:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: step out of range
Date: Fri, 12 Jan 2001 14:27:00 -0000
Message-id: <3A5F84DA.EA67851C@cygnus.com>
References: <5mpuhsza5c.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00070.html
Content-length: 1623

"J.T. Conklin" wrote:
> 
> I've encounter monitors and ICEs that have a "step out of range"
> command where execution continues until a instruction outside of a
> range of instructions is about to be executed or a breakpoint is
> triggered.  If GDB is able to take advantage of this feature, it won't
> have to do multiple single-steps for step, next, until, etc. commands.
> 
> This could siginficantly improve interactive debugging performance, as
> it eliminates most of the latency from the "step an instruction/ query
> registers to check whether we're within the address range/yep we
> are/repeat" sequence.
> 
> GDB already computes a range of instructions (step_range_start,
> step_range_end) that it uses internally when stepping through a range
> of instructions.  So it seems that all we need to do is to expose/use
> these variables in the target layer.  In fact, the vxWorks RDB target
> (remote-vx.c) does exactly this.  But it seems that these values
> should be passed through to target_remote() instead of being globals.
> 
> Any thoughts?  I'd like to add a step out of range command to the
> remote protocol.
> 

This idea is really neat.  I had a sort of stub some years ago 
(actually a "Debugger Helper" loaded on a multiprocessor node) that
was capable of taking care of the single step without having to
get back to the debugger.  The implementation was a hack, but the
result was effective.

You have my vote (as people are now in the voting mood :-).

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From cgf@redhat.com Fri Jan 12 14:30:00 2001
From: Christopher Faylor <cgf@redhat.com>
To: gdb@sources.redhat.com
Subject: Re: changelog rotation...
Date: Fri, 12 Jan 2001 14:30:00 -0000
Message-id: <20010112173052.A11539@redhat.com>
References: <5md7dt7ski.fsf@jtc.redback.com> <3A5E23C0.A8DF6E48@redhat.com> <5mn1cx6ajc.fsf@jtc.redback.com> <3A5E2E6B.AA61F361@redhat.com> <5m66jl68ez.fsf@jtc.redback.com> <9003-Fri12Jan2001111534+0200-eliz@is.elta.co.il> <7263-Fri12Jan2001122813+0200-eliz@is.elta.co.il> <3A5F5825.CF95E1D6@apple.com> <5m66jk36qu.fsf@jtc.redback.com> <1010112214939.ZM28565@ocotillo.lan>
X-SW-Source: 2001-01/msg00071.html
Content-length: 872

On Fri, Jan 12, 2001 at 02:49:39PM -0700, Kevin Buettner wrote:
>On Jan 12, 11:33am, J.T. Conklin wrote:
>
>> >> If we do put each version on its own ChangeLog, we could have
>> >> ChangeLog.418, ChangeLog.500, etc.
>> 
>> Stan> I really like this idea.
>> 
>> I actually like the split-by-year scheme.  This tends to place about
>> the right number of entries in each file regardless of whether there
>> are six months or two years between GDB releases.  It makes it easy 
>> to go from the mailing list archives to the cooresponding ChangeLog
>> file without any guessing.
>
>I agree with J.T.
>
>(I don't normally like "me too" mail, so just consider this as a vote
>against any split-by-version scheme.)

Maybe a compromise is to adopt the Microsoft-style version numbering of

"GDB 2001", "GDB 2002", etc.  Then we'd have the best of both worlds.

:-) (I think)

cgf
From greg@mcgary.org Fri Jan 12 14:41:00 2001
From: Greg McGary <greg@mcgary.org>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: step out of range
Date: Fri, 12 Jan 2001 14:41:00 -0000
Message-id: <ms66jkv1ff.fsf@mcgary.org>
References: <5mpuhsza5c.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00072.html
Content-length: 429

jtc@redback.com (J.T. Conklin) writes:

> Any thoughts?  I'd like to add a step out of range command to the
> remote protocol.

I implemented exactly this in gdb-4.17.  The gdb host side wasn't so
difficult to do, though the cleanliness of the implementation is an
open question.  8^) I'll blow the dust off it and integrate into
current code, then send you a copy.  Ping me if I don't have it for
you by end of next week.

Greg
From naklilu@ualberta.ca Fri Jan 12 20:50:00 2001
From: "Noah Aklilu" <naklilu@ualberta.ca>
To: gdb@sourceware.cygnus.com
Subject: Re: Using GDB with M32R MSA2000 Board
Date: Fri, 12 Jan 2001 20:50:00 -0000
Message-id: <3A5F7C09.23245.4F9559@localhost>
References: <3A5DD05F.D5C5F105@redhat.com>
X-SW-Source: 2001-01/msg00073.html
Content-length: 7716

Thanks for the advice.  Unfortunately I am going out of
town for a couple of weeks so I won't be able to
try it out until I get back.


On 11 Jan 2001, at 10:25, Fernando Nasser wrote:

> Noah Aklilu wrote:
> > 
> > It still comes out with the same error (minus the backtrace)
> > about the bad value returned.  Unfortunately the mon2000
> > is a remote target, so there is really no way I can think
> > of logging that.  Is there a way to starting backend
> > logging with gdb?
> > 
> > Well here is the result when I execute the gdb command:
> > 
> > m32r-elf-gdb -nw hello.exe
> > 
> > GNU gdb 5.0
> > Copyright 2000 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and
> > you are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for
> > details.
> > This GDB was configured as "--host=i686-pc-cygwin --target=m32r-
> > elf"...
> > (gdb) set remotebaud 9600
> > (gdb) target mon2000 com2
> > Remote target mon2000 connected to com2
> > monitor_supply_register (21):  bad value from monitor: 7FFFFFF0
> > psw = 000000C0 (BSM=0, BIE=0, BC=0, SM=1, IE=1, C=0)
> >   bpc = 00000000
> >   r0  = 00000000    r1  = 00000000    r2  = 00000000    r3  = 00000000
> >   r4  = 00000000    r5  = 00000000    r6  = 00000000    r7  = 00000000
> >   r8  = 00000000    r9  = 00000000    r10 = 00000000    r11 = 00000000
> >   r12 = 00000000    r13 = 00000000    r14 = 00000000
> >   spu = 009E3200    spi = 009E4200    acc = 00000000:00000000
> > Mon2000>.
> > (gdb) quit
> > The program is running.  Exit anyway? (y or n)
> > 
> > --end
> > 
> 
> Before issuing the "target" command, please use
> 
> set debug remote 2
> set debug monitor on
> 
> so we can see what the monitor is sending as the PC.
> 
> Alternatively, run gdb under gdb (use -nw as arguments for both) and
> set a breakpoint:
> 
> break m32r_supply_register 
> 
> and lets see what gdb is getting as a PC from the monitor.
> 
> 
> 
> > Now I am wondering if I have a different version of the
> > mon2000 monitor from what cygnus used to develop the
> > code for the toolset.  But when I read throught the
> > libgloss code, it says msa2000 in the comments. Hmmm.
> > 
> 
> It is possible that something different is being sent and GDB is
> not expecting.  If this is true you'll have to modify GDB to match
> your board monitor.
> 
> 
> > Below is the output with the version of the monitor and
> > system captured from the terminal emulator.
> > 
> 
> I wouldn't know anything about versions of these.  I never seen one
> of these boards.
> 
> Would anyone else know?
> 
> 
> > Noah.
> > 
> > MSA2000G01(M32R/D_2MB version)monitor program
> > Mon2000 Ver1.00b for FORTH programming system
> > Copyright 1997, MITSUBISHI ELECTRIC CORPORATION.
> > and MITSUBISHI ELECTRIC SEMICONDUCTOR SOFTWARE CORPORATION.
> > All Rights Reserved.
> > Mon2000> help
> >         ***** CLIENT PROGRAM DEBUGGING COMMAND *****
> > 
> >         TO               [data] TO %reg_name
> >             reg_name = R[0-14],SPU,SPI,PC,BPC,PSW,ACCH,ACCL
> >         .REGISTERS       .REGISTERS
> >         DUMP             [start_address] [byte_count] DUMP
> >         MOVE             [src_address] [dest_address] [count] MOVE
> >         MOVEH            [src_address] [dest_address] [count] MOVEH
> >         MOVEW            [src_address] [dest_address] [count] MOVEW
> >         FILL             [start_address] [count] [data] FILL
> >         FILLH            [start_address] [count] [data] FILLH
> >         FILLW            [start_address] [count] [data] FILLW
> >         GO               GO
> >         STEP             STEP
> >         STEPS            [count] STEPS
> >         DIS              [address] DIS
> >         +DIS             +DIS
> >         .BP              .BP
> >         +BP              [address] +BP
> >         -BP              [address] -BP
> >         BPOFF            BPOFF
> >         TILL             [address] TILL
> >         MB               [address] MB
> >         MH               [address] MH
> >         MW               [address] MW
> >         UL               UL[filename]
> >         UP               UP[path_name]
> >         UHIP             UHIP [sever_IPaddress]
> >         ULIP             ULIP [borad_IPaddress]
> >         UST              UST
> >         PING             PING [IPaddress]
> > Mon2000>
> > 
> > On 9 Jan 2001, at 21:30, Fernando Nasser wrote:
> > 
> > > Just to get a clearer error message, use GDB in command mode:
> > >
> > > gdb -x -nw <your program>
> > > ...
> > > (gdb) set remotebaud 9600
> > > (gdb) target mon2000 /dev/com1
> > >
> > > I don't know much about the mon2000 target.  If it has a log
> > > facility you may try setting it on.
> > >
> > > Fernando
> > >
> > >
> > >
> > >
> > > Noah Aklilu wrote:
> > > >
> > > > Hi
> > > >         I trying to get gdb (really insight 5.0)
> > > > to talk to a Mitusbishi MSA2000G01 (the m32r
> > > > evaluation board).  I switched the board to monitor/
> > > > self-debugging mode (instead of the default db32r ethernet
> > > > mode) and  get the Mon2000> prompt
> > > > using a terminal emulator.  When I tell gdb to
> > > > connect to the same com port using mon2000 as the
> > > > target (target mon2000 /dev/com1) it comes back with the error
> > > > listed below.
> > > >         I tried other target modes such as target m32r /dev/com1
> > > > but it simply times out.  I am running gdb/insight under cygwin
> > > > 1.1.7 on an NT 4 host (and compiled it there as well).  Any
> > > > comments/tips will be appreciated.
> > > >
> > > > Noah.
> > > >
> > > > -- start here
> > > > monitor_supply_register (21):  bad value from monitor: 7FFFFFF0
> > > > psw =
> > > > 000000C0 (BSM=0, BIE=0,
> > > > BC=0, SM=1, IE=1, C=0)
> > > >  bpc = 00000000
> > > >  r0  = 00000000    r1  = 00000000    r2  = 00000000    r3  = 00000000
> > > >  r4  = 00000000    r5  = 00000000    r6  = 00000000    r7  = 00000000
> > > >  r8  = 00000000    r9  = 00000000    r10 = 00000000    r11 = 00000000
> > > >  r12 = 00000000    r13 = 00000000    r14 = 00000000
> > > >  spu = 009E3200    spi = 009E4200    acc = 00000000:00000000
> > > > >.
> > > >
> > > >     while executing
> > > > "gdb_cmd "set remotebaud $baud""
> > > >     (object "::.targetselection0.targetselection" method
> > > > "::TargetSelection::change_baud" body line 4)
> > > >     invoked from within
> > > > "::.targetselection0.targetselection change_baud
> > > > .targetselection0.targetselection.f.lab.lf.childsite.cb 9600"
> > > >     (in namespace inscope "::TargetSelection" script line 1)
> > > >     invoked from within
> > > > "namespace inscope ::TargetSelection
> > > > {::.targetselection0.targetselection
> > > > change_baud}
> > > > .targetselection0.targetselection.f.lab.lf.childsite.cb 9600"
> > > >     ("after" script)errorCode is NONE
> > > > --end here
> > > >
> > > > ------------------------------------------
> > > > Noah Aklilu
> > > > http://www.ee.ualberta.ca/~aklilu/
> > > > naklilu@ualberta.ca
> > >
> > > --
> > > Fernando Nasser
> > > Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> > > 2323 Yonge Street, Suite #300
> > > Toronto, Ontario   M4P 2C9
> > 
> > ------------------------------------------
> > Noah Aklilu
> > http://www.ee.ualberta.ca/~aklilu/
> > naklilu@ualberta.ca
> 
> -- 
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9



------------------------------------------
Noah Aklilu
http://www.ee.ualberta.ca/~aklilu/
naklilu@ualberta.ca
From naklilu@ualberta.ca Fri Jan 12 21:00:00 2001
From: "Noah Aklilu" <naklilu@ualberta.ca>
To: gdb@sourceware.cygnus.com
Subject: Re: Using GDB with M32R MSA2000 Board
Date: Fri, 12 Jan 2001 21:00:00 -0000
Message-id: <3A5F7E86.26533.594EFA@localhost>
References: <3A5DD05F.D5C5F105@redhat.com>
X-SW-Source: 2001-01/msg00074.html
Content-length: 729

Now on a similar topic but a slight deviation.  Does gdb
have support for debugging over ethernet. The debugger
from Mitsubishi (idb32r) supports downloads and debugging
over ethernet.  Unfortunately it is not elf compatible
instead uses a sysroff format, otherwise I could have
linked its I/O libs to gcc generated program. 

I have a NEC ddb-VR4373 board which came with a prebuilt cygwin
toolkit, and it supports downloads over ethernet but
not direct debugging over ethernet.  Of course I haven't
actually programmed on this board, working on another
project right now.

Maybe something to look towards.

Noah.




------------------------------------------
Noah Aklilu
http://www.ee.ualberta.ca/~aklilu/
naklilu@ualberta.ca
From eliz@is.elta.co.il Sat Jan 13 00:02:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: jtc@redback.com
Cc: shebs@apple.com, fnasser@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Sat, 13 Jan 2001 00:02:00 -0000
Message-id: <1438-Sat13Jan2001095944+0200-eliz@is.elta.co.il>
References: <5md7dt7ski.fsf@jtc.redback.com> <3A5E23C0.A8DF6E48@redhat.com> <5mn1cx6ajc.fsf@jtc.redback.com> <3A5E2E6B.AA61F361@redhat.com> <5m66jl68ez.fsf@jtc.redback.com> <9003-Fri12Jan2001111534+0200-eliz@is.elta.co.il> <7263-Fri12Jan2001122813+0200-eliz@is.elta.co.il> <3A5F5825.CF95E1D6@apple.com> <5m66jk36qu.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00075.html
Content-length: 834

> From: jtc@redback.com (J.T. Conklin)
> Date: 12 Jan 2001 11:33:45 -0800
> 
> >> If we do put each version on its own ChangeLog, we could have
> >> ChangeLog.418, ChangeLog.500, etc.
> 
> Stan> I really like this idea.
> 
> I actually like the split-by-year scheme.  This tends to place about
> the right number of entries in each file regardless of whether there
> are six months or two years between GDB releases.

Why is this important to have ChangeLog files be of similar sizes?

In any case, the decision to start a new ChangeLog is a human one, and
can be based on the size as well.

> It makes it easy to go from the mailing list archives to the
> cooresponding ChangeLog file without any guessing.

You don't need to guess, just to "head ChangeLog.*".

Anyway, if you-all decide to stay with year-based split, I don't mind.
From eliz@is.elta.co.il Sat Jan 13 00:35:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: dj@redhat.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Sat, 13 Jan 2001 00:35:00 -0000
Message-id: <6480-Sat13Jan2001103308+0200-eliz@is.elta.co.il>
References: <5md7dt7ski.fsf@jtc.redback.com> <3405-Fri12Jan2001111148+0200-eliz@is.elta.co.il> <xnofxck5xc.fsf@greed.delorie.com>
X-SW-Source: 2001-01/msg00076.html
Content-length: 811

> From: DJ Delorie <dj@redhat.com>
> Newsgroups: cygnus.gdb
> Date: 12 Jan 2001 12:59:27 -0500
> 
> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > suggest to start this now, and rename all ChangeLog-NNNN into
> > ChangeLog.NNNN.
> 
> They'd also conflict, by dropping the last digit.

Only if we use 4-digit years.  We could use the last 3 digits
instead.  (Yes, it _is_ ugly, which is why I suggested to split the
files by GDB version, not by the year.)

> We might have to handle this in djtar, like the info files.

The GDB distribution already does that, by invoking DJTAR with a
rename file.  I was just trying to keep its size in check.

I'm not sure doing so in DJTAR's code is a good idea: this problem is
unique to GDB, and the right renaming isn't obvious to put it into
code applied automatically.
From eliz@is.elta.co.il Sat Jan 13 00:47:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: fche@redhat.com
Cc: fnasser@redhat.com, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Sat, 13 Jan 2001 00:47:00 -0000
Message-id: <3791-Sat13Jan2001104448+0200-eliz@is.elta.co.il>
References: <5md7dt7ski.fsf@jtc.redback.com> <3405-Fri12Jan2001111148+0200-eliz@is.elta.co.il> <3A5F02FE.83E5B350@redhat.com> <9791-Fri12Jan2001174626+0200-eliz@is.elta.co.il> <o5ely8g1zq.fsf@toenail.toronto.redhat.com>
X-SW-Source: 2001-01/msg00077.html
Content-length: 1408

> From: fche@redhat.com (Frank Ch. Eigler)
> Date: 12 Jan 2001 11:38:01 -0500
> 
> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> 
> : [...]
> : Anyway, I really don't understand the attitude.  [...]
> : Thousands of teenage programmers are exposed to Free Software through
> : using DJGPP.  [...]
> 
> Really?  How would you compare the popularity of Win32 platforms to
> DOS for running GNU tools on?

I don't have any objective data to compare.  Perhaps DJ can contribute
some insight.

What I can tell is that the comp.os.msdos.djgpp news group generates
about 100 messages on any given day.  That's a clear sign of a large
number of users.

Note that many (probably most) users run DJGPP on some version of
Windows nowadays, since DJGPP programs are very nice console
applications (they support long file names on Windows).  I'm guessing
that they use DJGPP because it is very easy to set up and use: unzip
the files, set a couple of environment variables, and start coding.

> Why are Cygwin and DOS mentioned in the same sentence anyway?  Is it
> not the case that any machine that can run Cygwin is unaffected by the
> DOS 8.3 limits?  (VFAT!)

The file-name problem is indeed irrelevant to Cygwin.  But other
nuisances are common to DOS and Windows.  For example, some characters
are invalid in file names on both DOS and Windows, you cannot delete
an open file on some of the Windows version, etc.
From dj@redhat.com Sat Jan 13 10:01:00 2001
From: DJ Delorie <dj@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Sat, 13 Jan 2001 10:01:00 -0000
Message-id: <xn8zofjqc9.fsf@greed.delorie.com>
References: <5md7dt7ski.fsf@jtc.redback.com> <3405-Fri12Jan2001111148+0200-eliz@is.elta.co.il> <3A5F02FE.83E5B350@redhat.com> <9791-Fri12Jan2001174626+0200-eliz@is.elta.co.il> <o5ely8g1zq.fsf@toenail.toronto.redhat.com> <3791-Sat13Jan2001104448+0200-eliz@is.elta.co.il>
X-SW-Source: 2001-01/msg00078.html
Content-length: 698


"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > Really?  How would you compare the popularity of Win32 platforms to
> > DOS for running GNU tools on?
> 
> I don't have any objective data to compare.  Perhaps DJ can contribute
> some insight.

The only data I have is that the web server claims about 1000 people a
day access the zip-picker (the cgi that tells them what to download
and how to install).  Here's one day's summary (last Thursday):

    115	os=dos
     11	os=dosemu
     30	os=unix
      9	os=win3x
    356	os=win95
    673	os=win98
    188	os=winNT

Note that only 95/98 support long file names in DOS, leaving 25% of
all djgpp users with the 8.3 restriction.
From eliz@delorie.com Sun Jan 14 03:37:00 2001
From: Eli Zaretskii <eliz@delorie.com>
To: dj@redhat.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Sun, 14 Jan 2001 03:37:00 -0000
Message-id: <200101141137.GAA16367@indy.delorie.com>
References: <5md7dt7ski.fsf@jtc.redback.com> <3405-Fri12Jan2001111148+0200-eliz@is.elta.co.il> <3A5F02FE.83E5B350@redhat.com> <9791-Fri12Jan2001174626+0200-eliz@is.elta.co.il> <o5ely8g1zq.fsf@toenail.toronto.redhat.com> <3791-Sat13Jan2001104448+0200-eliz@is.elta.co.il> <xn8zofjqc9.fsf@greed.delorie.com>
X-SW-Source: 2001-01/msg00079.html
Content-length: 1162

> From: DJ Delorie <dj@redhat.com>
> Newsgroups: cygnus.gdb
> Date: 13 Jan 2001 12:48:22 -0500
> 
> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > > Really?  How would you compare the popularity of Win32 platforms to
> > > DOS for running GNU tools on?
> > 
> > I don't have any objective data to compare.  Perhaps DJ can contribute
> > some insight.
> 
> The only data I have is that the web server claims about 1000 people a
> day access the zip-picker (the cgi that tells them what to download
> and how to install).

1000 per DAY??  Wow! that surprises even me...

> Here's one day's summary (last Thursday):
> 
>     115	os=dos
>      11	os=dosemu
>      30	os=unix
>       9	os=win3x
>     356	os=win95
>     673	os=win98
>     188	os=winNT
> 
> Note that only 95/98 support long file names in DOS, leaving 25% of
> all djgpp users with the 8.3 restriction.

I suspect that some of those registered under NT are actually using
Windows 2000, where long file names _are_ supported, since the
zip-picker doesn't distinguish between these two versions.

Anyway, I hoped that you might have some data about Cygwin downloads
as well, so that we could compare.
From cgf@redhat.com Sun Jan 14 10:17:00 2001
From: Christopher Faylor <cgf@redhat.com>
To: gdb@sources.redhat.com
Subject: Re: changelog rotation...
Date: Sun, 14 Jan 2001 10:17:00 -0000
Message-id: <20010114131735.G24031@redhat.com>
References: <5md7dt7ski.fsf@jtc.redback.com> <3405-Fri12Jan2001111148+0200-eliz@is.elta.co.il> <3A5F02FE.83E5B350@redhat.com> <9791-Fri12Jan2001174626+0200-eliz@is.elta.co.il> <o5ely8g1zq.fsf@toenail.toronto.redhat.com> <3791-Sat13Jan2001104448+0200-eliz@is.elta.co.il> <xn8zofjqc9.fsf@greed.delorie.com> <200101141137.GAA16367@indy.delorie.com>
X-SW-Source: 2001-01/msg00080.html
Content-length: 683

On Sun, Jan 14, 2001 at 06:37:52AM -0500, Eli Zaretskii wrote:
>> Here's one day's summary (last Thursday):
>> 
>>     115	os=dos
>>      11	os=dosemu
>>      30	os=unix
>>       9	os=win3x
>>     356	os=win95
>>     673	os=win98
>>     188	os=winNT
>> 
>> Note that only 95/98 support long file names in DOS, leaving 25% of
>> all djgpp users with the 8.3 restriction.
>
>I suspect that some of those registered under NT are actually using
>Windows 2000, where long file names _are_ supported, since the
>zip-picker doesn't distinguish between these two versions.

Haven't long filenames been supported since almost forever on Windows NT?
I use them on a 3.5 system, at least.

cgf
From fnasser@redhat.com Sun Jan 14 10:39:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: Christopher Faylor <cgf@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: changelog rotation...
Date: Sun, 14 Jan 2001 10:39:00 -0000
Message-id: <3A61F1F9.9E83D82C@redhat.com>
References: <5md7dt7ski.fsf@jtc.redback.com> <3405-Fri12Jan2001111148+0200-eliz@is.elta.co.il> <3A5F02FE.83E5B350@redhat.com> <9791-Fri12Jan2001174626+0200-eliz@is.elta.co.il> <o5ely8g1zq.fsf@toenail.toronto.redhat.com> <3791-Sat13Jan2001104448+0200-eliz@is.elta.co.il> <xn8zofjqc9.fsf@greed.delorie.com> <200101141137.GAA16367@indy.delorie.com> <20010114131735.G24031@redhat.com>
X-SW-Source: 2001-01/msg00081.html
Content-length: 718

Christopher Faylor wrote:
> 
> On Sun, Jan 14, 2001 at 06:37:52AM -0500, Eli Zaretskii wrote:
> >> Here's one day's summary (last Thursday):
> >>
> >>     115      os=dos
> >>      11      os=dosemu
> >>      30      os=unix
> >>       9      os=win3x
> >>     356      os=win95
> >>     673      os=win98
> >>     188      os=winNT

Do we build gdb natively on a DOS system or is it generated with
--build --host --target on a higher system?

Keeping the installed file names is not hard.  If we build on a
different host
the 8.3 restriction on source files won't hurt.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From ac131313@cygnus.com Sun Jan 14 16:36:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Christopher Faylor <cgf@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: [qqi@world.std.com: link update]
Date: Sun, 14 Jan 2001 16:36:00 -0000
Message-id: <3A6245B2.98DE0574@cygnus.com>
References: <20001222111413.A11450@redhat.com>
X-SW-Source: 2001-01/msg00082.html
Content-length: 873

Christopher Faylor wrote:
> 
> Who's maintaining the gdb web site these days?

It tends to be me however there is _nothing_ stopping others playing
with the pages :-)
I've fixed the below.

	enjoy,
		Andrew

> ----- Forwarded message from Quality Quorum <qqi@world.std.com> -----
> 
> From: Quality Quorum <qqi@world.std.com>
> To: sourcemaster@sources.redhat.com
> Subject: link update
> Date: Fri, 22 Dec 2000 00:38:45 -0500
> 
> Hi,
> 
> There are two links to my website from http://sources.redhat.com/gdb:
> 
> http://www.std.com/qqi/labslave/rproxy.html
> http://www.std.com/qqi/ftp/protocol.txt
> 
> They are moved to
> 
> http://world.std.com/~qqi/labslave/rproxy.html
> http://world.std.com/~qqi/download/protocol.txt
> 
> Please, update your links and let me know, I am going to
> remove old site.
> 
> Thanks,
> 
> Aleksey
> 
> ----- End forwarded message -----
From d_iftikhar@hotmail.com Mon Jan 15 00:37:00 2001
From: "danish iftikhar" <d_iftikhar@hotmail.com>
To: gdb@sourceware.cygnus.com
Subject: Jeeni + Ep7211
Date: Mon, 15 Jan 2001 00:37:00 -0000
Message-id: <F222FojonDUmeRXHQIV000050eb@hotmail.com>
X-SW-Source: 2001-01/msg00083.html
Content-length: 1879

  Hi

   I am trying to use Jeeni to debug my application .
I downloaded the code to the EP7211 target board . But the program is not 
able to come upto main() even . Doing "stepi" ( as "step" causes it to hang) 
i found that it goes till "cyg_hal_invoke_constructors" and hangs inside 
that .
  Earlier also i was stucked at same place . Hope something significant has 
been achived to solve this problem .
I am attching the rdi.log file produced when i tried to "continue" the code 
. can any of you make out from this what's happenning .
  The log file was enabled after downloading the code : so it shows the last 
couple of transactions happened between the two guys :
ADP log file opened at Mon Jan 15 19:02:40 2001

tx: [T=0 L=25] 01 5e 5d 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff 
ff 00 20 00 00
R=00010005 H->T CI_HADP:  ADP_CPUread ff 00002000
rx: [T=0 L=28] 01 5e 5e 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff 
00 00 00 00 54 18 00 00
R=80010005 H<-T CI_HADP:  ADP_CPUread 00000000 00001854
tx: [T=0 L=29] 01 5f 5e 01 09 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff 
44 85 00 00 00 00 00 00 00
R=00010009 H->T CI_HADP:  ADP_SetBreak 00008544 00000000 00000000
rx: [T=0 L=36] 01 5f 5f 01 09 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff 
00 00 00 00 78 ec 03 00 74 fe 1e 00 dc 98 00 00
R=80010009 H<-T CI_HADP:  ADP_SetBreak 00000000 0003ec78 001efe74 000098dc
tx: [T=0 L=24] 01 60 5f 01 0d 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff 
00 00 00 00
R=0001000d H->T CI_HADP:  ADP_Execute 00000000
rx: [T=0 L=24] 01 60 60 01 0d 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff 
00 00 00 00
R=8001000d H<-T CI_HADP:  ADP_Execute 00000000


   Nothing comes after this .

whats wrong here ??

regards
danish.

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com .

Re: changelog rotation...

[Eli Zaretskii]

> Date: Sun, 14 Jan 2001 13:17:35 -0500
> From: Christopher Faylor <cgf@redhat.com>
> 
> >I suspect that some of those registered under NT are actually using
> >Windows 2000, where long file names _are_ supported, since the
> >zip-picker doesn't distinguish between these two versions.
> 
> Haven't long filenames been supported since almost forever on Windows NT?
> I use them on a 3.5 system, at least.

For native Windows programs, that's true, of course.  But DJGPP
programs are DOS executables, as far as Windows is concerned, and DOS
executables are barred from issuing the Win32 API calls for file
access.  So DJGPP programs cannot access the long file names except
through a special API avail;able to DOS programs (a bunch of functions
of Int 21h).  That API is not supported by NT versions before 5
(i.e. before W2K).  Windows 9X always had it included.  The DJGPP
library detects this API at startup and automatically switches all
library functions to use that API, thereby proividing a transparent
support for long file names.
From eliz@delorie.com Mon Jan 15 03:14:00 2001
From: Eli Zaretskii <eliz@delorie.com>
To: fnasser@redhat.com
Cc: cgf@redhat.com, gdb@sources.redhat.com
Subject: Re: changelog rotation...
Date: Mon, 15 Jan 2001 03:14:00 -0000
Message-id: <200101151114.GAA11874@indy.delorie.com>
References: <5md7dt7ski.fsf@jtc.redback.com> <3405-Fri12Jan2001111148+0200-eliz@is.elta.co.il> <3A5F02FE.83E5B350@redhat.com> <9791-Fri12Jan2001174626+0200-eliz@is.elta.co.il> <o5ely8g1zq.fsf@toenail.toronto.redhat.com> <3791-Sat13Jan2001104448+0200-eliz@is.elta.co.il> <xn8zofjqc9.fsf@greed.delorie.com> <200101141137.GAA16367@indy.delorie.com> <20010114131735.G24031@redhat.com> <3A61F1F9.9E83D82C@redhat.com>
X-SW-Source: 2001-01/msg00085.html
Content-length: 413

> Date: Sun, 14 Jan 2001 13:37:45 -0500
> From: Fernando Nasser <fnasser@redhat.com>
> 
> Do we build gdb natively on a DOS system or is it generated with
> --build --host --target on a higher system?

It is mostly built natively.  Cross-compilation is not something a
typical DJGPP user will consider, and even some of the developers use
native build environment for whatever packages whose ports they maintain.
From ac131313@cygnus.com Mon Jan 15 04:14:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: haberg@matematik.su.se
Subject: C++ Q on types
Date: Mon, 15 Jan 2001 04:14:00 -0000
Message-id: <3A62E909.554EECBA@cygnus.com>
X-SW-Source: 2001-01/msg00086.html
Content-length: 1252

Via RMS:
> A user (haberg@matematik.su.se) sent me this explanation of a feature
> in some other debuggers:
> 
>     C++ has makes available various runtime information (RTTI). C++ has a
>     single one form of a polymorphic variable, or an object which can change
>     its type at runtime, namely the polymorphic pointer: If one has a class A
>     and derives from it a class B, then one can write
>       A* ap = new B();
>     The static type pointer to an  A  named  ap  now points to a dynamically
>     allocated  B  pointer. It means that in the C++ static typing, this is just
>     an  ap  pointer, but C++ has mechanism for keeping track of the dynamic
>     type  B, for example, via "virtual functions", or by using C++ RTTI...
> 
>     Now to the debugging: If the debugger only handles C++ static typing, it
>     will show that  ap  is an  A, and will only display that structure of it
>     (the names in that class and their values).
> 
>     But if the debugger handles C++ dynamic data, it will show that the  ap  is
>     actually a  B, and will show that (the names in that class  B  and their
>     values).
> 
> Does GDB have the ability to determine the actual type
> of *ap, and display it accordingly?

Something for TODO?
From moshaughnessy@quarrytech.com Mon Jan 15 10:43:00 2001
From: "O'Shaughnessy, Mike" <moshaughnessy@quarrytech.com>
To: "'gdb@sourceware.cygnus.com'" <gdb@sourceware.cygnus.com>
Cc: "O'Shaughnessy, Mike" <moshaughnessy@quarrytech.com>
Subject: gdb with HP probes?
Date: Mon, 15 Jan 2001 10:43:00 -0000
Message-id: <496A8683261CD211BF6C0008C733261AA25138@email.quarrytech.com>
X-SW-Source: 2001-01/msg00087.html
Content-length: 817

I haven't seen anything in the FAQs or archives...

Is anyone aware of any existing modification to gdb to allow it to be used
with HP/Agilent probes (E5900A/E5900B)?  We have quite a few probes that
we used with the SDS SingleStep debugger with WRS Tornado/gcc 2.7.2.

We've upgraded to gcc 2.95.2, which likes to use dwarf along with stabs, and
the SingleStep will not work with it for C++ code.  I'd like to replace
SingleStep
with gdb, but we'd really like to use the probes - they connect to the J-TAG
connectors on our embedded PowerPC product.

thanks!

--------------------------------------------------------
Mike O'Shaughnessy               Tel (781) 505-8300 x303
Quarry Technologies, Inc.        Fax (781) 505-8316
8 New England Executive Park, Burlington, MA  01803
email: moshaughnessy@quarrytech.com