• Henry Thomas (16/16) Dec 11 2002 I am having a problem linking a large project with codeview support. opt...
• Henry Thomas (9/11) Dec 11 2002 Never mind,
• Walter (10/21) Dec 11 2002 -g ensures that there's an EBP stack frame for each function. Sounds lik...
• Henry Thomas (51/53) Dec 11 2002 The code works fine when compiled by dmc without optomizations turned on...
• Henry Thomas (51/53) Dec 11 2002 The code compiles fine under dmc with optomizations turned off.
• Walter (12/65) Dec 11 2002 I would suggest just compiling it with just -gl, and then link the .obj
• Henry Thomas (30/30) Dec 16 2002 I have some great news :)
• Walter (10/40) Dec 16 2002 Great!

Henry Thomas <Henry_member pathlink.com> writes:

I am having a problem linking a large project with codeview support. optlink
reports the following Error 168: >64K Global Types. I have found no reference to
this error on your site. Any ideas?

link /CO:4 /NOI /DE /XN /NT /A:512 /ENTRY:_DllMainCRTStartup /IMPL:jedda.lib
crypt_digest.obj

SNIP lots of obj files /SNIP

util_unicode.obj  util_utf.obj, jedda.dll, , kernel32.lib 
ws2_32.lib , jedda.def, 
OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved
transact_schema.obj(transact_schema) 
Error 168: >64K Global Types 
NMAKE : fatal error U1077: 'C:\dm\bin\link.exe' : return code '0x1'
Stop.

Thanks in advance.

-h

Henry Thomas <Henry_member pathlink.com> writes:

In article <at7t2l$5ef$1 digitaldaemon.com>, Henry Thomas says...
I am having a problem linking a large project with codeview support. optlink
reports the following Error 168: >64K Global Types. I have found no reference
>to this error on your site. Any ideas?

Never mind,

adding -g4 to the build and /CO:4 /L /I to the link fixed it.

But I have another problem -- well the original problem I was trying to debug. I
have an error that only occurs when I enable optimization -o+time (in fact any
-o+xxxx variant seems to cause it). But as soon as I add -g to the build the
error goes away. What optimizations are turned off by -g? And if they are turned
off how do I debug them?

-h

"Walter" <walter digitalmars.com> writes:

-g ensures that there's an EBP stack frame for each function. Sounds like
you have a pointer bug.

"Henry Thomas" <Henry_member pathlink.com> wrote in message
news:at7vid$89b$1 digitaldaemon.com...
 In article <at7t2l$5ef$1 digitaldaemon.com>, Henry Thomas says...
I am having a problem linking a large project with codeview support.


optlink
reports the following Error 168: >64K Global Types. I have found no


reference >to this error on your site. Any ideas?
 Never mind,

 adding -g4 to the build and /CO:4 /L /I to the link fixed it.

 But I have another problem -- well the original problem I was trying to

debug. I
 have an error that only occurs when I enable optimization -o+time (in fact

any
 -o+xxxx variant seems to cause it). But as soon as I add -g to the build

the
 error goes away. What optimizations are turned off by -g? And if they are

turned
 off how do I debug them?

 -h

Henry Thomas <Henry_member pathlink.com> writes:

In article <at81kt$ar0$1 digitaldaemon.com>, Walter says...
-g ensures that there's an EBP stack frame for each function. Sounds like
you have a pointer bug.

The code works fine when compiled by dmc without optomizations turned on.

However I would like to get the optomizations to work because my database
compiler built under dmc is twice as slow as both bcc and vc. 

[52 Seconds] Digital Mars 8.29n

BUILD OPTIONS: -mn -WA -o+all -g -6 -a8

C:\Projects\jedda\build\bcc> jdc rebuild -t system
Jedda Database Compiler 2.0.3
Copyright 1996-2002 Jedda Inc., a California Corporation.
All rights reserved. Use is subject to license terms.
Licensed under the Open Software License version 1.0
Compiler: rebuilding "C:\projects\jedda_db\system.jedda"
Compiler: done 'system' - 173616 lines, 0 warnings, 0 errors
Uptime: 0 minutes, 52 seconds
Exited normally

[25 Seconds] Borland C++Builder 5.5

BUILD OPTIONS: -6 -d -O2 -Oc -Oi -OS -Ov

C:\Projects\jedda\build\bcc> jdc rebuild -t system
Jedda Database Compiler 2.0.3
Copyright 1996-2002 Jedda Inc., a California Corporation.
All rights reserved. Use is subject to license terms.
Licensed under the Open Software License version 1.0
Compiler: rebuilding "C:\projects\jedda_db\system.jedda"
Compiler: done 'system' - 173616 lines, 0 warnings, 0 errors
Uptime: 0 minutes, 25 seconds
Exited normally

[23 Seconds] Microsoft VC++ 6

BUILD OPTIONS: /G6 /ML /W4 /Ot /Oa /Ow /Oi /Oy /Ob2 /Gf /YX

C:\Projects\jedda\build\vc> jdc rebuild -t system
Jedda Database Compiler 2.0.3
Copyright 1996-2002 Jedda Inc., a California Corporation.
All rights reserved. Use is subject to license terms.
Licensed under the Open Software License version 1.0
Compiler: rebuilding "C:\projects\jedda_db\system.jedda"
Compiler: done 'system' - 173616 lines, 0 warnings, 0 errors
Uptime: 0 minutes, 23 seconds
Exited normally

Mind you, dmc was build with the -g switch. When I compile without -g I get a
invalid file descriptor error in the following fragment.

if(IsBufferReader(this)) {
this->tail = this->head = this->ceiling = this->floor + this->capacity;
if((this->fd = open(path->array, O_RDONLY | O_BINARY)) == -1) {
this->head = this->tail = this->ceiling = this->floor;
Throw( LogErrorMessage(IO_ERRNO, "while opening \"%t\" for reading", path) );
}
Try( BufferReader(this, this->tail - this->floor) );
}
else...

It would appear that this->fd is not being set before the call to BufferReader.
Any ideas?

-h

Henry Thomas <Henry_member pathlink.com> writes:

In article <at81kt$ar0$1 digitaldaemon.com>, Walter says...
-g ensures that there's an EBP stack frame for each function. Sounds like
you have a pointer bug.

The code compiles fine under dmc with optomizations turned off.

So this is not what I expected. My database compiler built under dmc is twice as
slow as both bcc and vc. 

[52 Seconds] Digital Mars 8.29n

BUILD OPTIONS: -mn -WA -o+all -g -6 -a8

C:\Projects\jedda\build\bcc> jdc rebuild -t system
Jedda Database Compiler 2.0.3
Copyright 1996-2002 Jedda Inc., a California Corporation.
All rights reserved. Use is subject to license terms.
Licensed under the Open Software License version 1.0
Compiler: rebuilding "C:\projects\jedda_db\system.jedda"
Compiler: done 'system' - 173616 lines, 0 warnings, 0 errors
Uptime: 0 minutes, 52 seconds
Exited normally

[25 Seconds] Borland C++Builder 5.5

BUILD OPTIONS: -6 -d -O2 -Oc -Oi -OS -Ov

C:\Projects\jedda\build\bcc> jdc rebuild -t system
Jedda Database Compiler 2.0.3
Copyright 1996-2002 Jedda Inc., a California Corporation.
All rights reserved. Use is subject to license terms.
Licensed under the Open Software License version 1.0
Compiler: rebuilding "C:\projects\jedda_db\system.jedda"
Compiler: done 'system' - 173616 lines, 0 warnings, 0 errors
Uptime: 0 minutes, 25 seconds
Exited normally

[23 Seconds] Microsoft VC++ 6

BUILD OPTIONS: /G6 /ML /W4 /Ot /Oa /Ow /Oi /Oy /Ob2 /Gf /YX

C:\Projects\jedda\build\vc> jdc rebuild -t system
Jedda Database Compiler 2.0.3
Copyright 1996-2002 Jedda Inc., a California Corporation.
All rights reserved. Use is subject to license terms.
Licensed under the Open Software License version 1.0
Compiler: rebuilding "C:\projects\jedda_db\system.jedda"
Compiler: done 'system' - 173616 lines, 0 warnings, 0 errors
Uptime: 0 minutes, 23 seconds
Exited normally

Mind you, dmc was build with the -g switch. When I compile without -g I get a
invalid file descriptor error in the following fragment.

if(IsBufferReader(this)) {
this->tail = this->head = this->ceiling = this->floor + this->capacity;
if((this->fd = open(path->array, O_RDONLY | O_BINARY)) == -1) {
this->head = this->tail = this->ceiling = this->floor;
Throw( LogErrorMessage(IO_ERRNO, "while opening \"%t\" for reading", path) );
}
Try( BufferReader(this, this->tail - this->floor) );
}
else...

it would appead that this->fd is not being set before the call to BufferReader.
Any ideas?

-h

"Walter" <walter digitalmars.com> writes:

I would suggest just compiling it with just -gl, and then link the .obj
files with -g. That will prevent changing the code generation.

As for it "working fine" without optimization, that kind of result is common
with pointer bugs. Any changes at all and they can appear to go away. Then,
they come back at the most annoying moment, such as the demo in front of
10,000 <g>.

"Henry Thomas" <Henry_member pathlink.com> wrote in message
news:at84li$e7b$1 digitaldaemon.com...
 In article <at81kt$ar0$1 digitaldaemon.com>, Walter says...
-g ensures that there's an EBP stack frame for each function. Sounds like
you have a pointer bug.

 The code compiles fine under dmc with optomizations turned off.

 So this is not what I expected. My database compiler built under dmc is

twice as
 slow as both bcc and vc.

 [52 Seconds] Digital Mars 8.29n

 BUILD OPTIONS: -mn -WA -o+all -g -6 -a8

 C:\Projects\jedda\build\bcc> jdc rebuild -t system
 Jedda Database Compiler 2.0.3
 Copyright 1996-2002 Jedda Inc., a California Corporation.
 All rights reserved. Use is subject to license terms.
 Licensed under the Open Software License version 1.0
 Compiler: rebuilding "C:\projects\jedda_db\system.jedda"
 Compiler: done 'system' - 173616 lines, 0 warnings, 0 errors
 Uptime: 0 minutes, 52 seconds
 Exited normally

 [25 Seconds] Borland C++Builder 5.5

 BUILD OPTIONS: -6 -d -O2 -Oc -Oi -OS -Ov

 C:\Projects\jedda\build\bcc> jdc rebuild -t system
 Jedda Database Compiler 2.0.3
 Copyright 1996-2002 Jedda Inc., a California Corporation.
 All rights reserved. Use is subject to license terms.
 Licensed under the Open Software License version 1.0
 Compiler: rebuilding "C:\projects\jedda_db\system.jedda"
 Compiler: done 'system' - 173616 lines, 0 warnings, 0 errors
 Uptime: 0 minutes, 25 seconds
 Exited normally

 [23 Seconds] Microsoft VC++ 6

 BUILD OPTIONS: /G6 /ML /W4 /Ot /Oa /Ow /Oi /Oy /Ob2 /Gf /YX

 C:\Projects\jedda\build\vc> jdc rebuild -t system
 Jedda Database Compiler 2.0.3
 Copyright 1996-2002 Jedda Inc., a California Corporation.
 All rights reserved. Use is subject to license terms.
 Licensed under the Open Software License version 1.0
 Compiler: rebuilding "C:\projects\jedda_db\system.jedda"
 Compiler: done 'system' - 173616 lines, 0 warnings, 0 errors
 Uptime: 0 minutes, 23 seconds
 Exited normally

 Mind you, dmc was build with the -g switch. When I compile without -g I

get a
 invalid file descriptor error in the following fragment.

 if(IsBufferReader(this)) {
 this->tail = this->head = this->ceiling = this->floor + this->capacity;
 if((this->fd = open(path->array, O_RDONLY | O_BINARY)) == -1) {
 this->head = this->tail = this->ceiling = this->floor;
 Throw( LogErrorMessage(IO_ERRNO, "while opening \"%t\" for reading",

path) );
 }
 Try( BufferReader(this, this->tail - this->floor) );
 }
 else...

 it would appead that this->fd is not being set before the call to

BufferReader.
 Any ideas?

 -h

Henry Thomas <Henry_member pathlink.com> writes:

I have some great news :)

I found the problem - I have my own cooperative garbage collector that uses
setjmp as an operating system and architecture independent way to pushes all
registers onto the stack so I can inventory pointer references. Anyway I was
using ...

memset(&regs, 0, sizeof regs);
setjmp(regs);

to do this. However I hadn't noticed that this was reporting a warning at
compile time. With -g on everything worked fine (it must disable the removal of
unreferenced variables) so I couldn't find any bugs. With -g off I was getting a
Bad file descriptor which I later found out was because the read buffer had been
prematurely garbage collected. So I changed my setjmp call to...

memset(&regs, 0, sizeof regs);
if(setjmp(regs) != 0) {
Throw( LogError(SYSTEM_ERROR) );
}

and now it works.

But the best news is the performance!

C:\Projects\jedda\build\vc> jdc rebuild -t system
Jedda Database Compiler 2.0.3
Copyright 1996-2002 Jedda Inc., a California Corporation.
All rights reserved. Use is subject to license terms.
Licensed under the Open Software License version 1.0
Compiler: rebuilding "C:\projects\jedda_db\system.jedda"
Compiler: done 'system' - 173616 lines, 0 warnings, 0 errors
Uptime: 0 minutes, 11 seconds
Exited normally

The DMC compiled code that is twice as fast as both BCC and VC. An average 11
second runtime compared with 25 and 23 seconds. DMC rocks!

-h

"Walter" <walter digitalmars.com> writes:

Great!

"Henry Thomas" <Henry_member pathlink.com> wrote in message
news:atl2gb$1u73$1 digitaldaemon.com...
 I have some great news :)

 I found the problem - I have my own cooperative garbage collector that

uses
 setjmp as an operating system and architecture independent way to pushes

all
 registers onto the stack so I can inventory pointer references. Anyway I

was
 using ...

 memset(&regs, 0, sizeof regs);
 setjmp(regs);

 to do this. However I hadn't noticed that this was reporting a warning at
 compile time. With -g on everything worked fine (it must disable the

removal of
 unreferenced variables) so I couldn't find any bugs. With -g off I was

getting a
 Bad file descriptor which I later found out was because the read buffer

had been
 prematurely garbage collected. So I changed my setjmp call to...

 memset(&regs, 0, sizeof regs);
 if(setjmp(regs) != 0) {
 Throw( LogError(SYSTEM_ERROR) );
 }

 and now it works.

 But the best news is the performance!

 C:\Projects\jedda\build\vc> jdc rebuild -t system
 Jedda Database Compiler 2.0.3
 Copyright 1996-2002 Jedda Inc., a California Corporation.
 All rights reserved. Use is subject to license terms.
 Licensed under the Open Software License version 1.0
 Compiler: rebuilding "C:\projects\jedda_db\system.jedda"
 Compiler: done 'system' - 173616 lines, 0 warnings, 0 errors
 Uptime: 0 minutes, 11 seconds
 Exited normally

 The DMC compiled code that is twice as fast as both BCC and VC. An average

11
 second runtime compared with 25 and 23 seconds. DMC rocks!

 -h