gcc putting me in a lose/lose situation

[Freanan]

Please help me with this problem:

When i try to do some % and / operations with integers of the long long type, ld tells me about undefined reference to __umoddi3 and ___udivdi3.
But i do need to use long long int in that special case, because otherwise my code won't work (it's about primitive math operations for doing integer output. When i want to output memory map data it crashes when i do not use 64 bit integers).

Is there a way to turn 64-bit integer support on without compiling in the standard lib?
Or do i have to work with unsigned long and split the number in two parts..?

Thanks in advance!

[fraserjgordon]

I know this isn't ideal, but you could print the 64-bit number as two 32-bit numbers that have been joined together, e.g.

Code: Select all

write(strcat( string(high_dword(int64)), string(low_dword(int_64)) ));

This solution is specific to the printing problem, but is useless for the general case of division (obviously).

[Freanan]

I might do something like that when everything else fails (actually i don't think that i need 64 bit mod and div stuff anywhere else...).

I could also write special mod and div funcs for 64 bit integers and use them instead of the standard operators, as i read that on most platforms the operators only work through special functions that are included with the stdlib.

But both things are not really satisfactory.
I would preffer to somehow tell gcc to include those two functions without the rest of the libs.

[JoeKayzA]

Hi!

Maybe this page could help you providing your own implementation for these functions....

http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gccint/Integer-library-routines.html

There you'll find at least the declarations that gcc expects.

cheers Joe

[Freanan]

Thanks!
In the meanwhile i tried to just output the data in a split form ie
"low part: xxx; high part: xxx"
using the 32-bit version of my integer output function for the split parts.
But even now integer overflows can occur and ruin it all - which actually is happening.
So i will probably really need to implement the functions myself.
But i will try to find a "workaround" first, because i think division of large integers is a rather difficult thing actually (i was marginally interrested in arbitrary precision arithmetics once - it was easy to figure out addition and so on, but i never found out how to do division).

[Pype.Clicker]

those functions are usually described in libgcc.a ... just locate it (e.g. /usr/lib/gcc-lib/i486-suse-linux/2.95.3/libgcc.a) and link your kernel against it. libgcc.a is made so that only functions you need will be added to your kernel (in this case, you should only have an overhead of about 512 bytes even though the library is 860K ...

also, iirc, the license of GCC states that linking against libgcc.a do not alter the licensing of your produced code in any way (otherwise, you couldn't even compile a proprietary project with gcc ...)

[Freanan]

That's very good - thank you!
So i will just add /<path>/libgcc.a
to the dependencies and to the ld-line in my makefile and that's it?
I will try it as soon as i am at home.

[Freanan]

Linking it in makes my kernel unbootable.
Buchs returns "error 13: unknown file format" (or somethjng similiar).
Also, the linker puts heaps of 0s at the beginning of my file instead of the multiboot info.

The same thing happened once in the beginning of my recent development (but without librarys being compiled in) and back then i had to add .rodata to the text section in the linker script.

Maybe my problem could be solved by specifying something similiar?

[Pype.Clicker]

if 'loads of zeroes" means >64K of them, then probably you forgot some section in the linker script. Since it doesn't have the proper base address (1MB), it uses the default base address (0) and generates a file >1MB that has padding between those two sections ...

Check out the section list in the newly generated file and in your linker script (e.g. you might miss ".rodata.32" or something) and update accordingly.

[Freanan]

Hm, i did not have any rodata.32 section (just rodata), but adding it did not change anything..
But it is still very probable that one is missing in the linker script.
Are there any special section names only used in libs, which would have brought a new section to my kernel, which ld put in the beginning?

I have searched for a list with all existing sections on the web, but could not find any information about them.

Anyway, this is my linker script so far:

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(start)
phys = 0x00100000;
SECTIONS
{
  .text phys : AT(phys) {
    code = .;
    *(.text)
    *(.rodata*)
    *(.rodata.32*)
    . = ALIGN(4096);
  }
  .data : AT(phys + (data - code))
  {
    data = .;
    *(.data)
    . = ALIGN(4096);
  }
  .bss : AT(phys + (bss - code))
  {
    bss = .;
    *(.bss)
    . = ALIGN(4096);
  }
  end = .;
}

[Pype.Clicker]

hmm ... the .rodata* should have covered .rodata32 if there were anything like that.

Looking at "objdump -x libgcc.a" reveals nothing odd here ... maybe your output will give more clue.

Maybe you could try to link without the "output(binary)" statement and objdump the resulting ELF file to see what sections it contains ...

[Freanan]

Okay, that's the output of objdump -h:

Code: Select all

bin/kernel.bin:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00003000  00100000  00100000  00001000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00001000  00103000  00103000  00004000  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00006884  00104000  00104000  00005000  2**5
                  ALLOC
  3 .note.GNU-stack 00000000  00000000  00000000  00005000  2**0
                  CONTENTS, READONLY
  4 .comment      00000485  00000000  00000000  00005000  2**0
                  CONTENTS, READONLY
  5 .eh_frame     00000058  00000488  00000488  00000488  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .debug_aranges 00000040  00000000  00000000  00005485  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_pubnames 00000040  00000000  00000000  000054c5  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_info   00006d1c  00000000  00000000  00005505  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_abbrev 0000057a  00000000  00000000  0000c221  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_line   00000622  00000000  00000000  0000c79b  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_frame  00000068  00000000  00000000  0000cdc0  2**2
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_str    00004a32  00000000  00000000  0000ce28  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_ranges 00000030  00000000  00000000  0001185a  2**0
                  CONTENTS, READONLY, DEBUGGING

But it looks, as if .text was correctly put at the beginning.
But the elf-file also differs from the binary file - there are far less 0's in the beginning...

When i tried to load the elf-kernel with grub, just out of curiosity, it replied with "selected item cannot fit into memory".

[Pype.Clicker]

that's all normal. Look at the "VMA" (virtual memory address) of the different sections: .text, .data and .bss all have virtual address above 1MB. However,

5 .eh_frame 00000058 00000488 00000488 00000488 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA

is likely to be what causes you trouble. I can't tell for sure what it contains (probably exception handler stuff) and i'd suggest you dismiss it using proper section (/DISCARD/ iirc). If it causes trouble, then you might want to include it along with .text or whatever.

"elf file isn't 1MB": normal because what causes trouble is the fact you cannot say in a binary file "this bits are going to be 1MB further", so you actually have to place padding instead. ELF files, instead, have headers saying "okay, bits x..x+n will be loaded at y while bits z..z+m will be loaded at y'."

"GRUB complains about kernel not fitting memory": normal too. GRUB will try to use the 1MB..AS_HIGH_AS_IT_CAN to load your kernel. Each section will go where specified. When it try to loads the ".eh_*" section, it discovers that the requested load address (e.g. 488 or something) doesn't fall in the range [1MB...[ so it complains.

Hope that helps.

Just out of curiosity, if you could post the content (e.g. a hexdump) of that ".eh_..." section ...

[Freanan]

Thank you!
That solved it and everything is working as it should now (so i can now go about debugging my physical allocation and freeing stuff ;D ).

Of course i would post the section..
Just that i don't know how, having used objdump the first time today and knowing no other similiar tools.
objdump -s eh_frame bin/kernel.bin seems to dump the whole file...

[Pype.Clicker]

hehe ... objdump is _ze_ reference tool when toying with object files ... you can inspect headers, disassemble code (even mixing disassembled code and source code), inspect symbols/relocation tables ...