"File format not recognized" linking PSF object

[zak24]

Hello,

I recently started taking a shot at OS development, and so far everything's more or less come along well. I managed to get VESA working more recently, but I've run into some problems with trying to link my PSF object file when trying to get PSF working. When I run the ./iso.sh script, I get an error in my kernel directory's Makefile:

Code: Select all

i686-elf-gcc --sysroot=/home/zak/pb/root/sysroot -isystem=/usr/include -T arch/i386/linker.ld -o pb.kernel -O2 -g -ffreestanding -Wall -Wextra    arch/i386/Lat2-Terminus16.o arch/i386/crti.o arch/i386/crtbegin.o arch/i386/boot.o arch/i386/tty.o  kernel/kernel.o   -nostdlib -lk -lgcc  arch/i386/crtend.o arch/i386/crtn.o 
arch/i386/Lat2-Terminus16.o: file not recognized: file format not recognized
collect2: error: ld returned 1 exit status
Makefile:58: recipe for target 'pb.kernel' failed
make: *** [pb.kernel] Error 1

I've done a bit of research on this particular error, but in those cases it seems to involve attempting to compile C header files. Nothing of the sort is going on here, so it's made me wonder if something went wrong while running objcopy. Then again, it's completely possible that I've made a careless mistake here as well.

I'll show the relevant parts of my Makefile (note: it's not heavily modified from the Meaty Skeleton kernel Makefile yet). Let me know if anything else may be needed to resolve the issue.

Code: Select all

KERNEL_OBJS=\
$(KERNEL_ARCH_OBJS) \
kernel/kernel.o \

OBJS=\
$(ARCHDIR)/Lat2-Terminus16.o \
$(ARCHDIR)/crti.o \
$(ARCHDIR)/crtbegin.o \
$(KERNEL_OBJS) \
$(ARCHDIR)/crtend.o \
$(ARCHDIR)/crtn.o \

LINK_LIST=\
$(LDFLAGS) \
$(ARCHDIR)/Lat2-Terminus16.o \
$(ARCHDIR)/crti.o \
$(ARCHDIR)/crtbegin.o \
$(KERNEL_OBJS) \
$(LIBS) \
$(ARCHDIR)/crtend.o \
$(ARCHDIR)/crtn.o \

.PHONY: all clean install install-headers install-kernel
.SUFFIXES: .o .c .S

all: pb.kernel

pb.kernel: $(OBJS) $(ARCHDIR)/linker.ld
	$(CC) -T $(ARCHDIR)/linker.ld -o $@ $(CFLAGS) $(LINK_LIST)
	grub-file --is-x86-multiboot pb.kernel

$(ARCHDIR)/crtbegin.o $(ARCHDIR)/crtend.o:
	OBJ=`$(CC) $(CFLAGS) $(LDFLAGS) -print-file-name=$(@F)` && cp "$$OBJ" $@

$(ARCHDIR)/Lat2-Terminus16.o: $(ARCHDIR)/Lat2-Terminus16.psf
	objcopy -O elf64-x86-64 -B i386 -I binary $(ARCHDIR)/Lat2-Terminus16.psf $(ARCHDIR)/Lat2-Terminus16.o

[iansjack]

Why have you made Lat2-Terminus16.o a 64-bit object file, and then try to link it with 32-bit code?

[zak24]

Why have you made Lat2-Terminus16.o a 64-bit object file, and then try to link it with 32-bit code?

I changed "elf64-x86_64" to "elf32-i386" and it seemed to link properly.

However, when casting the pointer to the font start symbol in Lat2-Terminus16.o to a PSF font structure, the magic number in the structure does not match the PSF font magic number. Just as expected, the function to place a character also does nothing. Although I don't see how it would, is there anything in this function which may cause this to occur? (This too is heavily rooted in the wiki page on PSF)

Code: Select all

extern char _binary_arch_i386_Lat2_Terminus16_psf_start;
void ttyplace(unsigned short int ch, int chx, int chy, color_t color, multiboot_info_t* mbi)
{
    uint8_t* fb = (uint8_t*) (mbi -> framebuffer_addr);
    uint32_t pitch = (uint32_t) (mbi -> framebuffer_pitch);

    psf_t* font = (psf_t*) &_binary_arch_i386_Lat2_Terminus16_psf_start;
    int bpl = ((font -> width) + 7) / 8;

    unsigned char* glyph = (unsigned char*) &_binary_arch_i386_Lat2_Terminus16_psf_start + (font -> headersize) + ((ch > 0 && ch < (font -> numglyph) ? ch : 0) * (font -> bytesperglyph));

    int offset = (chy * (font -> height) * pitch) + (chx * ((font -> width) + 1) * sizeof(pixel_t));

    int line, mask;

    for (int y = 0; y < font -> height; y++)
    {
        line = offset;
        mask = 1 << ((font -> width) - 1);

        for (int x = 0; x < font -> width; x++)
        {
            *((pixel_t*) (fb + line)) = (*((unsigned int*) glyph) & mask) ? color.fg : color.bg;
            mask >>= 1;
            line += sizeof(pixel_t);
        }

        glyph += bpl;
        offset += pitch;
    }
}

[iansjack]

Did your .psf file come from a 32-bit OS?

[zak24]

My PSF file came from a 64-bit OS on which I'm developing. Would I be correct in assuming that a 32-bit PSF should be used for this? Moreover, where could I obtain such a file other than from a 32-bit Linux distro?

Regardless of whether that is the case, I suppose I should anticipate such architecture incompatibility issues in the future.

[iansjack]

I honestly don't know the answer to that as I'm not familiar enough with .psf files (although I wouldn't have thought that a data file like this would depend on that factor). But mixing files between 32- and 64-bit distributions is not generally a good idea. If you're making a 32-bit OS I would advise using a 32-bit cross-compiler and toolset and use binary files from a 32-bit distribution. You could always install a 32-bit Linux in a Virtual Machine to get such files.

Your best bet is to hope that the author of the page you are following (bzt) can answer your question. Perhaps drop him a PM.

[zak24]

Although it may take a bit of time, I’ll try installing a 32-bit distribution of my host OS on a virtual machine at first opportunity and use the PSF from there. I’ll be sure to post an update when I have results.

Your best bet is to hope that the author of the page you are following (bzt) can answer your question. Perhaps drop him a PM.

I’ll PM the author if using a PSF file from a 32-bit OS fails to work.

[zak24]

It turns out there was an issue with the PSF file itself. All of the PSF files I tested, including the one I used from the 32-bit VM, had the same seemingly faulty magic signature of 0x10020436. I went through with sending bzt a PM about the issue, and he sent an example which contained a PSF file which worked correctly. Thanks for your help as well as the suggestion to PM him!

[iansjack]

Ah! Looks like your original .psf files are version 1, whereas the Wiki code assumes version 2.

Have a look at this document if you want to modify your code to handle either type: https://www.win.tue.nl/~aeb/linux/kbd/f ... ats-1.html