OT - Name Mangling software

[David Wade]

Folks,

Does any one know of any "name mangling" software that allows standard C
with long names to be linked? Any suggestions for a better place to look? I
have tried putting various searchs into google to no avail.

Dave.

 

[Kenneth Brody]

Folks,

Does any one know of any "name mangling" software that allows standard C
with long names to be linked? Any suggestions for a better place to look? I
have tried putting various searchs into google to no avail.

Why do you need to "mangle" the names just because they're "long"?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Eric Sosman]

Kenneth Brody wrote On 05/09/06 16:08,:

Why do you need to "mangle" the names just because they're "long"?

The usual reason is that the code uses a set of
external names that clash if merely truncated to the
linker's limit:

int getDescenderHeight(const Font *f);
const char *getDescription(const Font *f);
struct design_t *getDesign(const Font *f);
enum destination getDestination(const Taxi *t);

.... all of which are just `GETDES' to a case-insensitive
six-character linker satisfying the C89 minimal requirement.
What D.W. needs is some kind of tool that collects all these
names and writes a .h file like

#define getDescent GET121
#define getDescription GEN845
#define getDesign GEN126
#define getDestination GEN666

.... that he can then #include everywhere.

It was more than twenty years ago that I last confronted
this problem, and the tool we used was not something pre-
packaged: We just cobbled together a few shell scripts and
a short ad-hoc program. One important advantage was that we
were doing a port from a less-limited system where we were
able to build the program with the full names; this allowed
us to extract the names from the executable with an existing
system utility ("nm") instead of needing to parse the C source.

The worst part, as I recall, wasn't writing the mangler
but trying to use the debugger on the code whose long external
names had all been changed ... A pair of original-to-mangled
and mangled-to-original "dictionaries" helped, but there was
a lot of back-and-forthing just to figure out where to set a
breakpoint. Interpreting a stack trace was painful ... It
helps a little if the mangling preserves some "interesting"
features of the original names. It helps even more if the
mangling doesn't change (much) from day to day. Together,
these two suggest that the mangling should be driven as much
from the name itself as possible, and shouldn't just be a
disguised sequence number or address or some such that has
zero mnemonic value and defeats memorization.

Alas, I'm not aware of a pre-packaged tool that does this
sort of thing. On the other hand, it was a smallish bit of
work to put the tool together, and only the work of a few days
to refine it as far as we thought we could usefully go.

 

[CBFalconer]

Does any one know of any "name mangling" software that allows
standard C with long names to be linked? Any suggestions for a
better place to look? I have tried putting various searchs into
google to no avail.

My id2id package can be used to make consistent substitutions over
a set of source files, thus avoiding the problem entirely. If
properly selected the entire process is also reversible. In fact
one of the testing examples converts its own source into something
with only 2 character identifiers, and back again. See:

<http://cbfalconer.home.att.net/download/id2id-20.zip>

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - GWB 2004-2-8
"If I knew then what I know today, I would still have invaded
Iraq. It was the right decision" - G.W. Bush, 2004-08-02
"This notion that the United States is getting ready to attack
Iran is simply ridiculous. And having said that, all options
are on the table." - George W. Bush, Brussels, 2005-02-22

 

[David Wade]

My id2id package can be used to make consistent substitutions over
a set of source files, thus avoiding the problem entirely. If
properly selected the entire process is also reversible. In fact
one of the testing examples converts its own source into something
with only 2 character identifiers, and back again. See:

<http://cbfalconer.home.att.net/download/id2id-20.zip>>

That looks like one starting point, but you really need to know what ID's
are in use, which is not always easier. Why is this better than the
"#define" approach I have been using so far?

 

[CBFalconer]

That looks like one starting point, but you really need to know
what ID's are in use, which is not always easier. Why is this
better than the "#define" approach I have been using so far?

Because you don't have to distort anything. To get a list of ids
in your own package just run a cross-referencer. You are only
interested in ids that exceed the maximum length your linker can
handle, easily extracted from the xref with standard tools.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[David Wade]

Because you don't have to distort anything. To get a list of ids
in your own package just run a cross-referencer. You are only
interested in ids that exceed the maximum length your linker can
handle, easily extracted from the xref with standard tools.

Unfortunatly my assembler gets upset as well :-(