Compile and build tests with too many sections.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Compile and build tests with too many sections.

shankarke@gmail.com
I have a test which generates too many sections and we expect the linker to  
resolve a COMMON symbol that exists in  multiple files.

Test :-

cat > gen.py << \!
for i in range (0, 90000):
    print "int foo%d() { return 0; }" % (i)
print "int mycommon[10];"
!

cat > gen2.py << \!
for i in range (0, 90000):
    print "int bar%d() { return 0; }" % (i)
print "int mycommon[20];"
!

python gen.py > gen.c
python gen2.py > gen2.c

g++ -c -ffunction-sections gen.c
g++ -c -ffunction-sections gen2.c
ld gen.o gen2.o
gen2.o:(.bss+0x0): multiple definition of `mycommon'
gen.o:(.bss+0x0): first defined here

Further analyzing the problem, it looks like ths symbol mycommon gets
allocated in the section .bss as opposed to being a COMMON symbol.

Digging into the object file, When I see the generated file, the reserved
section index SHN_COMMON gets used  up in the object file for symbols
outside COMMON symbols.

Isnt the section indices defined by SHN_COMMON and few others really
reserved, so when the ELF file is being written, ELF file should skip
assigning reserved section numbers for symbols, and use the next available
number ?



Reply | Threaded
Open this post in threaded view
|

Re: Compile and build tests with too many sections.

Alan Modra-3
On Fri, Jan 22, 2016 at 06:54:52PM +0000, Shankar Easwaran wrote:

> I have a test which generates too many sections and we expect the linker to  
> resolve a COMMON symbol that exists in  multiple files.
>
> Test :-
>
> cat > gen.py << \!
> for i in range (0, 90000):
>     print "int foo%d() { return 0; }" % (i)
> print "int mycommon[10];"
> !
>
> cat > gen2.py << \!
> for i in range (0, 90000):
>     print "int bar%d() { return 0; }" % (i)
> print "int mycommon[20];"
> !
>
> python gen.py > gen.c
> python gen2.py > gen2.c
>
> g++ -c -ffunction-sections gen.c
> g++ -c -ffunction-sections gen2.c
> ld gen.o gen2.o
> gen2.o:(.bss+0x0): multiple definition of `mycommon'
> gen.o:(.bss+0x0): first defined here
>
> Further analyzing the problem, it looks like ths symbol mycommon gets
> allocated in the section .bss as opposed to being a COMMON symbol.

Well, yes, you did compile using g++ after all.  C++ is not C, and one
of the differences is how uninitialized global variables behave.

> Digging into the object file, When I see the generated file, the reserved
> section index SHN_COMMON gets used  up in the object file for symbols
> outside COMMON symbols.

You might need to look a little deeper into the object than readelf
shows you.  You'll find that symbols defined in sections with indices
of 0xff00 and higher use SHN_XINDEX in ".symtab".  The actual index
for these symbols is found in ".symtab_shndx".

--
Alan Modra
Australia Development Lab, IBM