I don’t know what Tom was thinking when he gave me an account. I just bitch and whine here when #seneca is empty.
Distcc seems to be coming pretty slowly now that we have to write our own tests. I’ve actually come across a few problems with the gdb, gnu’s debugger, when tring to debug a program.
One problem is multi-line statements. Although it may not seem obvious until you think about it, a long statement that spans multiple line is still treated as a single statement. For example, here is a small snippet of code :
if (!strcmp(foo, "Hello") ||
!strcmp(bar, “World”))
</em>
Now, if for whatever reason bar was a NULLL pointer, gdb should crash when evalutating the second string compare. But it will report you the first line of the if-statement rather than the offending line. This is not gdb fault, because that’s the way C is. But due to lack of experience and knowledge, this can cause hours of frustration as a statement that you know <em>should</em> work, doesn’t.
Another problem I have been having is gdb ’skipping’ lines of source code. I cannot, for the life of me, logically come to a conclusion on why this is happening, other than a bug or optimization. I tried making the variables volatile, but that didn’t help. Here is a large snippet of code with line numbers :
255 int dcc_cl_is_source(const char *sfile)
256 {
257 const char *dot, *ext;
258 int rv = 0;
259
260 dot = dcc_find_extension((char *) sfile);
261 if (!dot)
262 return 0;
263 ext = dot+1;
264
265 if (!strcmp(ext, “c”) ||
266 !strcmp(ext, “cc”) ||
I think I was the one who wrote this function, which may be one of the causes for concern. But for the purpose of this writing, here is what you need to know :
- I put a break on line 258 and 261. And run gdb with the following parameters “cl foo.asm”
- sfile is a pointer to the null terminated string “.asm”, the extension of the foo assembly file
- The file does not need to exist. This function returns whether the extension is a source file
- dcc_find_extension returns the extension. Which is “.asm” again. This function does not do anything in this particular case
So I run the gdb and stop at line 258 as expected.
Breakpoint 1, dcc_cl_is_source (sfile=0×22cced “.asm”) at src/filename.c:258
258 int rv = 0;
I continue to line 261 because dcc_find_extension does nothing interesting for me.
(gdb) step
260 dot = dcc_find_extension((char *) sfile);
(gdb) cont
Continuing.
And stop at my second breakpoint
Breakpoint 2, dcc_cl_is_source (sfile=0×22cced “.asm”) at src/filename.c:261
261 if (!dot)
When I stop at the if-statement, dot is set properly, and will not go into the if statement. I did not check it because I’m sure of it. And don’t you dare say “you should of checked the value of dot..”. I do a step, just to prove you wrong anyways 
(gdb) step
265 if (!strcmp(ext, “c”) ||
Wait a minute wtf? Haven’t you skipped a statement mista gdb?
(gdb) step
263 ext = dot+1;
o..k..
(gdb) step
265 if (!strcmp(ext, “c”) ||
Strange. I think it may be an optimization thing (for me to go insane faster). I didn’t try it with -O0 yet.
On another note, I have to whine about ENABLE_REMOTE_ASSEMBLE. This is a macro that, if defined, enables you to send assembly files to be distributed. Here is my concern with this :
- There doesn’t seem to be a way in ./configure to enable this.
- It is disabled by default.
- If it was enabled, I think some of the tests from the original Distcc may fail. This is because the current tests don’t treat .s and .S (assembly files) as source. But it seems like source to me, and I followed Martin’s guide closely. I think one of my tests may be incorrect because assembly is source code. Sorry Tom, it will be fixed on the second commit.
Lastly (for this post anyways, I can whine for HOURS) I want to talk about bash. I worked on a bash script for the Emery Wireless project. I need to read, line by line, from a file. Here a test script I made that, by the looks of it, should work fine :
#!/bin/sh
F=0
head -2 /etc/passwd | while read line
do
let “F++”
echo $F
done
echo $F
This script should read the first two lines from /etc/password, increment F each time, and print out the value of F. Here are my results.
1
2
0
Ideas? I’m probably going to talk to John about it, but I thought it was an interesting problem.
