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

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

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

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

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

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

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

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