.ctors / .init_array sections

When I build a simple hello world sample on i386 and x64 on Linux with Clang 3.3, the x64 version has .init_array / .fini_array and the i386 binary has .ctors / .dtors.

i386:

[18] .ctors PROGBITS
[19] .dtors PROGBITS

x64:

[18] .init_array INIT_ARRAY
[19] .fini_array FINI_ARRAY

There is code in ObjectFileELF.cpp which specifically looks for sections named “.ctors” and “.dtors” and sets the symbol type to eSymbolTypeCode if it not already set. There is no check for init_array there. That means the x64 version lists these symbols as Invalid currently.

(lldb) target modules dump symtab hello_world

i386:

[ 17] Code __init_array_end
[ 18] Code __init_array_start

x64:

[ 17] Invalid __init_array_end
[ 18] Invalid __init_array_start

I believe the fix is to add a check for init_array + fini_array and mark those sections as code. If anyone has any knowledge / comments on this, please fire away, otherwise I’ll post a patch in the next couple days.

There are also some sections in both i386 and x64 that are being marked as undefined. I assume this is ok?

[ 24] 55 Undefined 0x0000000000000000 0x0000000000000000 0x00000020 gmon_start
[ 25] 56 Undefined 0x0000000000000000 0x0000000000000000 0x00000020 _Jv_RegisterClasses

[ 28] 59 X Undefined 0x0000000000000000 0x0000000000000000 0x00000012 __libc_start_main@@GLIBC_2.0

Thanks.
-Mike

When I build a simple hello world sample on i386 and x64 on Linux with Clang 3.3, the x64 version has .init_array / .fini_array and the i386 binary has .ctors / .dtors.

i386:
  [18] .ctors PROGBITS
  [19] .dtors PROGBITS

x64:
  [18] .init_array INIT_ARRAY
  [19] .fini_array FINI_ARRAY

There is code in ObjectFileELF.cpp which specifically looks for sections named ".ctors" and ".dtors" and sets the symbol type to eSymbolTypeCode if it not already set. There is no check for init_array there. That means the x64 version lists these symbols as Invalid currently.

(lldb) target modules dump symtab hello_world

i386:
[ 17] Code __init_array_end
[ 18] Code __init_array_start

x64:
[ 17] Invalid __init_array_end
[ 18] Invalid __init_array_start

I believe the fix is to add a check for init_array + fini_array and mark those sections as code. If anyone has any knowledge / comments on this, please fire away, otherwise I'll post a patch in the next couple days.

From a brief web search it seems that these sections contain one or more function pointers. These functions get called in the order in which they are in the table in order to do global construction/destruction. I am not sure I would classify this as code, more as data since we would never set breakpoints in this code. So I would say to classify these sections as “eSectionTypeDataPointers”.

There are also some sections in both i386 and x64 that are being marked as undefined. I assume this is ok?

[ 24] 55 Undefined 0x0000000000000000 0x0000000000000000 0x00000020 __gmon_start__
[ 25] 56 Undefined 0x0000000000000000 0x0000000000000000 0x00000020 _Jv_RegisterClasses
[ 28] 59 X Undefined 0x0000000000000000 0x0000000000000000 0x00000012 __libc_start_main@@GLIBC_2.0

In general when classifying sections, I would try and see what the program headers say about the address itself. If the address is in executable code, then I would classify this as code.