One of the software tools I'd come to rely on was Borland's TDUMP utility. This is a little program that dumps out the records in a compiled .OBJ file in human readable form. Its been very handy in the past for examining compiler/assembler outputs and the modifications that my current project applies to those .OBJ file.
It seems TDUMP has some pretty egregious bugs when the count of LNAME strings start to grow beyond the trivial. It starts spewing worthless garbage.
OK fine, I'll try something else. MetaWare shipped a little utility called BD in their compiler packages. BD performs basically the same task as TDUMP and even gives a bit more information in some cases I'm interested in, a bit less in others. BD seemed to not choke on lots of LNAME strings, so that was a good thing.
However, the MetaWare BD utility seems to die with some sort of heap space issues when the number of segments (SEGDEF records) in a .OBJ file starts to get high. One of my test files I use to test my program with has thousands of segments in it and thousands of LNAME strings.
I believe Watcom shipped/ships a utility similar to TDUMP/BD in their compilers. This is a good excuse to load up some of the Watcom compilers which I need to test with anyway...
If the Watcom utility also fails, then I guess I'll have to write my own .OBJ dump utility. That wouldn't be a big deal really -- 90% of the work is already done since the program I'm working on reads .OBJ files and parses them anyway. Its just a matter of cruising through my internal record list and printing out what it contains.
At least my program doesn't choke on thousands of segments or LNAME strings, so I'd be in better shape right from the git go.
No comments:
Post a Comment