Re: Using GDB with M32R MSA2000 Board

[Fernando Nasser <fnasser@redhat.com>]

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

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
From lache@tu-harburg.de Thu Jan 11 09:06:00 2001
From: Jens-Christian Lache <lache@tu-harburg.de>
To: Fernando Nasser <fnasser@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: [aeb] Re: GNU toolchain and AEB
Date: Thu, 11 Jan 2001 09:06:00 -0000
Message-id: <01011118041900.03542@lab04>
References: <2358-327@arm.com> <01011110035102.01238@lab04> <3A5DD348.37A7F802@redhat.com>
X-SW-Source: 2001-01/msg00046.html
Content-type: multipart/mixed; boundary="----------=_1583534239-23287-0"

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

------------=_1583534239-23287-0
Content-length: 2782

Hi everybody!
This is a bug report about:

Today I encounter a problem with the gdb. I had the tooltips for variables
turned on. When moving the mousepointer over a field of a class, gdb startet to
allocote ruff amounts of mem. Only the limit of 128MB of swap could stop
it, it crashed and my X crashed too. I could mail you the project
and explain you how to reproduce this error.

This is how to reproduce it:

1.) install & say "make" in the adeos dir
2.) download & start it to a AT91EB01 or AT91EB40
It will stop in "main" at "os.start();"
3.) set a breakpoint in sched.cpp, function "Sched::start(void)",
third line "schedule();"
4.) continue
5.) move mousepointer over "state" from the line above
"state = Started;" Having
tooltips turned on, it should crash. Or try to add it to the list of
watch exprecions.

My arm-elf-gdb is from 20001212.

Regards,

Jens-Christian

Am Don, 11 Jan 2001 schrieben Sie:
> Jens-Christian Lache wrote:
> > 
> > > Yes this sounds serious.  But I guess I know that it is caused by a
> > > bug in the C++ symbol handling in GDB.  It gets into an infinite loop
> > > when we are looking for an overloaded symbol (I don't know the
> > > exact circunstances).
> > >
> > > Someone has been fixing C++ things lately.  Have you tried getting the
> > > latest insight from CVS to see if it works better for you?
> > Could you be a little more precise about lately? Mine is from 20001212.
> 
> Jee! That sounds new enough.
> 
> I guess I will have to take you on your offer to try to reproduce it.
> 
> What I am going to do is to try and find someone from the GDB C++ area
> to look at it.  I myself have not played with that code for a while and
> I am full of GUI stuff to do.
> 
> I have seem a similar problem, so I will bug them with this one as well.
> Lets hope they find it fast.
> 
> Maybe you should turn off your variable ballons in the meanwhile to
> avoid accidentaly
> tripping over one of those classes.  There is a preference under
> Preferences->Source
> to turn them off.
> 
> 
> > Thank´s again for your great support,  :-)
> > 
> You're welcome.
> 
> 
> P.S.:  Can you post your messages to the list?  We use the archives as a
> knowledge base
>        so if other people have a similar problem they can use our
> findings by searching
>        the old messages.  Also, sometimes there are other people who
> know something
>        about the problem we are tracking down and they can jump in and
> help us.
> :-)
> 
> 
> -- 
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

------------=_1583534239-23287-0
Content-Type: application/x-gzip; charset=binary; name="adeos.tgz"
Content-Disposition: inline; filename="adeos.tgz"
Content-Transfer-Encoding: base64
Content-Length: 8113

H4sIAPTmXToAA+09a3PbNrb5av4KxO6ktqsHJVlWIl/vrF/ZqGvHHsvZdO5j
MjQJWWwokktSdrwd319+P9xz8CJIkbaSiHK3FVpHIHgIHADnCR6AlkODuPmi
0mSaO2av24Vfs2V2Ovhrml2T//L0wuy1273ObqfT6r0AqN5O7wXpVosWT9M4
sSJCXniWPaaPwI3dO3cZ+Cw5WWz+Eyv+3LDDsJo2YD7N3Z2dkvlvtXd6HT7/
ZrfV7UA5FLXMF8SsBp1s+pPPf3N7Ickg+D9563rUtya0TyBJosIb+HdMYzty
w8QN/D458Ik7CT06oX5iYREJRiSilldP3Allz8ZkFETk4PjkfNgQ9b8PEhqz
yiGJMvw7CsL7yL0ZJ2TT3iKtN29ek+t7cubaY4t65NCKogYhV2M3JnEwSu6s
iBLIhzDn1CGunwRYSTKmJJxee65NnGBiuT6xfIdMrHtyTck0BkjEx/LvASoK
g5hCne+CO3pLoxo87MZYiR8krk3JBMgK8/goIOHfwNPwcEQnwS1ksWI/IIBI
ZPnJPSJDXWg/wirolzCiccyfwEFyIQvdcZNY4CcGLCKOGyeRez3FaxyjhaSm
YWy4vu1NHUrWmXxojNcN+iWhkU9uA9chduAncD3w3WTziOfJdo3f29yOpv7W
5hVMINneqhGeqeEoQ9/CYWLZn6+CcGuvqMbhnZvY47ROEp57jriqEa34Pb0T
V1CRgW0MHKQJzPX7PiLnkH1iwk1jsSR+RpNx4AgaxOZOYQ42t8TdDI0fAT0n
lFjEp3fEc/3PMI8eQCOpMwLPkvWaIGr2d0mTaeSLwveBT4lDR65PHfHMQlLT
kB3o97Wu/GZgoyHMEgzh+w+npzCKD1DS3NY6TJBOqhxb149pVDKyA3YPRhaH
kTEwsBQwhEMjNsZqqAtG+ArY3LY8j0bIdsBpYeDH7rVHGXsDR1nAYv4N1kqj
aBombJqWOSnNJmMK/E3nRwwHZyeYHPjdQojf8B9Ji4ACkSkMLyJ6CzP4CmVT
/S84n4wdOHizmebIR8v7DELvzmdCMB1HoNWpn7gejLQHki4iYeQGkQsSiw88
iuipD92fqfRuDKoAhIHA4iUnJPLqFUcd0JE1/ce+AttKi7dkRap/2T7pj7wH
dt+TYA/FPRQUg91DbmToWwkT2yQMUDi5vPMZ4pmpSSKPTQIaAgnV+LZCkAHu
MVwE60h6ZozDhN7jk0uM34ghOy7vyOq1KSWGgoLG9Pw7UDMwCaxbthVTlDvA
JnQSwrCzDpLCR90R2ZQt8XnbSm9qSOVnRfZ6FiJijLNH0jsP5Wh/LzEWd0oQ
JMdVzmBKljMoa5OtU2qW6jR6nWeEyEwFe3ONyDcRLykehxwFl+OTI2WCOiBP
xlXKf24rFcv/S3ZPyv9RFEyQKJYi9g/4iEM1oHRwzKVNx8xdQs4jTlLARG4C
Fl7s/5hgJZnECLVQ4ixauUN9qZgRQ5rVIVzbK+1RpjY4HRmFPKrbNpxFsdSh
lpPXE1ot5RpCKxI4MraapcwCLcA4KY/tiR9PweRPxhZnIoYUTA2x7GQKNHFf
gB4Kwe2cFMzhwaUa2WT3SpoWlKpaZbQ6O+vpMzkVojpm6C3yYUnNMskrVTDl
26lvc65DBKZ+MUeCXZ8aZOje2B61/GlIrBHyCrACZwj6xU3iMncuw22ssDoj
i1lY2J0ibkjnj/dLTl8N/TD6hdrgcYGswGIrjgPbBTsf3EMxUpn5FLMIbm50
f4GSY3NLTCZFKXI0hGtSmposgSfhgltpeWRIWQvkkN64fimtAb9liS22x9SZ
guz7MSaOlVgE3MYp0D6IwQyy4OqBz+Lco7hoCKKStCbuh5dT34fOs2FT7kEW
kbcRTUkemozR6SNxCO52pjmHehQcJEnozDcUlUFLEuknBogMORxOCBtgiQ13
+KGckjvX80B1gqeODjl0ER9ppOyDVF25QsNezuEoKg5ywb12Lc/9F2WuPwxi
QrOcU8gyC1ch3DfcFN69JPKtTXDuL6RpFHIHn030EDCWjKQKSHOfxPAbjDYB
cGZGkcYD/xatnOt76Boq1zsw/YA8F8srRP4O0tGVlFqPQ2q7I1z/AR7JagNH
NbOfWWT46ac92VGYQQFwiTzEy5XxiOWhwl52SsgEuCfHdc9Y44wg6kKSAIj/
UiP5P6JiZsAJoEIuzPUwjAKbgrCK5GJLpoP6ks4rW664AGPwpa2aWLkhP2lz
zHoz26qyVVPnnNtJMCiz+i4jcoRxiS2y2r9fFqSDDYrnCQIqpaAT38msgHBh
8dxLtwtJfP3/zPoMOtZ7bP37O9IT6/8mKxPvf9q7bbb+b67W/5eSNsiv1I/r
9jgC/nMtn/wMf+Yb0oaJMTaOjvab42BCm9j7JhuiZhIEXtx8V3d3X+/WQ7sO
zDb9Ur/xp81r129a0aROvVH9xrYNeDpz+fb04G/DfWOjfkvqIzq5po5Dnbr9
5YtxfHL44W/8dv3GOL+4GpwN/vPganD+XjxzdHH6YYh/aY0//WScDg6PB5fw
zOlXYOm5101Ap46/orJmu/Gm22iTr6pHPgv1lD+oATW/rvoK0DQG749OPxyf
8DEbzFRiNwd82R8G9v3fTy4/DY8uBxdXsyRgN5n3EomfBjdl4MfYOD/8+e3g
9GS4D+19SuxGQDBjuTIXuoHIgYL55Eb/lOWxyMQjkZnGYHlDnl3cOZADaF4l
ZnhFmJOAmGdw11ZMP1kOZA1w7vpra/wlBowE+W9jbU0KO2Ptr9QeB2QdBMAN
BefF89aNNTskQJ/bDBoI2lDP9idTUIqNAKog3KAWeeb486zreFRkpZLlV/g6
SWTFGxWWv45DkZPg/Io3NdaaGqdN8WxpL7B66McPm0dHW6R+fHD1pnW2Y4JA
hQvGZ/K3TX7Y1ChiC/QbDk89ID/8ldQ/erX61Q+bGUrYkphhTzBxtZkORlqm
BiUtUoOTFumDlJbywSIG/+2zHzsMS7vM4VSf4V8mNbby/cPeHPJsZlx+2Ezl
D0LNyB+At4lEwxBDIOjhUcQ4ZOWYSUQMMRN9/vsYagKyatQUIgYniL58KVyK
GIerGi/1bpoTZZ/9PIYWh6saLYkGQ+sT+EFJfxktDg3FiH2Ze2wwFHTV46Eh
w2cqnnOm4u/BrAiXYTo3G1K19UXGTnHZUK3O1Ra/+HR1eXB0MueQcPEsW+bI
MPXal7lnQoc1zfFhurkvc8+ED2ua46NMjb5+9Ux4qebFWMVyqOJnG6lYIoPG
V19kngkZbJkjI+y6fpp/JpRE4xwrtDD7IvNM+GDLxoa0hvsiMyRgpDbAZWi4
Pig4W2WRMWUeYE12MbFyyB9gK6wJWR9vgvOyzGUbwZKSVlrztMJq5M3IyU7z
2aZ42fc0JmrlzbFZFJlsQ1DwPa1gfcZG6oH0VXaYqY9eu4XDqDWf7bI2ocAi
6tFYZUuQSts3Ngz2UmYNbApwbuojsv2/wtHZBnN7uxGjw9NkJQak516aWKUl
JL7+h/NeXRtfFf/dxfW/Vre1u4r/Xkbi8y/WJCpq4/H1X7PV7nXT+O82W/9t
m93V+u8yUoXx34KoCsO/MRpnTAEiIqizeGjGNKZRzIJj4e45eFx8NXIV/L3s
4O+R79AR+cRC7z+9MzZ4AEZaoAeIsyXMda2Ar1HqJWIFUy8SC5zraWv4ClO1
xCKBiGlsUN9xR9gey+D7N4nEH+YN3PMmLv/VMl0lbTzx/q/V6faE/N8127st
lP/dzkr+LyVVKP/Ttd+5NwCB7JvA/VsVsYQv8h/fBcTiOgMfZtEHEclCKjHc
EJUKSnoV0pEE5CCyg8mPMZkJx7xiK4et169PDsnYihzUEY2Vhlni9qKiaIzM
BiFcfWUhSMUbh343W5FYAEq/z36GPCZIFPEIoX3ywU8Duxx4ArHhSQCqCORT
mHuP72KaAboWkS4q5sgU+6A4bQuowmA9GQ+soFT8jcSfVRnEbPsCezSDHswE
C4LBTI2YNdJqv96qeKMVa7tsL1AmzCkIaWSx6Mz4Pk7opFBonCH/XIuAcKB+
CqxHGe8FyCYkCjDAk8oI7fPhyyVHp+pkxMleBNRhWDKnpJc5UtqSuywMLSBt
XxseJ40XFsNZecgj6tbiLVxrPLB2MvUSFy1GmLD5o4KZqFVzhBH2JJ6GKDMd
lPN8HEB8DljIsRPQuDYj8+HGhFp+nEaFg8eBMeEoVsMIyci712Iwqwg/TiUD
jFLpLA+enGM2lji/a4ZSvE8Fy5Fvi53lwc968KyY4+ppSfWqMP6cetRO9BBa
IASM9Z36hXQ1GHFDIaUiKQxY0DQI/zHT0GQwvKwx8pihIIkQHyFoCwgwCUEk
ONomCJ/GTBh5KMtnquCzyaJd/0WjQGKaSQvYuFKxsGJqUxGznCadnqViQh3K
N8ZlSkGFiu1ys9QvaDtH+Wm86YUYdByZlJj5BKRDwmxBsP5CDDif3eiRU7nQ
rCk2dKW7PVKNu09ae7lNICW7PxiVUW4OWmQMJiSN6iokmEfE8n0FMTM3kBDc
ZAa9jBoH5NKAWdydM4OpHGWMONaeTHGWA07yVe0ZMzD1v0gpI6rSqslaF9o0
SgiGvMJG30WTxRhT1u5CyBp5lWJhKxtLPvCgctSLaUmtsnWtG2lwdnHTr9Jn
VCD0HIg8pBJRSarKhSKLix/EUbGOPfBkKDboNr75U1E6iWl0i76ElIAsGr3E
xQLyhf99igHkVnQPbk5WbaIADHzQl0omzoixwLdpvc53A+FjKSIZESk2Z8RK
Hj6bIFNDqwuyBe1DyMob3EOw0Bj1lCqqJ0BAuYz+yNfR3xc3WZFfSn5iYCun
vnp9zyhThCCyTdyRqXTfo1rRTEXiPCZo2XaNhwUzg6TQ1YpxQeLrvyqCtJI2
nnj/t9tqmdr7v11c/901d1brv8tIFa7/pmHJc6//Xrs+k+90YoXjACz61RFQ
v6M12motiTMklzn2x3KyWvI+WIZcvy9xXKg6lo7Jwa3leuDMU65G7ywX7RLl
m2W3eX6vdlyT6lF0qXJDMbE+lyzdfISOcr7ic8tXbsBZhxmXQ8KWYHxWCcmb
ic9xcICgB9apwoWOI8vzlN89s4d57TvIJV0d2ddoJn82hVg94Fm2hsTHFhci
5DMgvIYoXO7luDKhJFZPi2qSlPqOek5q65USKt7kvrFy0OdCELHB5dsDxxFn
F7GxVMt6WCYa1fYT5yrVZwAwyp1csFcIly4SfOTVp2CFJyNoj24Vj4fY0JyD
1Gt92lIuXaYVNz8yztAHMKIetUB71NTwscVbIKFYO70CF6YaVVjcnNVRopCK
Twhi3Sw7IojdTIUKOowwNmOgXVSlecL63cgU2atCsSLoskSsfPWsMbESF8gV
5PCZY3e0xoFF8myfX/bToV8+vvSnsa2kaRRIOEUjN4r5pjBw4R/h/IJqCuSS
jlTmyKCiPj66ZFh0bIH+MM6GkX/iUV4vc4cxzbXUWWJHpM8vmM0V+60c63/f
pPv/zxX/u9Peyfv/7e7K/19Kqtz/L47/fafF/qLpj4Kd6T9ie1ZcekDYytmv
OOT37MPVyS96yK8sKAj5NQw2V3ze5KHBDN9+qvmEe6kZB2yVm6Se017uTsb+
kc+FkXsL2k2rOI1i0vS81gz1pxPyW6oMa8ymIQ9cTe4ZD3sqrHgNw4pFR/9s
ukzs/8EZrayNJ+R/u9eR+39ABaAuaLV2e7sr+b+MVJX8X2MkVSz7RYQtk4ph
FPwKtmV69Fo+fg8crgRYeKUSnkslHA4vdIXALw2DnyApA2Fl3JoIUx1c7GWu
j4bZ67eedRPz4+P04mHusWHuseEge308TJWHEOgz21AU5spPJlY8AV3jwRDi
AbTrfhCub6VgwjsqhsLzvGFiWaA56iTquTcu+H5Ap2cBNGtN4xs6+r9xlJA7
GjnUfwlPrJ38cnF+ebV2cHl2zMK16AB8u2Yzf712djlci1rtGjm6GF5iwfnl
JS9g/2y8DyTg8HINYdgNVnD+j7XQrhEvMthh5VqTJ36mRf1ytsHDwdFXNwiX
In56/WidwBU/sp1r88XEZ8/U923R2Wk1ejh5s/mwp3VisXgXVfptyGdq0vHX
rRjGnV9jw+j7f57J/2ubnZ7m//X4/s/2Sv8vI1W+/2d+/49vPVj5f8+p7IdH
706OdXUvC6SzxyapzNkT2wpmnD0RIp739LTl0PwTaQRb/iEVzqM9gy4dzGK6
/aX4VY8Gxj3HdOMLyTmO2v6d37LbLGp6PH5NhieTB4HOrKMqWtV3BAkXtAh9
keQmmxmgdCNQPo7rUVAVpsUdX6FLOMexjT66EhFz/mdzhf+Uiet/ce5nRW2A
Pjd7vd6T53/s7u50u/gtwNaO2e29IO1GQ2JW3ekkf3L9r33/sbIFoKfsv/aO
mf/+o7mzWv9fSqr6+4/zm39M/a2sv+e0/q4Ohn/XjT9xbRjJfUgRYurH7g1u
cINeRoR/dnGv5K78NgSaG2hSIbS0qNgL9ZrcUVST4TbMiuJ2JkLnzEztg1ZP
fpAi/zmKveyLg0H6OQdXi2S6SD/WIGw50QP92WH6pYecHSc9d5GEt5/eZ+sD
7JBj+akTvV5tx4L+yR9M3PLd3E4/GLGl7N9Sg1P2k3+nQrzwSAcXzd4yOz79
yuMMEuq7jJnP5sz2pOhTUwA1A8cjR/IvYzjhrQzQ6hPX//Js22raeEL/m73O
rrb+g+9/2p3d1fkvS0mL0/9M+ffTY5Kh5B80ipm+NxstvL7gL3v6/GgwpspZ
ZLfTJ79aPmmZxGRwpxbo00kA0gCUYV9o/qNggnsF+qCuUdeOQV+85LcEwME0
GQdRn/yMH7Q4Uh+0OMWJZfhB5ppGFOyEPrkadMgVtce+i6sQ4NODtp+A3Pws
8Bw1yDGYEVdjsA1AYNLpiG/fHidJ2G827+7uGonbaSTTOui662l00wAnxaHT
BKprLlA35w4/YSFfuTcTePc0CMI+ufaIvFgHafswh/QU8T/ibPtqaOwJ/geX
r6fe/3b4+U87Zm/F/8tIFdr/Y+p5Qfn+H7L+DgHA+Asiz3m5TqwwVNbu9dT1
EhbxGYS4Meix85/AnAZZgVsQMbxXvFyuu2DShmBRgMjAUHLcIToqPsdBPkLk
A2DRj4Hpryn1iW2F+Jk89bFOh+Km1Zk6HHwXGDFLf+YFNkdOeTUrD2Yp36s3
qv0QJjq3B9L1KI5AP8Sv44hPnznk9OSYJBio704oHgYRU/APHLXFeJamgynu
VfZAlj9C12o+3WSWsDG8PWYIqKfVs+p7c8BhNzegM3DhXpJo+WE76NNYuI2A
beUe4bo4ZThWEA+fHeI0HD6n/oBCSWTWyEbLXO8T+G89MteZR1IE2ELAlgRs
lQPi6+9WWwK2ywE7CNiRgJ1ywB0E3JGAO+WAXQTsSsBuOeAuAu5KwN1ywB4C
9iRgrxzwNQK+loCvywHfIOAbCfiGA6YbQDLMUflXabG9wwwzzuqbIdA9fp8W
HfQJniNwQ+VeIvBnXcsjYRAlBIS3C4Ynss4jh2HMxZu/O2Y6/Apm6szLTJ15
makzLzN15mWmzrzM1JmXmTrzMlNnXmbqzMtMnSwzaZx0mOMk/p7widP4OBBj
xM0MOwJAF6C6rXYG6nAz01QNPwAooRbFu5IvM7yLhkux/mS8otRUwdlX7LWy
/A4zsxBnVKD68DE7H+SxheVZNlVNayeg8c2RLxfHn4I92ShIrjT4ZiH50pyt
mckj2djH55/6njEf07mWz7j/p74+V4mP8eT+D/X+p9Pb6YjzH1bf/1xKWvj6
jyKlRxeACtZ+nlz4+cMv9qj3MEfn769OfrnSX8WkRd9+1PrvJGSXS11c8l/g
Cb4LOLpXnjHf1Ef7ufmz6pSV/9UsAT4l/ztmS1v/x/iPTqu9kv9LSRXJ/2rf
AIRRcOs6NCbOdDK5V4YaPy0IITWZwtauMoLhD69HitfDFiZs2TsILFRuzCgI
2Imo+MvPgXswvlsiFzbTFs20VTPPzUCrtEqrtEqrtEr/hun/AWN+wgoAoAAA

------------=_1583534239-23287-0--
From jtc@redback.com Thu Jan 11 12:16:00 2001
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: changelog rotation...
Date: Thu, 11 Jan 2001 12:16:00 -0000
Message-id: <5md7dt7ski.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00047.html
Content-length: 348

Now that gcc and binutils have rotated ChangeLogs, should we do the
same for gdb?  By existing convention, the new ChangeLog file would be
ChangeLog-00.

Is there any reason not to use it?  The only drawback is that a sorted
directory listing wouldn't keep the files in numerically correct order.

        --jtc
 
-- 
J.T. Conklin
RedBack Networks
From fnasser@redhat.com Thu Jan 11 13:22:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Thu, 11 Jan 2001 13:22:00 -0000
Message-id: <3A5E23C0.A8DF6E48@redhat.com>
References: <5md7dt7ski.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00048.html
Content-length: 564

"J.T. Conklin" wrote:
> 
> Now that gcc and binutils have rotated ChangeLogs, should we do the
> same for gdb?  By existing convention, the new ChangeLog file would be
> ChangeLog-00.
> 
> Is there any reason not to use it?  The only drawback is that a sorted
> directory listing wouldn't keep the files in numerically correct order.
> 

We use 4 digits for gdbtk ChangeLogs.  Maybe we should do this for gdb
as well.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From jtc@redback.com Thu Jan 11 13:31:00 2001
From: jtc@redback.com (J.T. Conklin)
To: Fernando Nasser <fnasser@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Thu, 11 Jan 2001 13:31:00 -0000
Message-id: <5mn1cx6ajc.fsf@jtc.redback.com>
References: <5md7dt7ski.fsf@jtc.redback.com> <3A5E23C0.A8DF6E48@redhat.com>
X-SW-Source: 2001-01/msg00049.html
Content-length: 722

>>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
>> 
>> Now that gcc and binutils have rotated ChangeLogs, should we do the
>> same for gdb?  By existing convention, the new ChangeLog file would be
>> ChangeLog-00.
>> 
>> Is there any reason not to use it?  The only drawback is that a sorted
>> directory listing wouldn't keep the files in numerically correct order.
>> 

Fernando> We use 4 digits for gdbtk ChangeLogs.  Maybe we should do
Fernando> this for gdb as well.

I see no reason not to.  If we did, I'd split ChangeLog-9091 into two
files.  There's not much of a reason for it to be one file anyway, if
everything else is split by single years.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From fnasser@redhat.com Thu Jan 11 14:08:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Thu, 11 Jan 2001 14:08:00 -0000
Message-id: <3A5E2E6B.AA61F361@redhat.com>
References: <5md7dt7ski.fsf@jtc.redback.com> <3A5E23C0.A8DF6E48@redhat.com> <5mn1cx6ajc.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00050.html
Content-length: 1068

"J.T. Conklin" wrote:
> 
> >>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
> >>
> >> Now that gcc and binutils have rotated ChangeLogs, should we do the
> >> same for gdb?  By existing convention, the new ChangeLog file would be
> >> ChangeLog-00.
> >>
> >> Is there any reason not to use it?  The only drawback is that a sorted
> >> directory listing wouldn't keep the files in numerically correct order.
> >>
> 
> Fernando> We use 4 digits for gdbtk ChangeLogs.  Maybe we should do
> Fernando> this for gdb as well.
> 
> I see no reason not to.  If we did, I'd split ChangeLog-9091 into two
> files.  There's not much of a reason for it to be one file anyway, if
> everything else is split by single years.
> 

I agree.  Are you doing the renaming?  Nobody seems to disagree and this
has been the standard practice for years anyway.  I guess it was just a 
question of someone getting around to do it.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From jtc@redback.com Thu Jan 11 14:17:00 2001
From: jtc@redback.com (J.T. Conklin)
To: Fernando Nasser <fnasser@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Thu, 11 Jan 2001 14:17:00 -0000
Message-id: <5m66jl68ez.fsf@jtc.redback.com>
References: <5md7dt7ski.fsf@jtc.redback.com> <3A5E23C0.A8DF6E48@redhat.com> <5mn1cx6ajc.fsf@jtc.redback.com> <3A5E2E6B.AA61F361@redhat.com>
X-SW-Source: 2001-01/msg00051.html
Content-length: 1004

>>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
>> I see no reason not to.  If we did, I'd split ChangeLog-9091 into two
>> files.  There's not much of a reason for it to be one file anyway, if
>> everything else is split by single years.

Fernando> I agree.  Are you doing the renaming?  Nobody seems to
Fernando> disagree and this has been the standard practice for years
Fernando> anyway.  I guess it was just a question of someone getting
Fernando> around to do it.

I'll do the renaming as long as no one really wants to do it.  The
bulk of what I want to do is still stalled waiting for an approval, 
so I'm keeping myself occupied doing little stuff on the side.

So the current proposal is:

        * rename ChangeLog-9X to ChangeLog-199X
        * split ChangeLog-9091 into ChangeLog-1990 and ChangeLog-1991        
        * split ChangeLog-2000 out of ChangeLog.

Any objections?  If not, I intend to check in this tomorrow.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From shebs@apple.com Thu Jan 11 17:18:00 2001
From: Stan Shebs <shebs@apple.com>
To: jtc@redback.com
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Thu, 11 Jan 2001 17:18:00 -0000
Message-id: <3A5E5B35.AC34D5B0@apple.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>
X-SW-Source: 2001-01/msg00052.html
Content-length: 501

"J.T. Conklin" wrote:
> 
> So the current proposal is:
> 
>         * rename ChangeLog-9X to ChangeLog-199X
>         * split ChangeLog-9091 into ChangeLog-1990 and ChangeLog-1991
>         * split ChangeLog-2000 out of ChangeLog.
> 
> Any objections?  If not, I intend to check in this tomorrow.

Coolio, I was hoping somebody would do something like that for GDB.
(I made a ChangeLog-00 for Xconq last week, looked at it for a couple
minutes, said "nahhh" and did just what you're proposing.)

Stan
From cgf@redhat.com Thu Jan 11 20:49:00 2001
From: Christopher Faylor <cgf@redhat.com>
To: gdb@sources.redhat.com
Subject: [zackw@Stanford.EDU: Re: cpplib: Nix -g3.]
Date: Thu, 11 Jan 2001 20:49:00 -0000
Message-id: <20010111234941.A2371@redhat.com>
X-SW-Source: 2001-01/msg00053.html
Content-length: 1409

----- Forwarded message from Zack Weinberg <zackw@Stanford.EDU> -----

From: "Zack Weinberg" <zackw@Stanford.EDU>
To: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: cpplib: Nix -g3.
Date: Thu, 11 Jan 2001 20:40:59 -0800
In-Reply-To: <20010111185440.I32364@daikokuya.demon.co.uk>; from neil@daikokuya.demon.co.uk on Thu, Jan 11, 2001 at 06:54:40PM +0000

On Thu, Jan 11, 2001 at 06:54:40PM +0000, Neil Booth wrote:
> Zack Weinberg wrote:-
> 
> > That too might've been something to do with.  IIRC we're supposed to
> > spit out 
> > 
> > # 1 "file.c"
> > 
> > in between each builtin macro definition.  1 might have been 0.  This
> > was a very long time ago.
> 
> Well, the nice thing is that this is the natural behaviour when you
> remove those if statements.  It also re-preprocesses correctly with
> -fpreprocessed, with the patch below to prevent double-initialization
> of builtins and command line switches.  I must have got something
> right when I moved all this stuff to cppmain.c :-)
> 
> As for # 1 file.c or # 0 file.c, who's the right person to ask?  If 0
> is the line number we want, it won't be too hard to correct, I think.

The gdb people might know.  I'd say leave it as 1 until someone
complains.

zw

----- End forwarded message -----

Does anyone know what the correct layout for # ? "file.c" is supposed
to be?

If this screws up gdb in some way, let's deal with it now...

cgf
From ac131313@cygnus.com Fri Jan 12 01:12:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Arnaud Charlet <charlet@ACT-Europe.FR>
Cc: Fernando Nasser <fnasser@cygnus.com>, Richard Shih-Ping Chan <cshihpin@dso.org.sg>, GDB <gdb@sources.redhat.com>, Kevin Buettner <kevinb@redhat.com>
Subject: Re: GDB TUI doesn't build
Date: Fri, 12 Jan 2001 01:12:00 -0000
Message-id: <3A5ECA3A.68979DAC@cygnus.com>
References: <20010108183654.B467@cshihpin.isl.dso> <3A59DBFD.19EED398@cygnus.com> <20010108165633.F26870@dublin.int.act-europe.fr>
X-SW-Source: 2001-01/msg00054.html
Content-length: 558

Arnaud Charlet wrote:
> 
> > Or maybe you can run the GDB GUI (Insight) instead.
> 
> Or use one of the other available GUI front-ends for GDB, including
> GVD and DDD.
> 
> GVD home page: http://libre.act-europe.fr/gvd
> DDD home page: http://www.gnu.org/software/ddd

FYI, TUI stands for Text-User-Interface. Some of us old farts still like
to use TTYs and keyboard :-)  If anyone is interested, I've some notes
on things that need cleaning up in the TUI.  Per fernando's comment it
would need to be co-ordinated with the TUI maintainer.

	enjoy,
		Andrew
From eliz@is.elta.co.il Fri Jan 12 01:14:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Fri, 12 Jan 2001 01:14:00 -0000
Message-id: <3405-Fri12Jan2001111148+0200-eliz@is.elta.co.il>
References: <5md7dt7ski.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00055.html
Content-length: 503

> From: jtc@redback.com (J.T. Conklin)
> Date: 11 Jan 2001 12:16:29 -0800
> 
> Now that gcc and binutils have rotated ChangeLogs, should we do the
> same for gdb?  By existing convention, the new ChangeLog file would be
> ChangeLog-00.
> 
> Is there any reason not to use it?

Yes: these ChangeLog-NNNN names all clash after truncation to DOS 8+3
limits.

I believe it is a long-term goal to eliminate such problems.  So I'd
suggest to start this now, and rename all ChangeLog-NNNN into
ChangeLog.NNNN.
From eliz@is.elta.co.il Fri Jan 12 01:17:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: jtc@redback.com
Cc: fnasser@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Fri, 12 Jan 2001 01:17:00 -0000
Message-id: <9003-Fri12Jan2001111534+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>
X-SW-Source: 2001-01/msg00056.html
Content-length: 515

> Reply-To: jtc@redback.com
> From: jtc@redback.com (J.T. Conklin)
> Date: 11 Jan 2001 14:17:08 -0800
> 
> So the current proposal is:
> 
>         * rename ChangeLog-9X to ChangeLog-199X
>         * split ChangeLog-9091 into ChangeLog-1990 and ChangeLog-1991        
>         * split ChangeLog-2000 out of ChangeLog.

I suggest this instead:

         * rename ChangeLog-9X to ChangeLog.9X
         * split ChangeLog-9091 into ChangeLog.90 and ChangeLog.91        
         * split ChangeLog.00 out of ChangeLog.
From eliz@is.elta.co.il Fri Jan 12 01:18:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: fnasser@redhat.com
Cc: jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Fri, 12 Jan 2001 01:18:00 -0000
Message-id: <7458-Fri12Jan2001111404+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>
X-SW-Source: 2001-01/msg00057.html
Content-length: 323

> Date: Thu, 11 Jan 2001 17:06:35 -0500
> From: Fernando Nasser <fnasser@redhat.com>
> 
> Are you doing the renaming?  Nobody seems to disagree

Please allow a bit more time for dissent to be posted.  Not everybody
lives on EST around here, and sometimes some of us do happen to be
off-line (e.g., to catch some sleep ;-).
From eliz@is.elta.co.il Fri Jan 12 02:30:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: jtc@redback.com
Cc: fnasser@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Fri, 12 Jan 2001 02:30:00 -0000
Message-id: <7263-Fri12Jan2001122813+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>
X-SW-Source: 2001-01/msg00058.html
Content-length: 1573

> Date: Fri, 12 Jan 2001 11:15:34 +0200
> From: "Eli Zaretskii" <eliz@is.elta.co.il>
> > 
> > So the current proposal is:
> > 
> >         * rename ChangeLog-9X to ChangeLog-199X
> >         * split ChangeLog-9091 into ChangeLog-1990 and ChangeLog-1991        
> >         * split ChangeLog-2000 out of ChangeLog.
> 
> I suggest this instead:
> 
>          * rename ChangeLog-9X to ChangeLog.9X
>          * split ChangeLog-9091 into ChangeLog.90 and ChangeLog.91        
>          * split ChangeLog.00 out of ChangeLog.

I can also suggest alternative schemes that you might want to
consider.  One possibility is to rename the files to ChangeLog.1,
ChangeLog.2, ChangeLog.3, etc., starting with the oldest one.  This is
what Emacs does in its distribution.

Emacs also splits ChangeLog files by versions, not by years.  Thus, a
new ChangeLog is started when a version X.YZ is released and work on
the next version begins.  (Since GDB uses branching, this would mean
to start a new ChangeLog when a certain version's branch is cut.)

I think splitting by version is better than by years, because it is
trivial to find out to what years does a certain ChangeLog file
belongs, by looking at its head and tail, whereas the opposite--find
out what version's ChangeLog entries are in which file--is not trivial
at all.

Btw, it is not necessary to have one ChangeLog per released version;
depending on the number of entries, several versions can live in the
same ChangeLog file.

If we do put each version on its own ChangeLog, we could have
ChangeLog.418, ChangeLog.500, etc.
From fnasser@redhat.com Fri Jan 12 05:15:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Fri, 12 Jan 2001 05:15:00 -0000
Message-id: <3A5F02FE.83E5B350@redhat.com>
References: <5md7dt7ski.fsf@jtc.redback.com> <3405-Fri12Jan2001111148+0200-eliz@is.elta.co.il>
X-SW-Source: 2001-01/msg00059.html
Content-length: 931

Eli Zaretskii wrote:
> 
> > From: jtc@redback.com (J.T. Conklin)
> > Date: 11 Jan 2001 12:16:29 -0800
> >
> > Now that gcc and binutils have rotated ChangeLogs, should we do the
> > same for gdb?  By existing convention, the new ChangeLog file would be
> > ChangeLog-00.
> >
> > Is there any reason not to use it?
> 
> Yes: these ChangeLog-NNNN names all clash after truncation to DOS 8+3
> limits.
> 

Lots of other things will clash as well.

Our established file size limit is 14, exactly what these names have.


> I believe it is a long-term goal to eliminate such problems.  So I'd
> suggest to start this now, and rename all ChangeLog-NNNN into
> ChangeLog.NNNN.

We can't keep adding limitations to GDB and other free software based on
obsolete 20 year old operating systems.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From ac131313@cygnus.com Fri Jan 12 07:00:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Fri, 12 Jan 2001 07:00:00 -0000
Message-id: <3A5F1BC5.906EE337@cygnus.com>
References: <5md7dt7ski.fsf@jtc.redback.com> <3405-Fri12Jan2001111148+0200-eliz@is.elta.co.il> <3A5F02FE.83E5B350@redhat.com>
X-SW-Source: 2001-01/msg00060.html
Content-length: 285

Fernando Nasser wrote:

> We can't keep adding limitations to GDB and other free software based on
> obsolete 20 year old operating systems.

We shouldn't be doing anything to hinder people with such operating
systems either.  Supporting GNU tools on DOS/cygwin is important.

	Andrew
From eliz@is.elta.co.il Fri Jan 12 07:49:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: fnasser@redhat.com
Cc: jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Fri, 12 Jan 2001 07:49:00 -0000
Message-id: <9791-Fri12Jan2001174626+0200-eliz@is.elta.co.il>
References: <5md7dt7ski.fsf@jtc.redback.com> <3405-Fri12Jan2001111148+0200-eliz@is.elta.co.il> <3A5F02FE.83E5B350@redhat.com>
X-SW-Source: 2001-01/msg00061.html
Content-length: 2439

> Date: Fri, 12 Jan 2001 08:13:34 -0500
> From: Fernando Nasser <fnasser@redhat.com>
> 
> Lots of other things will clash as well.

But why add to those clashes?  In the long run, we agreed to eliminate
most, if not all of these problems by using subdirectories more
aggressively.

> Our established file size limit is 14, exactly what these names have.

I don't have anything against long file names, even if they are longer
than 14 characters, as long as they don't clash after truncation to
8+3.

> > I believe it is a long-term goal to eliminate such problems.  So I'd
> > suggest to start this now, and rename all ChangeLog-NNNN into
> > ChangeLog.NNNN.
> 
> We can't keep adding limitations to GDB and other free software based on
> obsolete 20 year old operating systems.

Uhm.. Unix is even older than that, I believe ;-)

Anyway, I really don't understand the attitude.  The DJGPP port is
part of the official distribution and is fully supported by the GDB
project.  Amazingly enough, the DJGPP installed base doesn't seem to
be decreasing, judging by the traffic on comp.os.msdos.djgpp (it
amazes me as well).  Thousands of teenage programmers are exposed to
Free Software through using DJGPP.  The FSF is now releasing the 2nd
edition of the "GNU Software for MS-Windows and MS-DOS" CD-ROM, which
is based equally on DJGPP and Cygwin ports (the previous editions were
all sold out); that CD-ROM includes ports of all the latest GNU stuff,
including GCC 2.95.2, Emacs 20.7 and GDB 5.0.

As long as the DJGPP port of GDB is fully supported, each file which
clashes with other files means more work for me, to resolve those
clashes, because otherwise users will not be able to build GDB
reliably.  When you add such files, you are fighting against me and
against DJGPP users, not against Microsoft.

Now, I'm fully aware that DOS and Windows are not the most important
operating systems on GNU Project's agenda, so if there are valid
technical reasons to do something that makes the maintenance of the
DJGPP port a bit harder, I'll accept that.  If some technical
considerations dictate that we use ChangeLog-NNNN names, let's talk
about those considerations.

I suggested a few alternative solutions, which I think are better, on
their own merit (split by version, not by year), and at the same time
avoid file-name clashes.  Perhaps considering those suggestions would
help us solve the problem without arguing about file names.
From fche@redhat.com Fri Jan 12 08:38:00 2001
From: fche@redhat.com (Frank Ch. Eigler)
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: fnasser@redhat.com, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Fri, 12 Jan 2001 08:38:00 -0000
Message-id: <o5ely8g1zq.fsf@toenail.toronto.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>
X-SW-Source: 2001-01/msg00062.html
Content-length: 479

"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?

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!)


- FChE
From dj@redhat.com Fri Jan 12 10:01:00 2001
From: DJ Delorie <dj@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Fri, 12 Jan 2001 10:01:00 -0000
Message-id: <xnofxck5xc.fsf@greed.delorie.com>
References: <5md7dt7ski.fsf@jtc.redback.com> <3405-Fri12Jan2001111148+0200-eliz@is.elta.co.il>
X-SW-Source: 2001-01/msg00063.html
Content-length: 244

"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.  We might have to
handle this in djtar, like the info files.
From jtc@redback.com Fri Jan 12 10:48:00 2001
From: jtc@redback.com (J.T. Conklin)
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: fnasser@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Fri, 12 Jan 2001 10:48:00 -0000
Message-id: <5m3deo4nec.fsf@jtc.redback.com>
References: <5md7dt7ski.fsf@jtc.redback.com> <3A5E23C0.A8DF6E48@redhat.com> <5mn1cx6ajc.fsf@jtc.redback.com> <3A5E2E6B.AA61F361@redhat.com> <7458-Fri12Jan2001111404+0200-eliz@is.elta.co.il>
X-SW-Source: 2001-01/msg00064.html
Content-length: 724

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
>> Date: Thu, 11 Jan 2001 17:06:35 -0500
>> From: Fernando Nasser <fnasser@redhat.com>
>> 
>> Are you doing the renaming?  Nobody seems to disagree

Eli> Please allow a bit more time for dissent to be posted.  Not
Eli> everybody lives on EST around here, and sometimes some of us do
Eli> happen to be off-line (e.g., to catch some sleep ;-).

Sorry, I jumped the gun and the renaming has already occured.  That's
not to say that it must stay that way.  It's trivial to rename them 
once again if a new naming convention is prefered.

For the time being, I'm going to step aside and let things sort them-
selves out.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From shebs@apple.com Fri Jan 12 11:17:00 2001
From: Stan Shebs <shebs@apple.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: jtc@redback.com, fnasser@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Fri, 12 Jan 2001 11:17:00 -0000
Message-id: <3A5F5825.CF95E1D6@apple.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>
X-SW-Source: 2001-01/msg00065.html
Content-length: 554

Eli Zaretskii wrote:
> 
> I can also suggest alternative schemes that you might want to
> consider.  One possibility is to rename the files to ChangeLog.1,
> ChangeLog.2, ChangeLog.3, etc., starting with the oldest one.  This is
> what Emacs does in its distribution.

Now that I'm working on GCC, I find that this is more puzzling
than the GDB scheme; the names give no information beyond that the
file has been split.

> If we do put each version on its own ChangeLog, we could have
> ChangeLog.418, ChangeLog.500, etc.

I really like this idea.

Stan
From jtc@redback.com Fri Jan 12 11:33:00 2001
From: jtc@redback.com (J.T. Conklin)
To: Stan Shebs <shebs@apple.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, fnasser@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: changelog rotation...
Date: Fri, 12 Jan 2001 11:33:00 -0000
Message-id: <5m66jk36qu.fsf@jtc.redback.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>
X-SW-Source: 2001-01/msg00066.html
Content-length: 992

>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:

Stan> Eli Zaretskii wrote:
>> 
>> I can also suggest alternative schemes that you might want to
>> consider.  One possibility is to rename the files to ChangeLog.1,
>> ChangeLog.2, ChangeLog.3, etc., starting with the oldest one.  This is
>> what Emacs does in its distribution.

Stan> Now that I'm working on GCC, I find that this is more puzzling
Stan> than the GDB scheme; the names give no information beyond that the
Stan> file has been split.

>> 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.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From ftantonio@infovia.com.ar Fri Jan 12 12:22:00 2001
From: "antonio" <ftantonio@infovia.com.ar>
To: <gdb@sourceware.cygnus.com>
Subject: carnavaldelpais.com.ar
Date: Fri, 12 Jan 2001 12:22:00 -0000
Message-id: <02c101c07cd5$3bcc58e0$26d00dd1@o7q7r9>
X-SW-Source: 2001-01/msg00067.html
Content-length: 1020

gdb@sourceware.cygnus.com

Esa información la encontraras en la pagina www.carnavaldelpais.com.ar




 SU DIRECCION FUE OBTENIDA DE UN SITIO PUBLICO Y NUESTRA INTENCION ES INFORMARLE NUESTRA PROPUESTA, LE PEDIMOS DISCULPAS SI NO RESULTASE DE SU INTERES... 
/////////////////////////////////////////////////////////////////////////////// 
Este mensaje se envía con la complacencia de la nueva legislación sobre correo electrónico: Por sección 301, parrafo (a)(2)(C) de S.1618 Bajo el decreto S.1618 titulo 3ro. Aprobado por el 105 congreso base de las normativas internacionales sobre SPAM, este E-mail no podrá ser considerado SPAM mientras incluya una forma de ser removido. Para ser removido de la lista envíe a  envios_car@yahoo.com.ar este mensaje y en subjet, título o asunto escriba "REMOVE" que automáticamente será removido para futuros mensajes. El proceso es automático. No olvide poner "REMOVE" en el asunto. 
////////////////////////////////////////////////////////////////////////////////