size of the executables

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

I am very surprised at the size of the executables that I am producing for
my application

ppid pid tid prio code data stack name
pgrp STATE Blocked Memory
5763105 5779496 1 16o 368K 5760K 8192(516K)* ./amiif
5763105 NANOSLEEP ldqnx.so.2
5763105 5779496 2 16o 368K 5760K 4096(132K) ./amiif
5763105 RECEIVE 3 ldqnx.so.2
5763105 5779496 3 16o 368K 5760K 8192(132K) ./amiif
5763105 NANOSLEEP ldqnx.so.2
585756 819246 1 10r 316K 5736K 8192(516K)* ./cdgpstools
819246 REPLY 45067 ldqnx.so.2
5763105 5767204 1 16o 356K 5752K 8192(516K)* ./config
5763105 RECEIVE 3 ldqnx.so.2
5763105 5779497 1 21f 328K 5844K 8192(516K)* ./feedback
5763105 NANOSLEEP ldqnx.so.2
5763105 5779506 1 26f 340K 5736K 8192(516K)* ./gpsif
5763105 NANOSLEEP ldqnx.so.2
5763105 5779506 2 16f 340K 5736K 8192(132K) ./gpsif
5763105 NANOSLEEP ldqnx.so.2
5763105 5779506 3 16f 340K 5736K 4096(132K) ./gpsif
5763105 RECEIVE 3 ldqnx.so.2
5763105 5779506 4 26f 340K 5736K 4096(132K) ./gpsif
5763105 RECEIVE 1 ldqnx.so.2
5763105 5779498 1 16o 384K 5760K 8192(516K)* ./macif
5763105 JOIN 4 ldqnx.so.2
5763105 5779498 2 16o 384K 5760K 12K(132K) ./macif
5763105 REPLY 782339 ldqnx.so.2
5763105 5779498 3 16o 384K 5760K 8192(132K) ./macif
5763105 REPLY 77836 ldqnx.so.2
5763105 5779498 4 16o 384K 5760K 4096(132K) ./macif
5763105 RECEIVE 2 ldqnx.so.2
5763105 5779507 1 22f 428K 6760K 8192(516K)* ./message
5763105 NANOSLEEP ldqnx.so.2
5763105 5779507 2 22f 428K 6760K 4096(260K) ./message
5763105 REPLY 77836 ldqnx.so.2
5763105 5779507 3 22f 428K 6760K 4096(260K) ./message
5763105 NANOSLEEP ldqnx.so.2
5763105 5779507 4 22f 428K 6760K 8192(260K) ./message
5763105 NANOSLEEP ldqnx.so.2
1724465 5763105 1 16o 328K 5740K 8192(516K)* gps/hub/bin/sysmon
5763105 NANOSLEEP ldqnx.so.2
5763105 5767203 1 19o 316K 5740K 8192(516K)* ./tracedebug
5763105 NANOSLEEP ldqnx.so.2
5763105 5767203 2 16o 316K 5740K 4096(132K) ./tracedebug
5763105 RECEIVE 1 ldqnx.so.2
5763105 5767203 3 19o 316K 5740K 16K(132K) ./tracedebug
5763105 REPLY 782339 ldqnx.so.2

What could be causing the data segment to be so large!!

2

“Michael Nunan” <m.nunan@ieee.ca> wrote in news:ab20ef$n0e$1@inn.qnx.com:

I am very surprised at the size of the executables that I am producing
for my application

ppid pid tid prio code data stack name
pgrp STATE Blocked Memory
5763105 5779496 1 16o 368K 5760K 8192(516K)* ./amiif
5763105 NANOSLEEP ldqnx.so.2
5763105 5779496 2 16o 368K 5760K 4096(132K) ./amiif
5763105 RECEIVE 3 ldqnx.so.2
5763105 5779496 3 16o 368K 5760K 8192(132K) ./amiif
5763105 NANOSLEEP ldqnx.so.2
snip
What could be causing the data segment to be so large!!

You’ll have to specify more info on how you’ve making you binaries and what
language you’re using.

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

3

Quoted from email:

The applications are coded in C with staticly linked libraries.

Here is a copy of a sample makefile.

I will really apprectiate some feedback.

Hi Michael,

Please keep news postings to the news group, that way all can help and
contribute.

Looking over you pidin again, I’m not sure you’ve got staticly linked
binaries. It seems (and I could be looking at the wrong processes) that
your processes are using ldqnx.so. This is the dynamic linker and should
not be required for staticly linked binaries. Something that may help you
out, is objdump. If you do an objdump -x, you’ll see what libs are
“NEEDED” (if any) and look at the .data sections and/or .bss. These are
the global data areas that you application has created.

–

Cheers,
Adam
QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>



\

Makefile

Macros

CDGPS_HOME = /home/cdgps/hub

DEBUG_FLAGS= -ggdb
MEM_MODEL=
SRCS=$(OBJS:o=c)

HUB_HEADERS= …/include/macif.h
…/include/cdgps.h
…/include/ipc.h
…/include/csock.h
…/include/ConstDefinition.h

SOCKET_LIBS=-lsocket

HUB_LIB=$(CDGPS_HOME)/lib

MACIF_LIBS =
$(CDGPS_HOME)/lib/csock.a
$(CDGPS_HOME)/lib/ssock.a

INCLUDE_PATH=/usr/include -I…/include


COMP_FLAGS= -Wall -c ${MEM_MODEL} $(DEBUG_FLAGS) -I$(INCLUDE_PATH)


COMPILER = gcc

List of object files goes here

OBJS= macif.o MessageParser.o

TEST_OBJS = test_svr.o

Dependencies

all: test_svr macif

…c.o:
@{ echo “$$USER is making $<” ;
$(COMPILER) $< $(COMP_FLAGS); }

macif: $(OBJS) $(MACIF_LIBS) makefile
{ gcc -o …/bin/macif $(OBJS) -L $(HUB_LIB) $(MACIF_LIBS)
$(SOCKET_LIBS); }


test_svr: $(TEST_OBJS) $(MACIF_LIBS) makefile
{ gcc -o …/bin/test_svr $(TEST_OBJS) -L $(HUB_LIB) $(MACIF_LIBS)
$(SOCKET_LIBS); }


macif.o: macif.c $(HUB_HEADERS) makefile

test_svr.o: test_svr.c $(HUB_HEADERS) makefile

…PHONY : clean
clean :
-rm …/bin/macif $(OBJS)

4

doing objdump -x,

I get the following. I is obvious that the bss section is the one that is
allocating all of the memory.

Sections:
Idx Name Size VMA LMA File off Algn
18 .bss 00590ab0 08051140 08051140 00008140 2**5
ALLOC

SO I guess the question is how do I truncate this section? I am assuming
that the section is the initial stack / heap?

Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 00000014 080480f4 080480f4 000000f4 20
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .note0 00000000 08048108 08048108 00000108 20
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .hash 00000228 08048108 08048108 00000108 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .dynsym 00000450 08048330 08048330 00000330 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .dynstr 000002a0 08048780 08048780 00000780 20
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .rel.bss 00000008 08048a20 08048a20 00000a20 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .rel.plt 000001c8 08048a28 08048a28 00000a28 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .init 00000008 08048bf0 08048bf0 00000bf0 20
CONTENTS, ALLOC, LOAD, READONLY, CODE
8 .plt 000003a0 08048bf8 08048bf8 00000bf8 22
CONTENTS, ALLOC, LOAD, READONLY, CODE
9 .text 00004fbc 08048f98 08048f98 00000f98 22
CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .fini 00000008 0804df54 0804df54 00005f54 20
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 .rodata 000017bc 0804df60 0804df60 00005f60 25
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .data 00000198 08050720 08050720 00007720 25
CONTENTS, ALLOC, LOAD, DATA
13 .eh_frame 000006f8 080508b8 080508b8 000078b8 22
CONTENTS, ALLOC, LOAD, DATA
14 .ctors 00000008 08050fb0 08050fb0 00007fb0 22
CONTENTS, ALLOC, LOAD, DATA
15 .dtors 00000008 08050fb8 08050fb8 00007fb8 22
CONTENTS, ALLOC, LOAD, DATA
16 .got 000000f0 08050fc0 08050fc0 00007fc0 22
CONTENTS, ALLOC, LOAD, DATA
17 .dynamic 00000090 080510b0 080510b0 000080b0 22
CONTENTS, ALLOC, LOAD, DATA
18 .bss 00590ab0 08051140 08051140 00008140 25
ALLOC
19 .comment 00000130 00000000 00000000 00008140 20
CONTENTS, READONLY
20 .debug 000088f0 00000000 00000000 00008270 22
CONTENTS, READONLY, DEBUGGING
21 .line 0000057c 00000000 00000000 00010b60 20
CONTENTS, READONLY, DEBUGGING
22 .debug_srcinfo 0000006c 00000000 00000000 000110dc 20
CONTENTS, READONLY, DEBUGGING
23 .debug_sfnames 0000005a 00000000 00000000 00011148 20
CONTENTS, READONLY, DEBUGGING
24 .debug_aranges 000000c4 00000000 00000000 000111a2 20
CONTENTS, READONLY, DEBUGGING
25 .debug_pubnames 000007d2 00000000 00000000 00011266 20
CONTENTS, READONLY, DEBUGGING
26 .debug_info 0000acea 00000000 00000000 00011a38 20
CONTENTS, READONLY, DEBUGGING
27 .debug_abbrev 00000529 00000000 00000000 0001c722 20
CONTENTS, READONLY, DEBUGGING
28 .debug_line 0000258a 00000000 00000000 0001cc4b 20
CONTENTS, READONLY, DEBUGGING
29 .note 000000a0 00000000 00000000 0001f1d5 20
CONTENTS, READONLY

“Adam Mallory” <amallory@qnx.com> wrote in message
news:Xns9207799C17649amalloryqnxcom@209.226.137.4…

Quoted from email:
The applications are coded in C with staticly linked libraries.

Here is a copy of a sample makefile.

I will really apprectiate some feedback.

Hi Michael,

Please keep news postings to the news group, that way all can help and
contribute.

Looking over you pidin again, I’m not sure you’ve got staticly linked
binaries. It seems (and I could be looking at the wrong processes) that
your processes are using ldqnx.so. This is the dynamic linker and should
not be required for staticly linked binaries. Something that may help you
out, is objdump. If you do an objdump -x, you’ll see what libs are
“NEEDED” (if any) and look at the .data sections and/or .bss. These are
the global data areas that you application has created.

–

Cheers,
Adam
QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net



\

Makefile

Macros

CDGPS_HOME = /home/cdgps/hub

DEBUG_FLAGS= -ggdb
MEM_MODEL=
SRCS=$(OBJS:o=c)

HUB_HEADERS= …/include/macif.h
…/include/cdgps.h
…/include/ipc.h
…/include/csock.h
…/include/ConstDefinition.h

SOCKET_LIBS=-lsocket

HUB_LIB=$(CDGPS_HOME)/lib

MACIF_LIBS =
$(CDGPS_HOME)/lib/csock.a
$(CDGPS_HOME)/lib/ssock.a

INCLUDE_PATH=/usr/include -I…/include


COMP_FLAGS= -Wall -c ${MEM_MODEL} $(DEBUG_FLAGS) -I$(INCLUDE_PATH)


COMPILER = gcc

List of object files goes here

OBJS= macif.o MessageParser.o

TEST_OBJS = test_svr.o

Dependencies

all: test_svr macif

.c.o:
@{ echo “$$USER is making $<” ;
$(COMPILER) $< $(COMP_FLAGS); }

macif: $(OBJS) $(MACIF_LIBS) makefile
{ gcc -o …/bin/macif $(OBJS) -L $(HUB_LIB) $(MACIF_LIBS)
$(SOCKET_LIBS); }


test_svr: $(TEST_OBJS) $(MACIF_LIBS) makefile
{ gcc -o …/bin/test_svr $(TEST_OBJS) -L $(HUB_LIB) $(MACIF_LIBS)
$(SOCKET_LIBS); }


macif.o: macif.c $(HUB_HEADERS) makefile

test_svr.o: test_svr.c $(HUB_HEADERS) makefile

.PHONY : clean
clean :
-rm …/bin/macif $(OBJS)

5

After some further digging I find that there is a (for some unknown reason)
a 5 MB structure !!! incorrectly defined in one of our common header
files. It gets included in all of our apps - and is used in only one of
them.

080516c0 g O .bss 0058ae88 sFeedBack

thanks for the help.

“Michael Nunan” <m.nunan@ieee.ca> wrote in message
news:abeouu$5of$1@inn.qnx.com…

doing objdump -x,

I get the following. I is obvious that the bss section is the one that is
allocating all of the memory.

Sections:
Idx Name Size VMA LMA File off Algn
18 .bss 00590ab0 08051140 08051140 00008140 2**5
ALLOC

SO I guess the question is how do I truncate this section? I am assuming
that the section is the initial stack / heap?

Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 00000014 080480f4 080480f4 000000f4 20
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .note0 00000000 08048108 08048108 00000108 20
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .hash 00000228 08048108 08048108 00000108 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .dynsym 00000450 08048330 08048330 00000330 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .dynstr 000002a0 08048780 08048780 00000780 20
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .rel.bss 00000008 08048a20 08048a20 00000a20 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .rel.plt 000001c8 08048a28 08048a28 00000a28 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .init 00000008 08048bf0 08048bf0 00000bf0 20
CONTENTS, ALLOC, LOAD, READONLY, CODE
8 .plt 000003a0 08048bf8 08048bf8 00000bf8 22
CONTENTS, ALLOC, LOAD, READONLY, CODE
9 .text 00004fbc 08048f98 08048f98 00000f98 22
CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .fini 00000008 0804df54 0804df54 00005f54 20
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 .rodata 000017bc 0804df60 0804df60 00005f60 25
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .data 00000198 08050720 08050720 00007720 25
CONTENTS, ALLOC, LOAD, DATA
13 .eh_frame 000006f8 080508b8 080508b8 000078b8 22
CONTENTS, ALLOC, LOAD, DATA
14 .ctors 00000008 08050fb0 08050fb0 00007fb0 22
CONTENTS, ALLOC, LOAD, DATA
15 .dtors 00000008 08050fb8 08050fb8 00007fb8 22
CONTENTS, ALLOC, LOAD, DATA
16 .got 000000f0 08050fc0 08050fc0 00007fc0 22
CONTENTS, ALLOC, LOAD, DATA
17 .dynamic 00000090 080510b0 080510b0 000080b0 22
CONTENTS, ALLOC, LOAD, DATA
18 .bss 00590ab0 08051140 08051140 00008140 25
ALLOC
19 .comment 00000130 00000000 00000000 00008140 20
CONTENTS, READONLY
20 .debug 000088f0 00000000 00000000 00008270 22
CONTENTS, READONLY, DEBUGGING
21 .line 0000057c 00000000 00000000 00010b60 20
CONTENTS, READONLY, DEBUGGING
22 .debug_srcinfo 0000006c 00000000 00000000 000110dc 20
CONTENTS, READONLY, DEBUGGING
23 .debug_sfnames 0000005a 00000000 00000000 00011148 20
CONTENTS, READONLY, DEBUGGING
24 .debug_aranges 000000c4 00000000 00000000 000111a2 20
CONTENTS, READONLY, DEBUGGING
25 .debug_pubnames 000007d2 00000000 00000000 00011266 20
CONTENTS, READONLY, DEBUGGING
26 .debug_info 0000acea 00000000 00000000 00011a38 20
CONTENTS, READONLY, DEBUGGING
27 .debug_abbrev 00000529 00000000 00000000 0001c722 20
CONTENTS, READONLY, DEBUGGING
28 .debug_line 0000258a 00000000 00000000 0001cc4b 20
CONTENTS, READONLY, DEBUGGING
29 .note 000000a0 00000000 00000000 0001f1d5 20
CONTENTS, READONLY

“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:Xns9207799C17649amalloryqnxcom@209.226.137.4…
Quoted from email:
The applications are coded in C with staticly linked libraries.

Here is a copy of a sample makefile.

I will really apprectiate some feedback.

Hi Michael,

Please keep news postings to the news group, that way all can help and
contribute.

Looking over you pidin again, I’m not sure you’ve got staticly linked
binaries. It seems (and I could be looking at the wrong processes) that
your processes are using ldqnx.so. This is the dynamic linker and
should
not be required for staticly linked binaries. Something that may help
you
out, is objdump. If you do an objdump -x, you’ll see what libs are
“NEEDED” (if any) and look at the .data sections and/or .bss. These are
the global data areas that you application has created.

–

Cheers,
Adam
QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net



\

Makefile

Macros

CDGPS_HOME = /home/cdgps/hub

DEBUG_FLAGS= -ggdb
MEM_MODEL=
SRCS=$(OBJS:o=c)

HUB_HEADERS= …/include/macif.h
…/include/cdgps.h
…/include/ipc.h
…/include/csock.h
…/include/ConstDefinition.h

SOCKET_LIBS=-lsocket

HUB_LIB=$(CDGPS_HOME)/lib

MACIF_LIBS =
$(CDGPS_HOME)/lib/csock.a
$(CDGPS_HOME)/lib/ssock.a

INCLUDE_PATH=/usr/include -I…/include


COMP_FLAGS= -Wall -c ${MEM_MODEL} $(DEBUG_FLAGS) -I$(INCLUDE_PATH)


COMPILER = gcc

List of object files goes here

OBJS= macif.o MessageParser.o

TEST_OBJS = test_svr.o

Dependencies

all: test_svr macif

.c.o:
@{ echo “$$USER is making $<” ;
$(COMPILER) $< $(COMP_FLAGS); }

macif: $(OBJS) $(MACIF_LIBS) makefile
{ gcc -o …/bin/macif $(OBJS) -L $(HUB_LIB) $(MACIF_LIBS)
$(SOCKET_LIBS); }


test_svr: $(TEST_OBJS) $(MACIF_LIBS) makefile
{ gcc -o …/bin/test_svr $(TEST_OBJS) -L $(HUB_LIB)
$(MACIF_LIBS)
$(SOCKET_LIBS); }


macif.o: macif.c $(HUB_HEADERS) makefile

test_svr.o: test_svr.c $(HUB_HEADERS) makefile

.PHONY : clean
clean :
-rm …/bin/macif $(OBJS)