January 28, 2007 Re: DMD 1.004 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lionello Lunesu | Lionello Lunesu a écrit : > "Walter Bright" <newshound@digitalmars.com> wrote in message news:epgokh$2q2p$1@digitaldaemon.com... >> Jordan Miner wrote: >>> Here is a problem I've found in post-1.00 versions. >> What's happening is you're writing into the string literal, which is not allowed. String literals should be regarded as readonly. >> >> Post-1.00 versions combine identical string literals, which is why you see the error. > > Shouldn't string literals be forced "const"? Even D's limited const could do that. Agreed! There's really not reason to create such blatant trap in D.. renoX > To create a mutable copy you'd be forced to used .dup. > > const char[] either = "asdfsadf"; > char[] or = "asdfsd".dup; > > L. > > |
January 28, 2007 Re: DMD 1.004 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright Attachments: | Walter Bright schrieb am 2007-01-28: [...] > But the worst thing about linux development is gdb. gdb's user interface seems stuck in 1983 era thinking. Have you tried "insight" or "ddd"? > I can't even get the thing to display the register contents. print $ebp print $eax > It won't pick up the program arguments from the command line. run what ever argument > Either I'm stupid, all this is missing from the documentation, or gdb really is terrible. "info gdb" should provide you with lots of documentation. Thomas |
January 28, 2007 Re: DMD 1.004 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Thomas Kuehne | Thomas Kuehne wrote: > Walter Bright schrieb am 2007-01-28: > [...] >> But the worst thing about linux development is gdb. gdb's user interface seems stuck in 1983 era thinking. > > Have you tried "insight" or "ddd"? No, I've never heard of them. Insight isn't on my machine. ddd is, and looks interesting. I'll try it. >> I can't even get the thing to display the register contents. > > print $ebp > print $eax There are a bunch of registers, I have to list them one at a time. It's pretty miserable if you're single stepping trying to keep an eye on the register contents. Every other debugger I've ever used, going back to the 70's, could either dump all regs with a shorter command, or had a window where the reg values were continuously updated. >> It won't pick up the program arguments from the command line. > > run what ever argument Where this falls down is when you've a long list of arguments to the program. I'll write a simple .bat file like: windbg program arg arg arg ... to run the debugger with the args. Doesn't work with gdb, because gdb doesn't pick up debuggee args from the command line, making gdb very tedious to use. > >> Either I'm stupid, all this is missing from the documentation, or gdb >> really is terrible. > > "info gdb" should provide you with lots of documentation. I didn't know that. You'd think: gdb --help would have provided this information. Thanks for the pointers. |
January 28, 2007 Re: DMD 1.004 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | >>> I can't even get the thing to display the register contents. >> >> print $ebp >> print $eax > > There are a bunch of registers, I have to list them one at a time. It's pretty miserable if you're single stepping trying to keep an eye on the register contents. Every other debugger I've ever used, going back to the 70's, could either dump all regs with a shorter command, or had a window where the reg values were continuously updated. (gdb) break main Breakpoint 1 at 0x804b389 (gdb) run Starting program: /home/braddr/sandbox/d/bugs/abstract_15 Failed to read a valid object file image from memory. Breakpoint 1, 0x0804b389 in main () (gdb) info registers eax 0xbff57484 -1074432892 ecx 0xb7dd1e6d -1210245523 edx 0x1 1 ebx 0xb7ee9ff4 -1209098252 esp 0xbff573e8 0xbff573e8 ebp 0xbff57408 0xbff57408 esi 0x0 0 edi 0xb7f4fcc0 -1208681280 eip 0x804b389 0x804b389 <main+9> eflags 0x282 [ SF IF ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) help info <snip a long list of helpful program status info options> (gdb) help set args Set argument list to give program being debugged when it is started. Follow this command with any number of args, to be passed to the program. >>> It won't pick up the program arguments from the command line. >> >> run what ever argument > > Where this falls down is when you've a long list of arguments to the program. I'll write a simple .bat file like: > windbg program arg arg arg ... > to run the debugger with the args. Doesn't work with gdb, because gdb doesn't pick up debuggee args from the command line, making gdb very tedious to use. Also: $ gdb --args programtodebug arg1 arg2 arg3 >>> Either I'm stupid, all this is missing from the documentation, or gdb >>> really is terrible. >> >> "info gdb" should provide you with lots of documentation. > > I didn't know that. You'd think: > gdb --help > would have provided this information. Thanks for the pointers. The built-in help to gdb isn't bad either.. though sometimes hard to find stuff in. Later, Brad |
January 28, 2007 Re: DMD 1.004 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright Attachments: | Walter Bright schrieb am 2007-01-28: > Thomas Kuehne wrote: >> Walter Bright schrieb am 2007-01-28: >> [...] >>> But the worst thing about linux development is gdb. gdb's user interface seems stuck in 1983 era thinking. >> >> Have you tried "insight" or "ddd"? > > No, I've never heard of them. Insight isn't on my machine. ddd is, and looks interesting. I'll try it. > >>> I can't even get the thing to display the register contents. >> >> print $ebp >> print $eax > > There are a bunch of registers, I have to list them one at a time. It's pretty miserable if you're single stepping trying to keep an eye on the register contents. Every other debugger I've ever used, going back to the 70's, could either dump all regs with a shorter command, or had a window where the reg values were continuously updated. info registers info float info vector >>> It won't pick up the program arguments from the command line. >> >> run what ever argument > > Where this falls down is when you've a long list of arguments to the > program. I'll write a simple .bat file like: > windbg program arg arg arg ... > to run the debugger with the args. Doesn't work with gdb, because gdb > doesn't pick up debuggee args from the command line, making gdb very > tedious to use. run `cat file_containing_all_your_arguments` or start GDB with gdb --args your_binary some argument Thomas |
January 28, 2007 Re: DMD 1.004 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Roberts | Brad Roberts wrote: >>>> I can't even get the thing to display the register contents. >>> >>> print $ebp >>> print $eax >> >> There are a bunch of registers, I have to list them one at a time. It's pretty miserable if you're single stepping trying to keep an eye on the register contents. Every other debugger I've ever used, going back to the 70's, could either dump all regs with a shorter command, or had a window where the reg values were continuously updated. > > (gdb) break main > Breakpoint 1 at 0x804b389 > (gdb) run > Starting program: /home/braddr/sandbox/d/bugs/abstract_15 > Failed to read a valid object file image from memory. > > Breakpoint 1, 0x0804b389 in main () > (gdb) info registers > eax 0xbff57484 -1074432892 > ecx 0xb7dd1e6d -1210245523 > edx 0x1 1 > ebx 0xb7ee9ff4 -1209098252 > esp 0xbff573e8 0xbff573e8 > ebp 0xbff57408 0xbff57408 > esi 0x0 0 > edi 0xb7f4fcc0 -1208681280 > eip 0x804b389 0x804b389 <main+9> > eflags 0x282 [ SF IF ] > cs 0x73 115 > ss 0x7b 123 > ds 0x7b 123 > es 0x7b 123 > fs 0x0 0 > gs 0x33 51 > > (gdb) help info > <snip a long list of helpful program status info options> > > (gdb) help set args > Set argument list to give program being debugged when it is started. > Follow this command with any number of args, to be passed to the program. > >>>> It won't pick up the program arguments from the command line. >>> >>> run what ever argument >> >> Where this falls down is when you've a long list of arguments to the program. I'll write a simple .bat file like: >> windbg program arg arg arg ... >> to run the debugger with the args. Doesn't work with gdb, because gdb doesn't pick up debuggee args from the command line, making gdb very tedious to use. > > Also: > $ gdb --args programtodebug arg1 arg2 arg3 That's good to know. > >>>> Either I'm stupid, all this is missing from the documentation, or gdb >>>> really is terrible. >>> >>> "info gdb" should provide you with lots of documentation. >> >> I didn't know that. You'd think: >> gdb --help >> would have provided this information. Thanks for the pointers. > > The built-in help to gdb isn't bad either.. though sometimes hard to find stuff in. I missed the 'info registers' command because gdb doesn't list 'info' when you type 'help' on its command prompt. Thanks for the tip. |
January 28, 2007 Re: DMD 1.004 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | GDB is simply unintuitive and problematic to use. Of course it has thousand commands able to display anything - but entering them is just a way to waste the time. For example hp-ux gdb equivalent has a lot better text mode interface - similar to the "windowed" debuggers. |
January 28, 2007 Re: DMD 1.004 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote:
> Bob W wrote:
>>>> Sounds like you work under Windows... :o)
>> ..........
>>> Yep, looks like he does (mostly) :).
>>
>> He is a smart guy who probably does not feel like
>> beta testing operating systems. Or maybe he just
>> ran out of coffee too often while waiting for penguin's
>> favorite compiler and linker to finish their jobs .... ;-)
>
> g++ is a slow compiler, and ld is a really slow linker, and I'm just more used to windows quirks than linux quirks.
>
> But the worst thing about linux development is gdb. gdb's user interface seems stuck in 1983 era thinking. I can't even get the thing to display the register contents. It won't pick up the program arguments from the command line. Either I'm stupid, all this is missing from the documentation, or gdb really is terrible.
>
> I do all my debugging on windows. Even horrible old windbg is a decade ahead of gdb.
>
> I do like gcov, though.
(I agree its an ugly interface.)
One thing I like though is the command history -- like most programs in Linux, you have 'readline', which means if you use 'control-R' you can search all previous commands for some string, for example.
Other things were answered already, heres some assorted stuff...
You can do a "display" to print some value after every command:
display $eax
display s.c_str()
I recommend this, it makes structures readable:
set print pretty on
Also, "gdb -x filename", tells it to run some file as a startup script. This is a good place to put long command lines and special stuff like this (these are just some examples; the stuff after -- is my comment, I don't know if gdb accepts a comment marker of any kind.
rbreak SomeClass:: -- break on all members of a class, takes a regex
rbreak __cxa -- this stops at all the exception handling in C++
break main
set print pretty on -- readable classes - dont know why its not default
open (command)
run (arguments)
Kevin
|
January 28, 2007 Re: DMD 1.004 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote: > Fixes mixin gc bug. > > http://www.digitalmars.com/d/changelog.html > > http://ftp.digitalmars.com/dmd.1.004.zip shootout.binarytrees (http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=dig italmars.D&artnum=43991) with gc is still very slow (only marginal improvement since 0.173): DMD 0.173 - full GC : 19.720 sec DMD 1.004 - full GC : 17.971 sec It seems like only generational GC (or maybe some other novel GC technology) could help in this case. -- I would love to change the world, but they won't give me the source code... |
January 28, 2007 Re: DMD 1.004 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lionello Lunesu | "Lionello Lunesu" <lionello@lunesu.remove.com> wrote in message news:ephjmf$12sd$1@digitaldaemon.com... > > > Shouldn't string literals be forced "const"? Even D's limited const could do that. To create a mutable copy you'd be forced to used .dup. > > const char[] either = "asdfsadf"; > char[] or = "asdfsd".dup; > That wouldn't help, because even if you pass a const char[] into a function that takes a char[], that function can still modify it. The const goes away. |
Copyright © 1999-2021 by the D Language Foundation