forums.ps2dev.org

t0mb0la · Joined: 20 Jan 2004 Posts: 24 Location: Seattle WA, USA

When I compile the code (debug.cpp) shown below with ee-gcc (3.2.2) using option '-O2' the following output is produced:

mharris · Joined: 25 Jan 2004 Posts: 155 Location: Annapolis, MD, USA

I've seen this before, and my conclusion was that UDP was getting bolloxed when the packets were coming in too fast. With UDP (as opposed to TCP), there's no guarantee of the order in which they're sent or received. It's just a theory, and doing tcpdump shows that the output from printf is indeed arriving out of sequence, but they're all very close together in time.

Interesting that the -O2 flag makes a difference -- maybe the less-optimized code has enough delays between the individual calls to npmPuts() to make a difference, and your client pulls them out in the right order.

I'm assuming you're using ps2link, not naplink... I'm guessing the naplink drivers use their own packet encapsulation rather than IP, but I've never run naplink so I can't be sure. One would think this problem wouldn't exist on naplink because of this.

If you try using naplink, or scr_printf() or similar, does the problem go away in -O2 code?

t0mb0la · Joined: 20 Jan 2004 Posts: 24 Location: Seattle WA, USA

I'm sure this isn't a UDP issue. I first came across it in a program which is using GSlib to display the text, the lines are messed up in exactly the same way, using strlen on textarray[0] or textarray[5] (in this example) will return what it 'sees' thus (I extended to printf("%s [%d]\n", textarray[i], strlen(textarray[i])); ) and the output is:

Guest

ooPo · Posted: Sun May 09, 2004 4:17 pm Post subject:

Hooray for munged data.

Notice how it skips 5 characters in line one? I wonder if that may be tied to your having 5 textarray lines? Or looping 5 times... *shrug*

Try printing out the lines before and after you do a strcpy. Try doing them in a different order. See if you can find out if its failing during the strcpy or during the printf. Maybe use a memcpy instead? Try to output it to the screen somehow if you can, avoiding the network code.

The code compiles and runs fine on my pc, so the code should work fine. :)

Guest

One more possibility, and this could very well likely be your problem

The newest versions of gcc have a weird optimization where it will
automagically convert printf() calls to puts() calls. This hung me
up on compiling oopo's new beta toolchain.

Compiling your code with the -S flag and viewing asm output
confirms that your printf() is being converted to puts().

Ok, in theory, things should still work. But you can turn off that
annoying attempt at optimization with: -fno-builtin-printf and see
if it goes away.

I can't take credit for knowing this, pixel helped me out last night
when I ran into this problem. :)

Gorim

mharris · Joined: 25 Jan 2004 Posts: 155 Location: Annapolis, MD, USA

t0mb0la: can you post the asm code that's generated for textfunction() w/ -O0 and -O2? That should the ultimate test... Pass is the -S option to gcc instead of -c, but you know that already...

I'd try myself, but I don't have the 3.2.2 gcc installed.

t0mb0la · Joined: 20 Jan 2004 Posts: 24 Location: Seattle WA, USA

Ok, here is the asm code generated without -O2 option for the textfill and textfunction:

Guest · Posted: Mon May 10, 2004 6:05 am Post subject:

Are you compiling as C++ ? The ASM function names looked
like they have been mangled. can you try compiling as C ?

furthermore, the section where it inline copies the first two
strings is definitely hosed as bad code.

I compiled your code earlier today to look at asm output, and
it looked alot cleaner. I compiled it from my mac, having just
installed the new toolchain last night:

pixel · Joined: 30 Jan 2004 Posts: 791

Try recompiling your sources with the options -O2 -fno-builtin to disable *all* the builtins (including strcpy), to see if it's the fault of the builtin strcpy here.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

Guest · Posted: Mon May 10, 2004 6:25 am Post subject:

I didn't compile with -fno-builtins and the asm is much nicer :)

Anyhow, the section of his asm code that is really munged is
this:

t0mb0la · Joined: 20 Jan 2004 Posts: 24 Location: Seattle WA, USA

Ok, compiling with -O2 -fno-builtin removes the problem. Does this mean my builtin strcpy is broken?

mrbrown · Joined: 17 Jan 2004 Posts: 1536

Actually, MrHTFord outlined this issue in GCC 3.2.2 (MIPS backend) a few months ago either here or on IRC. There's a bug when GCC picks alignment for block moves, I think it was where it would pick 128-bit alignment for data that was only 64-bit aligned. Lemme see if I can find it...

Hmm, I can't find it here, so we must've talked about it on IRC. Try tracking MrHTFord down, as he knows more details than me.

Guest · Posted: Mon May 10, 2004 11:16 am Post subject:

Ok, so why does my brand-spanking newly installled toolchain
not have this problem ? (installed from oopo's beta toolchain
installer...and i have no other tools installed on this host so
can't be any side-effects from accidental environmental
references to pre-existing stuff).

Its pretty bad if the compiler can't be consistent about when
it exhibits this bad output.

FYI, I compiled with -O2 (you can tell from the inlined strcpy
in my output) and did not do -fno-builtins.

Gorim

ooPo · Posted: Mon May 10, 2004 2:01 pm Post subject:

Its possible he's using an earlier 3.2.2 patch, I've added stuff from mrhtford to the beta set... maybe it was fixed already?

At the very least, is there a way to override block move alignment and force it to 64-bit?

pixel · Joined: 30 Jan 2004 Posts: 791

I finally found the patch back, and put it here:

http://www.nobis-crew.org/gcc-3.2.2-IOP-20040222.diff.gz

Now I'm going to do some tests with it.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.