How to determine contents of data segment?

I compile most of my code at the command-line, and I'm writing a new
code base that, for reasons I can't determine, is stuffing a lot into
the data segment. For example, compiling a "hello world"-type of
program will result in something like:

20 lines, 9.3 seconds, 4000 bytes code, 3000 bytes data.

It's the "3000 bytes data" part that is driving me nuts. I've gone
over the code over and over again and I'm allocating nearly everything
on the heap (ie. no static VARs) so I honestly can't figure out what
the heck the compiler is stuffing into the data segment.

I tried pulling up the executable with embedded debug info into Turbo
Debugger and doing a View->Variables and looking through the list, but
I can't see anything obvious in there that would account for nearly
half of an empty program's size crammed into the data segment. I've
generated a detailed .MAP but there's only a single line in there that
has DATA and it only tells me how large it is.

Is there some way to see what is taking up the data segment?

On Feb 26, 6:55 pm, Jim Leonard <MobyGa...@gmail.com> wrote:
> 20 lines, 9.3 seconds, 4000 bytes code, 3000 bytes data.

(BTW this is a serious inquiry. I know people might be thinking "who
cares about 3000 bytes" but it's more the principle I'm concerned
about.)

On 2008-02-27, Jim Leonard <MobyGamer@gmail.com> wrote:
> I compile most of my code at the command-line, and I'm writing a new
> code base that, for reasons I can't determine, is stuffing a lot into
> the data segment. For example, compiling a "hello world"-type of
> program will result in something like:
>
> 20 lines, 9.3 seconds, 4000 bytes code, 3000 bytes data.
>
> It's the "3000 bytes data" part that is driving me nuts. I've gone
> over the code over and over again and I'm allocating nearly everything
> on the heap (ie. no static VARs) so I honestly can't figure out what
> the heck the compiler is stuffing into the data segment.

Note that that includes the RTL? I know that e.g. the FPC rtl copies the
environment on many OSes, parse the arguments and build an array etc.

Still, for an ancient compiler as TP, 3000 is a tad much. Maybe stack is
included? See if playing with the stack size changes the number.

Jim Leonard wrote :
> ...
> I've
> generated a detailed .MAP but there's only a single line in there that
> has DATA and it only tells me how large it is.
> ...

A small single line "Hello world" program uses 670 bytes of data.
They are all individually accounted for in the map file (using the -gd
argument).

--

/klaus

Jim Leonard wrote:

> the data segment. For example, compiling a "hello world"-type of
> program will result in something like:

Please give some example source code.

If you don't need TP's RTL get TinyRTL.

--
Robert Riebisch
Bitte NUR in der Newsgroup antworten!
Please reply to the Newsgroup ONLY!

On Feb 27, 6:12 am, Klaus Jorgensen <k...@no.spam> wrote:
> > I've
> > generated a detailed .MAP but there's only a single line in there that
> > has DATA and it only tells me how large it is.
>
> A small single line "Hello world" program uses 670 bytes of data.
> They are all individually accounted for in the map file (using the -gd
> argument).

....except what goes in the DATA segment.

I figured it out; evidently:

const
foo:Pchar='this is a string';

....goes in the data segment. I had put about 2K's worth of messages
in an array that way.

Jim Leonard wrote :
> On Feb 27, 6:12 am, Klaus Jorgensen <k...@no.spam> wrote:
>>> I've
>>> generated a detailed .MAP but there's only a single line in there that
>>> has DATA and it only tells me how large it is.
>>
>> A small single line "Hello world" program uses 670 bytes of data.
>> They are all individually accounted for in the map file (using the -gd
>> argument).
>
> ...except what goes in the DATA segment.
>

Then what exactly is the symbols at segment $007F below?


--------------------------------------------------
Start Stop Length Name Class

00000H 00044H 00045H PROGRAM CODE
00050H 007E4H 00795H System CODE
007F0H 00A8FH 002A0H DATA DATA
00A90H 04A8FH 04000H STACK STACK
04A90H 04A90H 00000H HEAP HEAP

Address Publics by Value

0000:000D @
007F:0002 OvrCodeList
007F:0004 OvrHeapSize
007F:0006 OvrDebugPtr
007F:000A OvrHeapOrg
007F:000C OvrHeapPtr
007F:000E OvrHeapEnd
007F:0010 OvrLoadList
007F:0012 OvrDosHandle
007F:0014 OvrEmsHandle
007F:0016 HeapOrg
007F:001A HeapPtr
007F:001E HeapEnd
007F:0022 FreeList
--------------------------------------------------

--

/klaus

On Feb 29, 2:42 pm, Klaus Jorgensen <k...@no.spam> wrote:
> > ...except what goes in the DATA segment.
>
> Then what exactly is the symbols at segment $007F below?
>
> --------------------------------------------------
> Start Stop Length Name Class
>
> 00000H 00044H 00045H PROGRAM CODE
> 00050H 007E4H 00795H System CODE
> 007F0H 00A8FH 002A0H DATA DATA
> 00A90H 04A8FH 04000H STACK STACK
> 04A90H 04A90H 00000H HEAP HEAP
>
> Address Publics by Value
>
> 0000:000D @
> 007F:0002 OvrCodeList
> 007F:0004 OvrHeapSize
> 007F:0006 OvrDebugPtr
> 007F:000A OvrHeapOrg

Yes, I see this now. Having a linear address in the top part and an
intel segfs in the bottom was confusing.

Still, I wish it were broken down more than that. Here is my
actual .map:

Start Stop Length Name Class

....snip...

01810H 020FFH 008F0H DATA DATA

Okay, so there's the DATA. What's in it?

Address Publics by Value

....snip...

0181:0308 PreventSnow
0181:0322 OvrCodeList
0181:0324 OvrHeapSize
0181:0326 OvrDebugPtr
0181:032A OvrHeapOrg
0181:032C OvrHeapPtr
0181:032E OvrHeapEnd
0181:0330 OvrLoadList
0181:0332 OvrDosHandle
0181:0334 OvrEmsHandle
0181:0336 HeapOrg
0181:033A HeapPtr
0181:033E HeapEnd
0181:0342 FreeList
0181:0346 FreeZero
0181:034A HeapError
0181:034E ExitProc
0181:0352 ExitCode
0181:0354 ErrorAddr
0181:0358 PrefixSeg
0181:035A StackLimit
0181:035C InOutRes
0181:035E RandSeed
0181:0362 SelectorInc
0181:0364 Seg0040
0181:0366 SegA000
0181:0368 SegB000
0181:036A SegB800
0181:036C Test8086
0181:036D Test8087
0181:036E FileMode
0181:0372 X
0181:0373 Y
0181:0374 calx
0181:0376 caly
0181:0378 foo
0181:0478 mykeyb
0181:047C kbd
0181:04FC old9
0181:0500 tfMaxScrX
0181:0501 tfMaxScrY
0181:0502 tfScrSizeInWords
0181:0694 Int1D_mode_table
0181:06A2 Input
0181:07A2 Output
0181:08A2 SaveInt00
0181:08A6 SaveInt02
0181:08AA SaveInt1B
0181:08AE SaveInt21
0181:08B2 SaveInt23
0181:08B6 SaveInt24
0181:08BA SaveInt34
0181:08BE SaveInt35
0181:08C2 SaveInt36
0181:08C6 SaveInt37
0181:08CA SaveInt38
0181:08CE SaveInt39
0181:08D2 SaveInt3A
0181:08D6 SaveInt3B
0181:08DA SaveInt3C
0181:08DE SaveInt3D
0181:08E2 SaveInt3E
0181:08E6 SaveInt3F
0181:08EA SaveInt75

I can't see from all this where 2288 bytes ($8f0 listed above) is
coming from. Looking at the map, I am seeing these sizes (in bytes,
after the last column; for unknowns, I'll assume a pointer which is 4
bytes

0181:0308 PreventSnow 1 (defined as const PreventSnow:byte=1)
0181:0322 OvrCodeList 4
0181:0324 OvrHeapSize 4
0181:0326 OvrDebugPtr 4
0181:032A OvrHeapOrg 4
0181:032C OvrHeapPtr 4
0181:032E OvrHeapEnd 4
0181:0330 OvrLoadList 4
0181:0332 OvrDosHandle 4
0181:0334 OvrEmsHandle 4
0181:0336 HeapOrg 4
0181:033A HeapPtr 4
0181:033E HeapEnd 4
0181:0342 FreeList 4
0181:0346 FreeZero 4
0181:034A HeapError 4
0181:034E ExitProc 4
0181:0352 ExitCode 4
0181:0354 ErrorAddr 4
0181:0358 PrefixSeg 4
0181:035A StackLimit 4
0181:035C InOutRes 4
0181:035E RandSeed 4
0181:0362 SelectorInc 4
0181:0364 Seg0040 4
0181:0366 SegA000 4
0181:0368 SegB000 4
0181:036A SegB800 4
0181:036C Test8086 4
0181:036D Test8087 4
0181:036E FileMode 1
0181:0372 X 1
0181:0373 Y 1
0181:0374 calx 1
0181:0376 caly 1
0181:0378 foo 4
0181:0478 mykeyb 4
0181:047C kbd 4
0181:04FC old9 4
0181:0500 tfMaxScrX 1
0181:0501 tfMaxScrY 1
0181:0502 tfScrSizeInWords 2
0181:0694 Int1D_mode_table 4
0181:06A2 Input 4
0181:07A2 Output 4
0181:08A2 SaveInt00 4
0181:08A6 SaveInt02 4
0181:08AA SaveInt1B 4
0181:08AE SaveInt21 4
0181:08B2 SaveInt23 4
0181:08B6 SaveInt24 4
0181:08BA SaveInt34 4
0181:08BE SaveInt35 4
0181:08C2 SaveInt36 4
0181:08C6 SaveInt37 4
0181:08CA SaveInt38 4
0181:08CE SaveInt39 4
0181:08D2 SaveInt3A 4
0181:08D6 SaveInt3B 4
0181:08DA SaveInt3C 4
0181:08DE SaveInt3D 4
0181:08E2 SaveInt3E 4
0181:08E6 SaveInt3F 4
0181:08EA SaveInt75 4

When I add all of those up, I get ~240 bytes. So where are the other
~1800?

On Mar 3, 2:10 pm, Jim Leonard <MobyGa...@gmail.com> wrote:
> When I add all of those up, I get ~240 bytes. So where are the other
> ~1800?

Hold on, I figured out my mistake: The offsets must be *inclusive*,
since I saw something I recognized. Let's take a look at that again:

0181:0378 foo
0181:0478 mykeyb
0181:047C kbd
0181:04FC old9
0181:0500 tfMaxScrX

Look at kbd. It goes from 47c to 4fc. 4fc-47c=128 bytes, which is
exactly how large kbd is (it's not a pointer like I thought, but
rather defined as "foo:array[0..127] of byte"). So, seeing that, I
now realize that I need to go through and start looking at sizes
between offsets.

So, does anyone know of a nice .map analyzer utility out there, to
prevent me from re-inventing the wheel? :-)

Jim Leonard wrote:

> So, does anyone know of a nice .map analyzer utility out there, to
> prevent me from re-inventing the wheel? :-)

Erm... What do you need this tool for? All info is already in the .map
file.

--
Robert Riebisch
Bitte NUR in der Newsgroup antworten!
Please reply to the Newsgroup ONLY!