[solved] ld error: crtbegin.o: file not recognized

[xeyes]

Update: The ctor problem below can be worked around using --disable-initfini-array

Now stuck at this error from ld:

crtbegin.o: file not recognized

Yet ld doesn't have any issue with crtend.o and the rest of their gang (crt*.o)

Below is original post:

Managed to build a static version of gcc using newlib. But perhaps as expected, getting it to run properly is another challenge.

It can now launch cc1, and cc1 crashes early into the run because processor_alias_table is all zeros.

processor_alias_table is an array of structs in i386-common.c, looks like below:

Code: Select all

const pta processor_alias_table[] =
{
  {"i386", PROCESSOR_I386, CPU_NONE, 0},
  ...

Its address in elf is within bss so the loader zeroed the area.

But it is not initialized by any constructor either. In fact _init called from my _start didn't run anything because it read out -1 as the first ctor entry and simply returned. Checked __CTOR_LIST__ manually and indeed the first entry there is 0xffffffff.

_init's ctor running function looks like below:

Code: Select all

0x91d3140 <__do_global_ctors_aux>         mov    0x982a0ac,%eax                                     
0x91d3145 <__do_global_ctors_aux+5>     cmp    $0xffffffff,%eax                                   
0x91d3148 <__do_global_ctors_aux+8>     je     0x91d3180 <__do_global_ctors_aux+64>

__CTOR_LIST__ is at 0x982a0ac and the value there is 0xffffffff followed by 0x0

So I'm lost now as of whether it is mis-configured and resulted in a broken build that is missing the needed ctors or there are more ways to initialize a global array than loading .data or initializing using a constructor.

Searched old posts and the internet but didn't find anything obvious, would appreciate any help on what other ways of initializing a global array in C that I might have missed or other places to check for.

[kzinti]

Looks like a missing or incorrect link script?

How do you link crtbegin.o / crtend.o?

[nullplan]

Its address in elf is within bss so the loader zeroed the area.

Well, that is certainly wrong. A constant array like that should be in .rodata. So either the compiler or the linker screwed up here. And since there is no constructor creating the table, I'm guessing it's the latter. Try finding the object files and maybe go from there.

[xeyes]

Looks like a missing or incorrect link script?

How do you link crtbegin.o / crtend.o?

How I do track down linker scripts of complex projects like this? Do they even use static ones or maybe they generate those on the fly?

I only issued make cmd as per the wiki page, the cmd (from make's output) to link cc1 is below and doesn't have crtbegin.o & crtend.o in it, but this cmd is given to g++.

Code: Select all

i686-myos-g++ -no-pie   -g -O2 -DIN_GCC -fPIC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o i386-c.o default-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -L/home/ac9/ws/buildccs/./isl/.libs  -lisl -L/home/ac9/ws/buildccs/./gmp/.libs -L/home/ac9/ws/buildccs/./mpfr/src/.libs -L/home/ac9/ws/buildccs/./mpc/src/.libs -lmpc -lmpfr -lgmp   -L./../zlib -lz 

I did notice that the binary actually had all the constructors in .init_array section, but doesn't have __init_array_start, __init_array_end symbols.

Searched more and found this post viewtopic.php?f=1&t=33834. by adding --disable-initfini-array to all the configure steps the constructors are forced into .ctor section instead and the newlib _init was able to run them.

Now cc1 is seemingly working for helloworld and I made a few other changes to keep the whole chain going further, it is now stuck at another error from ld:

crtbegin.o: file not recongnized: file format not recognized

While collect2 asked ld to link a few object files, this seems to be the only one that is problemtic.
ld complains like this even if I manually run it with this single .o. While it doesn't seem to have any problem with crt0.o crti.o, crtend.0 crtn.0 or the .o from the helloworld code.

Any idea on where could I have messed up that caused crtbegin.o alone to be not recognizable by ld?

[xeyes]

Its address in elf is within bss so the loader zeroed the area.

Well, that is certainly wrong. A constant array like that should be in .rodata. So either the compiler or the linker screwed up here. And since there is no constructor creating the table, I'm guessing it's the latter. Try finding the object files and maybe go from there.

It works better now that the ctors are put into .ctor.

finding the object files and maybe go from there

What can I do with object files? It is now stuck at ld doesn't recognize crtbegin.o but does recognize the others like crtend.o.

I used readelf on all the gcc supplied .o files and all of them have the same header/type info like below:

Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: Intel 80386

Anything else that I should look out for in the .o files?

[kzinti]

How do you link crtbegin.o / crtend.o?

If you link using GCC, it should be automatic (unless you use freestanding / nostdlib).

How I do track down linker scripts of complex projects like this? Do they even use static ones or maybe they generate those on the fly?

If you are not using an explicit one, I assume it reverts to a default one and that might be the problem. You are not supposed to have both a __CTOR_LIST__ and a .init_array section. These are two different mechanisms to call constructors. The former is the older method and the later is the new one. .init_array is the better option because the constructors can be executed in the correct order where the __CTOR_LIST__ method will execute constructors in the order you linked them. To me it looks like your GCC is configured to use .init_array and that you are using a linker script + crtbegin.o that are configured to use __CTOR_LIST__, which shouldn't happen with a clean GCC build.

I did notice that the binary actually had all the constructors in .init_array section, but doesn't have __init_array_start, __init_array_end symbols.

Correct, you need to provide them yourself (using a link script) if you want them. These are not strictly required as the intended use if for your ELF loader to find the .init_array section using DT_INIT_ARRAY and execute the constructors. In that scenario, no symbols are required.

Searched more and found this post viewtopic.php?f=1&t=33834. by adding --disable-initfini-array to all the configure steps the constructors are forced into .ctor section instead and the newlib _init was able to run them.

That is correct: disabling init/fini arrays means GCC will revert back to the older method of using __CTOR_LIST__. It does mean your code will call __do_global_ctors_aux() which is provided by crtbegin.o.

crtbegin.o: file not recongnized: file format not recognized

Any idea on where could I have messed up that caused crtbegin.o alone to be not recognizable by ld?

Looks like a corrupted file. This is weird. Try dumping it with "objdump -D"?

[xeyes]

How do you link crtbegin.o / crtend.o?

If you link using GCC, it should be automatic (unless you use freestanding / nostdlib).

How I do track down linker scripts of complex projects like this? Do they even use static ones or maybe they generate those on the fly?

If you are not using an explicit one, I assume it reverts to a default one and that might be the problem. You are not supposed to have both a __CTOR_LIST__ and a .init_array section. These are two different mechanisms to call constructors. The former is the older method and the later is the new one. .init_array is the better option because the constructors can be executed in the correct order where the __CTOR_LIST__ method will execute constructors in the order you linked them. To me it looks like your GCC is configured to use .init_array and that you are using a linker script + crtbegin.o that are configured to use __CTOR_LIST__, which shouldn't happen with a clean GCC build.

Maybe by not specifying either enable or disable initfini, the configure script was confused and resulted in parts not agreeing with each other?

I searched the gcc folder and the single ld file in there is in a test folder. But it is unlikely that project with its scale doesn't use linker scripts, so maybe they generate linker scripts during the build or maybe the scripts are not named *.ld?

Looks like a corrupted file. This is weird. Try dumping it with "objdump -D"?

The file is not corrupted during copying as the md5 cheksums match, but that obviously can't tell whether it is broken or of a wrong format.

objdump -D output of crtbegin.o below, there some scary things like relocation in there but those shouldn't make ld not recognize the format right?

Also attached the output for crtend.o at the end. They look to be the same or similiar format at least to my eyes

Code: Select all

crtbegin.o:     file format elf32-i386


Disassembly of section .group:

00000000 <.group>:
   0:	01 00                	add    %eax,(%eax)
   2:	00 00                	add    %al,(%eax)
   4:	10 00                	adc    %al,(%eax)
	...

Disassembly of section .group:

00000000 <.group>:
   0:	01 00                	add    %eax,(%eax)
   2:	00 00                	add    %al,(%eax)
   4:	11 00                	adc    %eax,(%eax)
	...

Disassembly of section .group:

00000000 <.group>:
   0:	01 00                	add    %eax,(%eax)
   2:	00 00                	add    %al,(%eax)
   4:	12 00                	adc    (%eax),%al
	...

Disassembly of section .text:

00000000 <deregister_tm_clones>:
   0:	e8 fc ff ff ff       	call   1 <deregister_tm_clones+0x1>
   5:	81 c2 02 00 00 00    	add    $0x2,%edx
   b:	8d 8a 00 00 00 00    	lea    0x0(%edx),%ecx
  11:	8d 82 00 00 00 00    	lea    0x0(%edx),%eax
  17:	39 c8                	cmp    %ecx,%eax
  19:	74 25                	je     40 <deregister_tm_clones+0x40>
  1b:	8b 82 00 00 00 00    	mov    0x0(%edx),%eax
  21:	85 c0                	test   %eax,%eax
  23:	74 1b                	je     40 <deregister_tm_clones+0x40>
  25:	55                   	push   %ebp
  26:	89 e5                	mov    %esp,%ebp
  28:	83 ec 14             	sub    $0x14,%esp
  2b:	51                   	push   %ecx
  2c:	ff d0                	call   *%eax
  2e:	83 c4 10             	add    $0x10,%esp
  31:	c9                   	leave  
  32:	c3                   	ret    
  33:	8d b4 26 00 00 00 00 	lea    0x0(%esi,%eiz,1),%esi
  3a:	8d b6 00 00 00 00    	lea    0x0(%esi),%esi
  40:	c3                   	ret    
  41:	8d b4 26 00 00 00 00 	lea    0x0(%esi,%eiz,1),%esi
  48:	8d b4 26 00 00 00 00 	lea    0x0(%esi,%eiz,1),%esi
  4f:	90                   	nop

00000050 <register_tm_clones>:
  50:	e8 fc ff ff ff       	call   51 <register_tm_clones+0x1>
  55:	81 c2 02 00 00 00    	add    $0x2,%edx
  5b:	55                   	push   %ebp
  5c:	89 e5                	mov    %esp,%ebp
  5e:	53                   	push   %ebx
  5f:	8d 8a 00 00 00 00    	lea    0x0(%edx),%ecx
  65:	8d 82 00 00 00 00    	lea    0x0(%edx),%eax
  6b:	83 ec 04             	sub    $0x4,%esp
  6e:	29 c8                	sub    %ecx,%eax
  70:	89 c3                	mov    %eax,%ebx
  72:	c1 e8 1f             	shr    $0x1f,%eax
  75:	c1 fb 02             	sar    $0x2,%ebx
  78:	01 d8                	add    %ebx,%eax
  7a:	d1 f8                	sar    %eax
  7c:	74 14                	je     92 <register_tm_clones+0x42>
  7e:	8b 92 00 00 00 00    	mov    0x0(%edx),%edx
  84:	85 d2                	test   %edx,%edx
  86:	74 0a                	je     92 <register_tm_clones+0x42>
  88:	83 ec 08             	sub    $0x8,%esp
  8b:	50                   	push   %eax
  8c:	51                   	push   %ecx
  8d:	ff d2                	call   *%edx
  8f:	83 c4 10             	add    $0x10,%esp
  92:	8b 5d fc             	mov    -0x4(%ebp),%ebx
  95:	c9                   	leave  
  96:	c3                   	ret    
  97:	8d b4 26 00 00 00 00 	lea    0x0(%esi,%eiz,1),%esi
  9e:	66 90                	xchg   %ax,%ax

000000a0 <__do_global_dtors_aux>:
  a0:	55                   	push   %ebp
  a1:	89 e5                	mov    %esp,%ebp
  a3:	57                   	push   %edi
  a4:	e8 fc ff ff ff       	call   a5 <__do_global_dtors_aux+0x5>
  a9:	81 c7 02 00 00 00    	add    $0x2,%edi
  af:	56                   	push   %esi
  b0:	53                   	push   %ebx
  b1:	83 ec 0c             	sub    $0xc,%esp
  b4:	80 bf 00 00 00 00 00 	cmpb   $0x0,0x0(%edi)
  bb:	75 63                	jne    120 <__do_global_dtors_aux+0x80>
  bd:	8d b7 00 00 00 00    	lea    0x0(%edi),%esi
  c3:	8d 9f 00 00 00 00    	lea    0x0(%edi),%ebx
  c9:	8b 87 04 00 00 00    	mov    0x4(%edi),%eax
  cf:	29 f3                	sub    %esi,%ebx
  d1:	c1 fb 02             	sar    $0x2,%ebx
  d4:	83 eb 01             	sub    $0x1,%ebx
  d7:	39 d8                	cmp    %ebx,%eax
  d9:	73 1b                	jae    f6 <__do_global_dtors_aux+0x56>
  db:	8d 74 26 00          	lea    0x0(%esi,%eiz,1),%esi
  df:	90                   	nop
  e0:	83 c0 01             	add    $0x1,%eax
  e3:	89 87 04 00 00 00    	mov    %eax,0x4(%edi)
  e9:	ff 14 86             	call   *(%esi,%eax,4)
  ec:	8b 87 04 00 00 00    	mov    0x4(%edi),%eax
  f2:	39 d8                	cmp    %ebx,%eax
  f4:	72 ea                	jb     e0 <__do_global_dtors_aux+0x40>
  f6:	e8 05 ff ff ff       	call   0 <deregister_tm_clones>
  fb:	8b 87 00 00 00 00    	mov    0x0(%edi),%eax
 101:	85 c0                	test   %eax,%eax
 103:	74 14                	je     119 <__do_global_dtors_aux+0x79>
 105:	83 ec 0c             	sub    $0xc,%esp
 108:	8d 87 00 00 00 00    	lea    0x0(%edi),%eax
 10e:	89 fb                	mov    %edi,%ebx
 110:	50                   	push   %eax
 111:	e8 fc ff ff ff       	call   112 <__do_global_dtors_aux+0x72>
 116:	83 c4 10             	add    $0x10,%esp
 119:	c6 87 00 00 00 00 01 	movb   $0x1,0x0(%edi)
 120:	8d 65 f4             	lea    -0xc(%ebp),%esp
 123:	5b                   	pop    %ebx
 124:	5e                   	pop    %esi
 125:	5f                   	pop    %edi
 126:	5d                   	pop    %ebp
 127:	c3                   	ret    
 128:	8d b4 26 00 00 00 00 	lea    0x0(%esi,%eiz,1),%esi
 12f:	90                   	nop

00000130 <frame_dummy>:
 130:	55                   	push   %ebp
 131:	89 e5                	mov    %esp,%ebp
 133:	53                   	push   %ebx
 134:	e8 fc ff ff ff       	call   135 <frame_dummy+0x5>
 139:	81 c3 02 00 00 00    	add    $0x2,%ebx
 13f:	83 ec 04             	sub    $0x4,%esp
 142:	8b 83 00 00 00 00    	mov    0x0(%ebx),%eax
 148:	85 c0                	test   %eax,%eax
 14a:	74 19                	je     165 <frame_dummy+0x35>
 14c:	83 ec 08             	sub    $0x8,%esp
 14f:	8d 83 08 00 00 00    	lea    0x8(%ebx),%eax
 155:	50                   	push   %eax
 156:	8d 83 00 00 00 00    	lea    0x0(%ebx),%eax
 15c:	50                   	push   %eax
 15d:	e8 fc ff ff ff       	call   15e <frame_dummy+0x2e>
 162:	83 c4 10             	add    $0x10,%esp
 165:	8b 5d fc             	mov    -0x4(%ebp),%ebx
 168:	c9                   	leave  
 169:	e9 e2 fe ff ff       	jmp    50 <register_tm_clones>

Disassembly of section .data:

00000000 <__dso_handle>:
   0:	00 00                	add    %al,(%eax)
	...

Disassembly of section .bss:

00000000 <completed.2>:
   0:	00 00                	add    %al,(%eax)
	...

00000004 <dtor_idx.1>:
   4:	00 00                	add    %al,(%eax)
	...

00000008 <object.0>:
	...

Disassembly of section .ctors:

00000000 <__CTOR_LIST__>:
   0:	ff                   	(bad)  
   1:	ff                   	(bad)  
   2:	ff                   	(bad)  
   3:	ff                   	.byte 0xff

Disassembly of section .dtors:

00000000 <__DTOR_LIST__>:
   0:	ff                   	(bad)  
   1:	ff                   	(bad)  
   2:	ff                   	(bad)  
   3:	ff                   	.byte 0xff

Disassembly of section .fini:

00000000 <.fini>:
   0:	e8 9c 00 00 00       	call   a1 <__do_global_dtors_aux+0x1>

Disassembly of section .init:

00000000 <.init>:
   0:	e8 2c 01 00 00       	call   131 <frame_dummy+0x1>

Disassembly of section .text.__x86.get_pc_thunk.dx:

00000000 <__x86.get_pc_thunk.dx>:
   0:	8b 14 24             	mov    (%esp),%edx
   3:	c3                   	ret    

Disassembly of section .text.__x86.get_pc_thunk.bx:

00000000 <__x86.get_pc_thunk.bx>:
   0:	8b 1c 24             	mov    (%esp),%ebx
   3:	c3                   	ret    

Disassembly of section .text.__x86.get_pc_thunk.di:

00000000 <__x86.get_pc_thunk.di>:
   0:	8b 3c 24             	mov    (%esp),%edi
   3:	c3                   	ret    

Disassembly of section .comment:

00000000 <.comment>:
   0:	00 47 43             	add    %al,0x43(%edi)
   3:	43                   	inc    %ebx
   4:	3a 20                	cmp    (%eax),%ah
   6:	28 47 4e             	sub    %al,0x4e(%edi)
   9:	55                   	push   %ebp
   a:	29 20                	sub    %esp,(%eax)
   c:	31 30                	xor    %esi,(%eax)
   e:	2e 32 2e             	xor    %cs:(%esi),%ch
  11:	30 00                	xor    %al,(%eax)

Here is the objdump for crtend.o:

Code: Select all

crtend.o:     file format elf32-i386


Disassembly of section .group:

00000000 <.group>:
   0:	01 00                	add    %eax,(%eax)
   2:	00 00                	add    %al,(%eax)
   4:	0c 00                	or     $0x0,%al
	...

Disassembly of section .text:

00000000 <__do_global_ctors_aux>:
   0:	e8 fc ff ff ff       	call   1 <__do_global_ctors_aux+0x1>
   5:	81 c2 02 00 00 00    	add    $0x2,%edx
   b:	8b 82 fc ff ff ff    	mov    -0x4(%edx),%eax
  11:	83 f8 ff             	cmp    $0xffffffff,%eax
  14:	74 3a                	je     50 <__do_global_ctors_aux+0x50>
  16:	55                   	push   %ebp
  17:	89 e5                	mov    %esp,%ebp
  19:	53                   	push   %ebx
  1a:	8d 9a fc ff ff ff    	lea    -0x4(%edx),%ebx
  20:	83 ec 04             	sub    $0x4,%esp
  23:	8d b4 26 00 00 00 00 	lea    0x0(%esi,%eiz,1),%esi
  2a:	8d b6 00 00 00 00    	lea    0x0(%esi),%esi
  30:	ff d0                	call   *%eax
  32:	8b 43 fc             	mov    -0x4(%ebx),%eax
  35:	83 eb 04             	sub    $0x4,%ebx
  38:	83 f8 ff             	cmp    $0xffffffff,%eax
  3b:	75 f3                	jne    30 <__do_global_ctors_aux+0x30>
  3d:	8b 5d fc             	mov    -0x4(%ebp),%ebx
  40:	c9                   	leave  
  41:	c3                   	ret    
  42:	8d b4 26 00 00 00 00 	lea    0x0(%esi,%eiz,1),%esi
  49:	8d b4 26 00 00 00 00 	lea    0x0(%esi,%eiz,1),%esi
  50:	c3                   	ret    

Disassembly of section .ctors:

00000000 <__CTOR_END__>:
   0:	00 00                	add    %al,(%eax)
	...

Disassembly of section .dtors:

00000000 <__DTOR_END__>:
   0:	00 00                	add    %al,(%eax)
	...

Disassembly of section .eh_frame:

00000000 <__FRAME_END__>:
   0:	00 00                	add    %al,(%eax)
	...

Disassembly of section .init:

00000000 <.init>:
   0:	e8 fc ff ff ff       	call   1 <.init+0x1>

Disassembly of section .text.__x86.get_pc_thunk.dx:

00000000 <__x86.get_pc_thunk.dx>:
   0:	8b 14 24             	mov    (%esp),%edx
   3:	c3                   	ret    

Disassembly of section .comment:

00000000 <.comment>:
   0:	00 47 43             	add    %al,0x43(%edi)
   3:	43                   	inc    %ebx
   4:	3a 20                	cmp    (%eax),%ah
   6:	28 47 4e             	sub    %al,0x4e(%edi)
   9:	55                   	push   %ebp
   a:	29 20                	sub    %esp,(%eax)
   c:	31 30                	xor    %esi,(%eax)
   e:	2e 32 2e             	xor    %cs:(%esi),%ch
  11:	30 00                	xor    %al,(%eax)

[Octocontrabass]

How I do track down linker scripts of complex projects like this? Do they even use static ones or maybe they generate those on the fly?

Pass --verbose to ld (or -Wl,--verbose to GCC) when linking and it will show you the linker script it's using.

[kzinti]

Your crtbegin.o and crtend.o look fine to me. Must be something with the link script being used. I don't use the default one so I am not sure which one would be used.

[xeyes]

Your crtbegin.o and crtend.o look fine to me. Must be something with the link script being used. I don't use the default one so I am not sure which one would be used.

Yet another "POSIX compliance" issue

my lseek() returns 0 on success which can mess up the FILE stream state kept by newlib.

When ld used convenient file position movement functions like rewind() to move around in the object file, the file offset kept by both the kernel and newlib can get messed up in certain situations (my guess is that whenever the file is bigger than some internal file buffer of the tools).

It turns out that among the crt*.o, only crtbegin.o is bigger than that threshold. Thus ld failed to read section header names just for crtbegin.o and determined that the file is neither a valid ELF file nor a linker script thus 'not recognized'.

Finally got it to produce a helloworld binary

[kzinti]

Glad you found the problem!

[xeyes]

Glad you found the problem!

Thanks, I probably need a more careful review of all return codes as it takes much longer to get to it from an 'unrelated' error from a user app.

[kzinti]

Might be worth investing in some unit tests here to make sure your APIs follow the spec.

[xeyes]

How I do track down linker scripts of complex projects like this? Do they even use static ones or maybe they generate those on the fly?

Pass --verbose to ld (or -Wl,--verbose to GCC) when linking and it will show you the linker script it's using.

Still haven't figured out how to inject these to their makefiles, but did use the method to look at the default one when no linker script is given to ld.

It is a lot more complex than I imagined

[xeyes]

Might be worth investing in some unit tests here to make sure your APIs follow the spec.

Good point. It is a bit tricky as when I write tests, I know and expect my return values, so the tests would test for those known values (like, it would believe that lseek () should return 0 on success).

I wonder if there's some existing tests that can be adapted (like, by providing syscalls wrappers like the newlib ones so they can be built and run on top of any kernel)?

Might be a good project as it can be valuable for everyone making a kernel and many can also submit their tests to it.