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

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

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.

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

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

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.

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.

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

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

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