Feature request: support making a binary blob

[ftphikari]

With ld you can do this:

ld -r -b binary -o obj.o file.jpg

This command will make an object file out of a common binary file (image/font/whatever). Here is an example of what it might look like:

$ objdump -t dejavu_sans.o

dejavu_sans.o:     file format elf64-x86-64

SYMBOL TABLE:
0000000000000000 l    d  .data	0000000000000000 .data
0000000000000000 g       .data	0000000000000000 _binary_res_DejaVuSans_ttf_start
00000000000b8d54 g       .data	0000000000000000 _binary_res_DejaVuSans_ttf_end
00000000000b8d54 g       *ABS*	0000000000000000 _binary_res_DejaVuSans_ttf_size

This can then be imported into source code like this:

// import binary blob
extern const unsigned char _binary_res_DejaVuSans_ttf_start[];
extern const unsigned char _binary_res_DejaVuSans_ttf_end[];

It would be great if mold supported this feature, but if it is out of the scope I wouldn't mind. :)

[rui314]

mold does not support -b binary, but you can do the same by objcopy -I binary -O elf64-little file.jpg obj.o.

So I don't think we need to support that feature.

[ftphikari]

Indeed you are right, but out of curiosity, what is elf64-little format?

[rui314]

ELF is the name of the object file format used on Unix. 64 means its 64-bit version (as opposed to 32-bit). little means it is in little-endian as opposed to big-endian. So, all in all, elf64-little just means the object file format that we use daily.

[ftphikari]

I mean, what is the difference between elf64-x86-64 and elf64-little?

[rui314]

Ah, maybe elf-x86-64 is better than elf64-little. The latter leaves the machine field in the elf header blank, but it may not be desirable. At least it's a bit odd to leave it blank.

[ftphikari]

Ok, thank you, you are very kind, God bless! :)

[Alcaro]

One advantage of having this feature in the linker is that the linker knows your output format, so you can say ld -r -b binary -o obj.o file.jpg on anything from x86_64 Linux to 32bit Android.

It's a fairly small advantage. Your choice if it's worth caring about.

[rui314]

I found that you can specify default instead of elf-x86-64 (or whatever), so you can write it in a target-independent way as objcopy -I binary -O default input-file output-file.o.

[satmandu]

This appears to break builds of glib on x86_64:

FAILED: gio/tests/test_resources.o
/usr/local/bin/ld -z noexecstack -r -b binary gio/tests/test5.gresource -o gio/tests/test_resources.o
mold: fatal: mold does not support `-b binary`. If you want to convert a binary file into an object file, use `objcopy -I binary -O default <input-file> <output-file.o>` instead.
[837/1350] Compiling C object gio/tests/libresourceplugin.so.p/resourceplugin.c.o
[838/1350] Compiling C object gio/tests/slow-connect-preload.so.p/slow-connect-preload.c.o
[839/1350] Generating symbol file gio/tests/gdbus-object-manager-example/libgdbus-example-objectmanager.so.p/libgdbus-example-objectmanager.so.symbols
[840/1350] Compiling C object gio/tests/defaultvalue.p/defaultvalue.c.o

Is there a workaround for this when building with ninja?

[satmandu]

@rui314 Could we reopen this issue?

[rui314]

Filed a bug to GLib to ask to remove the use of ld -r.

https://gitlab.gnome.org/GNOME/glib/-/issues/2768

[satmandu]

This appears to be the offending meson section there: https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/tests/meson.build#L821

    # Create object file containing resource data
    test_resources_binary = custom_target('test_resources.o',
      input : test_gresource_binary,
      output : 'test_resources.o',
      command : [ld,
                 '-z', 'noexecstack',
                 '-r',
                 '-b','binary',
                 '@INPUT@',
                 '-o','@OUTPUT@'])

[apprehensions]

https://github.com/NVIDIA/nvidia-settings/blob/76b10f1b028cdccfa1b524955d9b8ca719c206c6/utils.mk#L568-L577

[rui314]

@wael444 Can you explain a little bit more about what that link is?

[apprehensions]

Links to lines 568 to 577:

define READ_ONLY_OBJECT_FROM_FILE_RULE
  $$(OUTPUTDIR)/$$(notdir $(1)).o: $(1)
	$(at_if_quiet)$$(MKDIR) $$(OUTPUTDIR)
	$(at_if_quiet)cd $$(dir $(1)); \
	$$(call quiet_cmd_no_at,LD) -r -z noexecstack --format=binary \
	    $$(notdir $(1)) -o $$(OUTPUTDIR_ABSOLUTE)/$$(notdir $$@)
	$$(call quiet_cmd,OBJCOPY) \
	    --rename-section .data=.rodata,contents,alloc,load,data,readonly \
	    $$@
endef

[rui314]

OK so you are pointing out that there's a usage of -r there too?