OSDev.org

Posted: **Tue Jul 03, 2012 9:22 pm**

Greetings,

I've got something of an odd problem with my kernel image.

I was writing a register dump function to dump the register contents when a page fault occurs, using the registers_t struct from the James Molloy tutorial series. I've written my own hack up of vsprintf for handling the formatting, and thus dump_registers() looks like this:

Code: Select all

void dump_registers(registers_t regs)
{
  vsprintf(print_buffer, "\neax: %08x\tebx: %08x\tecx: %08x\tedx: %08x\n", regs.eax, regs.ebx, regs.ecx, regs.edx);
  console_putstr(DFL_ATTRIB, print_buffer);
  vsprintf(print_buffer, "edi: %08x\tesi: %08x\tebp: %08x\tesp: %08x\n", regs.edi, regs.esi, regs.ebp, regs.esp);
  console_putstr(DFL_ATTRIB, print_buffer);
}

(print_buffer is a global symbol pointing at 512 bytes in .bss)

This works fine. But if i add one more call to vsprintf, Grub fails to load the entire kernel image, citing error 13.

The ELF header of the image itself looks fine when examined with objdump, So I can't see anything obviously wrong, perhaps an alignment issue or similar. I tried a few other things as well and noticed that
any additional function calls from within dump_registers to either vsprintf or console_putstr sets off the corruption issue.

I'm at a loss to explain why. Any ideas?

Posted: **Tue Jul 03, 2012 9:27 pm**

Can you post the output of at least "readelf -l" on both versions of the kernel binary?

Posted: **Tue Jul 03, 2012 9:44 pm**

Certainly. Bad image follows good:

Code: Select all

duran@tyrion ~/src/aspidistrOS/src [master *]
± % readelf -l aspidistros                                                                                                        !4702

Elf file type is EXEC (Executable file)
Entry point 0x100f5c
There are 3 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0xc0100000 0x00100000 0x024f0 0x024f0 R E 0x1000
  LOAD           0x004000 0xc0103000 0x00103000 0x04050 0x08ee4 RW  0x1000
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

 Section to Segment mapping:
  Segment Sections...
   00     .text .eh_frame 
   01     .data .bss 
   02     

duran@tyrion ~/src/aspidistrOS/src [master *]
± % readelf -l aspidistros-bad                                                                                                    !4703

Elf file type is EXEC (Executable file)
Entry point 0x1010ec
There are 3 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0xc0100000 0x00100000 0x02680 0x02680 R E 0x1000
  LOAD           0x004000 0xc0103000 0x00103000 0x04050 0x08ee4 RW  0x1000
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

 Section to Segment mapping:
  Segment Sections...
   00     .text .eh_frame 
   01     .data .bss 
   02

Posted: **Tue Jul 03, 2012 9:58 pm**

Quick update: after playing with readelf -a, I changed my linker script so that the arguments passed to ld are explicit, rather than *.o. Doing this I made a point to put common.o (the file containing the dump_registers() routine) at the end.

Now I can call console_putstr as many times as i like from within that function and it just works. Looking more like an alignment issue, but i'm not sure why this is the case.

Posted: **Tue Jul 03, 2012 11:18 pm**

In which section do the constant strings end up? I don't see any .rodata?

Posted: **Wed Jul 04, 2012 1:27 am**

This sounds like a typical case of the multiboot header moving too far from the start of the file..

Posted: **Wed Jul 04, 2012 3:39 pm**

jbemmel wrote:In which section do the constant strings end up? I don't see any .rodata?

Excellent question. Neither do I. There are allowances made for .rodata in the linker script, but perhaps GCC isn't putting out any .rodata to link? How can I check.

Posted: **Wed Jul 04, 2012 4:04 pm**

Try objdump -t <object file>

OSDev.org

too many function calls corrupts the kernel image

too many function calls corrupts the kernel image

Re: too many function calls corrupts the kernel image

Re: too many function calls corrupts the kernel image

Re: too many function calls corrupts the kernel image

Re: too many function calls corrupts the kernel image

Re: too many function calls corrupts the kernel image

Re: too many function calls corrupts the kernel image

Re: too many function calls corrupts the kernel image