Multiple line #0 in LINN32's?

The LINN32 was generated with 2006 architect trial.  Its ***NOT*** a TDUMP
bug, my OMF post processing utility sees the same thing.  The duplicate
entries for a line #0 in an OBJ are in themself harmless, but I have some
concern about what might be going on inside the backend that caused them to
be generated.  The older BC5 was only producing a single entry for line #0.

As a suggestion, there's no reason to be wasting space on 32 bit offsets in
a LINN32 when all the entries in a line number record are less than 65536
(which is the vast majority of cases).  Emitting a LINNUM with 16 bit
offsets would save 2 bytes per entry.


TDUMP output
-------------------------------------------------------------

0005E7 SEGDEF 1 : _TEXT           DWORD PUBLIC  USE32 Class 'CODE'  Length:
115b

blah, blah, blah...

005746 LINN32  Segment: _TEXT
     764:00001001h     769:00001006h     770:00001032h     773:00001038h
775:0000103Eh
     789:00001049h     790:0000104Fh     793:00001051h     799:0000105Ch
801:00001065h
     803:00001080h     804:0000109Ch     809:000010A4h     810:000010ABh
814:000010C0h
     815:000010C9h     818:000010D0h     819:000010E4h     822:000010E9h
823:000010EFh
     811:00001101h     826:0000110Ah     827:00001113h     829:0000111Fh
831:00001128h
     832:00001131h     834:0000114Ah     835:0000114Ch       0:00001150h
839:00001150h
     841:00001153h     842:00001159h     --->  0:0000115Bh       0:0000115Bh
<----
005818 MODE32

My post processing tool's output
-------------------------------------------------------------
0005E7 SEGDEF 1 : _TEXT       DWORD PUBLIC   USE32 Class:'CODE'
(OvlIx==0) Len:115B
*** WARNING *** The SEGDEF record above has problem(s).
  Overlay Index value of zero is illegal

blah, blah, blah...

005756 LINN32 _TEXT
     0764:00001001H  0769:00001006H  0770:00001032H  0773:00001038H
     0775:0000103EH  0789:00001049H  0790:0000104FH  0793:00001051H
     0799:0000105CH  0801:00001065H  0803:00001080H  0804:0000109CH
     0809:000010A4H  0810:000010ABH  0814:000010C0H  0815:000010C9H
     0818:000010D0H  0819:000010E4H  0822:000010E9H  0823:000010EFH
     0811:00001101H  0826:0000110AH  0827:00001113H  0829:0000111FH
     0831:00001128H  0832:00001131H  0834:0000114AH  0835:0000114CH
     0000:00001150H  0839:00001150H  0841:00001153H  0842:00001159H
     --->  0000:0000115BH  0000:0000115BH  <---

Lets suppose for a moment this isn't a bug and/or you have no intention of
doing anything about it if it was a bug.

Q: Will removing the redundant 2nd line number for zero cause anything dire
to happen in the debugger/profiler/etc tools downstream.

If Borland has no intentions of dealing with this, I will rectify it within
the line number optimization phase in my OMF post processor product.

<cutaway@bellsouth.net> wrote in message
news:45b90acc$1@newsgroups.borland.com...
> The LINN32 was generated with 2006 architect trial.  Its ***NOT*** a TDUMP
> bug, my OMF post processing utility sees the same thing.  The duplicate
> entries for a line #0 in an OBJ are in themself harmless, but I have some
> concern about what might be going on inside the backend that caused them
to
> be generated.

cutaway@bellsouth.net wrote:
> Q: Will removing the redundant 2nd line number for zero cause 
> anything dire to happen in the debugger/profiler/etc tools 
> downstream.

It shouldn't be needed anywhere.

> If Borland has no intentions of dealing with this, I will rectify it 
> within the line number optimization phase in my OMF post processor 
> product.

I know it's an open report though I can't give any timeframe of course.
It's a rather benign issue so I don't imagine we'll hotfix it
unless it gets bundled with something else.

Regards,

In article <45d4afd1$1@newsgroups.borland.com>,
 Lee Cantey <lcantey@borland.com> wrote:

> I know it's an open report though I can't give any timeframe of course.
> It's a rather benign issue so I don't imagine we'll hotfix it
> unless it gets bundled with something else.

   Glad to see you posting Lee. How about making that address 
@codegear.com?

-- 
-David Dean
CodeGear C++ QA Engineer

David Dean [CodeGear] wrote:
> In article <45d4afd1$1@newsgroups.borland.com>,
  >    Glad to see you posting Lee. How about making that address
> @codegear.com?

You know, I made that change right *after* I posted. :)

Lee