digitalmars.D.bugs - [Issue 1675] New: "Identifier too long" error with OMF object files
- d-bugmail puremagic.com (24/24) Nov 15 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1675
- d-bugmail puremagic.com (15/15) Nov 15 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1675
- d-bugmail puremagic.com (8/23) Nov 15 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1675
- d-bugmail puremagic.com (9/9) Nov 16 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1675
- Jarrett Billingsley (5/17) Nov 16 2007 That's a good idea. That way, only those very few symbols which actuall...
- d-bugmail puremagic.com (9/9) Jun 22 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1675
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
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. --
Nov 15 2007
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.. --
Nov 15 2007
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. --
Nov 16 2007
<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.
Nov 16 2007
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 --
Jun 22 2008