www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1675] New: "Identifier too long" error with OMF object files

reply d-bugmail puremagic.com writes:
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.


--
Nov 15 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1675






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.


--
Nov 15 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1675








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


--
Nov 15 2007
prev sibling next sibling parent reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1675


shro8822 vandals.uidaho.edu changed:

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





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.


--
Nov 16 2007
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
<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





 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.
Nov 16 2007
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1675


bugzilla digitalmars.com changed:

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





Fixed dmd 1.031 and 2.015


--
Jun 22 2008