From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Noah Aklilu Cc: gdb@sourceware.cygnus.com Subject: Re: Using GDB with M32R MSA2000 Board Date: Thu, 11 Jan 2001 07:26:00 -0000 Message-id: <3A5DD05F.D5C5F105@redhat.com> References: <3A5CD21F.11803.31B91E@localhost> X-SW-Source: 2001-01/msg00045.html 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 > > ... > > (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 To: Fernando Nasser 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 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 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 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 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 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 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 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 To: jtc@redback.com Cc: Fernando Nasser , 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 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 ----- From: "Zack Weinberg" 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 To: Arnaud Charlet Cc: Fernando Nasser , Richard Shih-Ping Chan , GDB , Kevin Buettner 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" 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" 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" 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 > > 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" 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" > > > > 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 To: Eli Zaretskii 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 To: Fernando Nasser Cc: Eli Zaretskii , 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" 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 > > 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 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: 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" 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 To: gdb@sourceware.cygnus.com Subject: Re: changelog rotation... Date: Fri, 12 Jan 2001 10:01:00 -0000 Message-id: 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" 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 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 writes: >> Date: Thu, 11 Jan 2001 17:06:35 -0500 >> From: Fernando Nasser >> >> 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 To: Eli Zaretskii 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 Cc: Eli Zaretskii , 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 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" To: 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. ////////////////////////////////////////////////////////////////////////////////