http://d.puremagic.com/issues/show_bug.cgi?id=1675

           Summary: "Identifier too long" error with OMF object files
           Product: D
           Version: 1.00
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: jarrett.billingsley@gmail.com


If there were an "OPTLINK" component, I would have filed this under it.

When dealing with complex template tuples, it's very easy to overflow the maximum symbol length allowed by OPTLINK.  This is, simply put, a damn shame, because it prevents otherwise completely legal code from compiling and linking with DMDWin, whereas it works perfectly fine when using DMDNix or GDC.

I know that this is neither a simple nor a small issue to fix: either the ancient, nearly-immutable OPTLINK would have to be modified, or DMDWin would have to be changed to output a more reasonable format, in which case a new linker would probably have to be written.  Until then, this issue should stand as a reminder that DMDWin is inherently limited.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1675





------- Comment #1 from shro8822@vandals.uidaho.edu  2007-11-15 22:31 -------
Oplink isn't the issue. The OMF file format has a hard limit. This results in the only solutions being: convert DMD to use some other .obj format or have DMD do something else for name mangling.

In talking to Walter, the issue is that it's easy to get symbols that have more info in them than can be fit into the limit. (the limit has already stretched by gziping the symbols.)

The "simple solution" I have proposed is to just MD5 (or what not) the symbols. The only issue (besides a vanishingly small chance of a hash collision) is that this looses information so you can't look at a symbol and directly determine what it was. My answer to that is, who cares? The only place where hashing provides less info than compressing is in a debugger and it can grab the full symbol from a table in the static data segment.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1675





------- Comment #2 from jarrett.billingsley@gmail.com  2007-11-15 23:52 -------
(In reply to comment #1)
> Oplink isn't the issue. The OMF file format has a hard limit. This results in the only solutions being: convert DMD to use some other .obj format or have DMD do something else for name mangling.
> 
> In talking to Walter, the issue is that it's easy to get symbols that have more info in them than can be fit into the limit. (the limit has already stretched by gziping the symbols.)
> 
> The "simple solution" I have proposed is to just MD5 (or what not) the symbols. The only issue (besides a vanishingly small chance of a hash collision) is that this looses information so you can't look at a symbol and directly determine what it was. My answer to that is, who cares? The only place where hashing provides less info than compressing is in a debugger and it can grab the full symbol from a table in the static data segment.
> 

I suppose as a stopgap measure that'd work fine, and might even be controlled by a compiler switch, so that in the general case debugger info wouldn't be affected.  And what's more -- the only time these issues come up is with templates, which a lot of debuggers have serious problems with anyway, so..


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1675


shro8822@vandals.uidaho.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |shro8822@vandals.uidaho.edu




------- Comment #3 from shro8822@vandals.uidaho.edu  2007-11-16 10:30 -------
I would set it up as a method of last resort. It wouldn't be used unless the symbol can't be used any other way.


-- 

<d-bugmail@puremagic.com> wrote in message news:fhkgjb$2opv$1@digitalmars.com...
> http://d.puremagic.com/issues/show_bug.cgi?id=1675
>
>
> shro8822@vandals.uidaho.edu changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|
> |shro8822@vandals.uidaho.edu
>
>
>
>
> ------- Comment #3 from shro8822@vandals.uidaho.edu  2007-11-16 
> 10:30 -------
> I would set it up as a method of last resort. It wouldn't be used unless
> the
> symbol can't be used any other way.
>
>
> -- 
>

That's a good idea.  That way, only those very few symbols which actually are too long will be hashed, making the already vanishingly small chance of a hash collision next to zero.

http://d.puremagic.com/issues/show_bug.cgi?id=1675


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #4 from bugzilla@digitalmars.com  2008-06-22 18:53 -------
Fixed dmd 1.031 and 2.015


--