Strange compilation problem

[aladdin]

@beyond infinity : a macro is called at the and of each service (mem-manager, ps-manager ...etc), this macro add a poiter to an initialisation routine to that service in a global table, then the kernel will call all initialisation routines (pointers to functions).
I tried to disassemble my binary, but this didn't help me figure the problem
>:(

and btw : It's only 3720 posts til I reach the 4000 posts

[Solar]

While we're at it, ----this---- is the changelog for ld... and if either a GCC or ld version update "broke" your code, it was broken to start with, as it can be reasonably expected that all hell would break lose in the Linux camp if a new GCC / ld would break legal code...

[distantvoices]

@aladdin: could you place this actual development branch of your kernel online in a tarball? I'd like to have a look at it and check if I can reproduce this behaviour at home. I'm curious about your technique, as I couldn't encounter this macro in the latest version you 've placed online currently.

Gonna see if we canna track down this damned beast of a bug.

you use make, don't you?

[Pype.Clicker]

@beyond infinity : a macro is called at the and of each service (mem-manager, ps-manager ...etc),

i've just downloaded your latest sources (16122004 or something)...
I suppose the macro is "IMOD_INTERFACE", no ?

iiuc, it generates a function that perform "add <...> on the imod_t structure

Code: Select all

include/imod/internal_mod.h:#define IMOD_INTERFACE(module, imod, name, msg, init, errorstab, error, depstab) void module(void) \
{\ 
...\
}

mm/mm.c:imod_t pagingmod;

mm/mm.c:IMOD_INTERFACE(PAGER, pagingmod, pagingname, pagingmsg, init_paging, pagingerrorstab, pagingerror, pagingdepstab);

maybe you may like to check the global imods table once you're done (e.g. make sure that global_imods[0].init == init_paging) etc.

[Pype.Clicker]

running generated image in trace-on bochs (normal bochs interrupting too fast)

i get "setup XSS ... ok"
"XOSKER32XSS ........
(screen becoming blue)
(red banner line)
D?tection du mat?riel (nb. "n?cessaire" et pas "naicessaire")
* lecteur de disquette

Code: Select all

(0).[4949217] [0x001011d9] 0008:001011d9 (unk. ctxt): cmp byte ptr ss:[ebp+0xfffffffb], al ; 3845fb
(0).[4949218] [0x001011dc] 0008:001011dc (unk. ctxt): jb 0x1011e0               ; 7202
(0).[4949219] [0x001011e0] 0008:001011e0 (unk. ctxt): mov eax, 0x0              ; b800000000
(0).[4949220] [0x001011e5] 0008:001011e5 (unk. ctxt): mov al, byte ptr ss:[ebp+0xfffffffb] ; 8a45fb
(0).[4949221] [0x001011e8] 0008:001011e8 (unk. ctxt): mov eax, dword ptr ds:[eax*4+0x10bba0] ; 8b0485a0bb1000
(0).[4949222] [0x001011ef] 0008:001011ef (unk. ctxt): call eax    

========================================================================
Bochs is exiting with the following message:
[CPU0 ] prefetch: running in bogus memory
========================================================================
00004949223i[CPU0 ] protected mode
00004949223i[CPU0 ] CS.d_b = 32 bit
00004949223i[CPU0 ] SS.d_b = 32 bit
00004949223i[CPU0 ] | EAX=3a434347  EBX=0010ead0  ECX=0000000d  EDX=000003d5
00004949223i[CPU0 ] | ESP=0009eff0  EBP=0009effc  ESI=0000fad0  EDI=00000000
00004949223i[CPU0 ] | IOPL=0 NV UP DI NG NZ AC PO CY
00004949223i[CPU0 ] | SEG selector     base    limit G D
00004949223i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
00004949223i[CPU0 ] |  DS:0010( 0002| 0|  0) 00000000 000fffff 1 1
00004949223i[CPU0 ] |  ES:0010( 0002| 0|  0) 00000000 000fffff 1 1
00004949223i[CPU0 ] |  FS:0010( 0002| 0|  0) 00000000 000fffff 1 1
00004949223i[CPU0 ] |  GS:0010( 0002| 0|  0) 00000000 000fffff 1 1
00004949223i[CPU0 ] |  SS:0010( 0002| 0|  0) 00000000 000fffff 1 1
00004949223i[CPU0 ] |  CS:0008( 0001| 0|  0) 00000000 000fffff 1 1
00004949223i[CPU0 ] | EIP=3a434347 (3a434347)
00004949223i[CPU0 ] | CR0=0x60000011 CR1=0x00000000 CR2=0x00000000
00004949223i[CPU0 ] | CR3=0x00000000 CR4=0x00000000

[distantvoices]

my bad, have downloaded the wrong binary. well, reading is an art.

Have looked into it.

What's this, the imod interface expands to void module(void){ any content }? is the linker supposed to distinguish all the public symbols overthere, all with the same name:void module(void)?

Isn't it possible to have it be either static - and export the pointer to the function in some public available struct - or just give it a slightly different name?

[Pype.Clicker]

well, reading is an art.
is the linker supposed to distinguish all the public symbols overthere, all with the same name:void module(void)?

Teh Art of reading joo h4v3 n07 y37 m4573r3d, j00ng padawan

"module" is the name of 1st argument for the macro. It will define "PAGER()" function, "MM()" function etc.

What seems strange to me is the usefulness of a table which require the init sequence (in init_internal_modules) to be adjusted so tht the table is created in the correct order at runtime (well, well).

Error tracked somewhere around

Code: Select all

init_internal_modules();        /*Initialisation des modules internes*/
   XOSmsgln("Chargement des modules internes");
   star();
   for(m=0; m<get_last_idx(); m++)   /*Creation de la liste des modules internes*/
   {
           if (k_imod_tab[m])
       (* k_imod_tab[m])();
      printk("|");
   }

And if i may say, that (*k_imod_tab[m]) thing is *weiiird* to me ...

Code: Select all

include/imod/init_imod.h:#define ADD_INTERNAL_MODULE(module) k_imod_tab[k_imod_idx++]=(&module)

include/imod/init_imod.h:void (* k_imod_tab[NB_IMODS])();
kernel32/imod/init_imod.c:ADD_INTERNAL_MODULE(PAGER);
kernel32/imod/init_imod.c:ADD_INTERNAL_MODULE(XOSMM);
kernel32/imod/init_imod.c:ADD_INTERNAL_MODULE(GDT);
...

[Pype.Clicker]

compiled with GCC 2.95.3

{
(* k_imod_tab[m])();
1f6: 31 c0 xor %eax,%eax
1f8: 8a 45 ff mov 0xffffffff(%ebp),%al
1fb: 8d 14 85 00 00 00 00 lea 0x0(,%eax,4),%edx
202: b8 00 00 00 00 mov $0x0,%eax
203: R_386_32 k_imod_tab
207: 8b 1c 02 mov (%edx,%eax,1),%ebx
20a: ff d3 call *%ebx
printk("|");

compiled with gcc 3.3

{
(* k_imod_tab[m])();
1e0: b8 00 00 00 00 mov $0x0,%eax
1e5: 8a 45 fb mov 0xfffffffb(%ebp),%al
1e8: 8b 04 85 00 00 00 00 mov 0x0(,%eax,4),%eax
1eb: R_386_32 k_imod_tab
1ef: ff d0 call *%eax
printk("|");

except 2.95.3 code is **way** more ugly, both code do the basic same stuff ...

once linked, we have

void init_internal_modules()
{
1016a4: 55 push %ebp
1016a5: 89 e5 mov %esp,%ebp

/*ADD_INTERNAL_MODULE(VOID);*/
ADD_INTERNAL_MODULE(PAGER);
1016a7: a0 d4 b7 10 00 mov 0x10b7d4,%al
1016ac: 25 ff 00 00 00 and $0xff,%eax
1016b1: c7 04 85 a0 bb 10 00 movl $0x10773b,0x10bba0(,%eax,4)
1016b8: 3b 77 10 00

...
{
(* k_imod_tab[m])();
1011e0: b8 00 00 00 00 mov $0x0,%eax
1011e5: 8a 45 fb mov 0xfffffffb(%ebp),%al
1011e8: 8b 04 85 a0 bb 10 00 mov 0x10bba0(,%eax,4),%eax
1011ef: ff d0 call *%eax
printk("|");

0010773b <PAGER>:




/* Interface du module Interne */
IMOD_INTERFACE(PAGER, pagingmod, pagingname, pagingmsg, init_paging, pagingerror
stab, pagingerror, pagingdepstab);
10773b: 55 push %ebp
10773c: 89 e5 mov %esp,%ebp
10773e: 57 push %edi
10773f: 56 push %esi
107740: 83 ec 08 sub $0x8,%esp
107743: 83 ec 08 sub $0x8,%esp
107746: e8 ad 9c ff ff call 1013f8 <imod_get_next_idx>

[Pype.Clicker]

it looks to me that "something" has trashed your table :

<bochs:7> x /256xb 0x10bba0
[bochs]:
0x0010bba0 <bogus+ 0>: 0x47 0x43 0x43 0x3a 0x20 0x28 0x47 0x4e
0x0010bba8 <bogus+ 8>: 0x55 0x29 0x20 0x33 0x2e 0x33 0x20 0x32
0x0010bbb0 <bogus+ 16>: 0x30 0x30 0x33 0x30 0x32 0x32 0x36 0x20
0x0010bbb8 <bogus+ 24>: 0x28 0x70 0x72 0x65 0x72 0x65 0x6c 0x65
0x0010bbc0 <bogus+ 32>: 0x61 0x73 0x65 0x29 0x20 0x28 0x53 0x75
0x0010bbc8 <bogus+ 40>: 0x53 0x45 0x20 0x4c 0x69 0x6e 0x75 0x78
0x0010bbd0 <bogus+ 48>: 0x29 0x00 0x00 0x47 0x43 0x43 0x3a 0x20

...

Something that says

0x0010bba0 <bogus+ 0>: G C C : ( G N
0x0010bba8 <bogus+ 8>: U ) 3 . 3 2
0x0010bbb0 <bogus+ 16>: 0 0 3 0 2 2 6
0x0010bbb8 <bogus+ 24>: ( p r e r e l e
0x0010bbc0 <bogus+ 32>: a s e ) ( S u
0x0010bbc8 <bogus+ 40>: S E L i n u x
0x0010bbd0 <bogus+ 48>: ) \0 \0 G C C :
0x0010bbd8 <bogus+ 56>: ( G N U ) 3 .
0x0010bbe0 <bogus+ 64>: 3 2 0 0 3 0 2
0x0010bbe8 <bogus+ 72>: 2 6 ( p r e r
0x0010bbf0 <bogus+ 80>: e l e a s e )
0x0010bbf8 <bogus+ 88>: ( S u S E L i
0x0010bc00 <bogus+ 96>: n u x ) \0 \0 G C
0x0010bc08 <bogus+ 104>: C : ( G N U )
0x0010bc10 <bogus+ 112>: 3 . 3 2 0 0
0x0010bc18 <bogus+ 120>: 3 0 2 2 6 ( p
0x0010bc20 <bogus+ 128>: r e r e l e a s
0x0010bc28 <bogus+ 136>: e ) ( S u S E
0x0010bc30 <bogus+ 144>: L i n u x ) \0
0x0010bc38 <bogus+ 152>: \0 G C C : ( G
0x0010bc40 <bogus+ 160>: N U ) 3 . 3
0x0010bc48 <bogus+ 168>: 2 0 0 3 0 2 2 6
0x0010bc50 <bogus+ 176>: ( p r e r e l

So it actually looks like your ".bss" is not full of zeroes but instead contains .comments or something alike ... the error is likely to be somewhere in your linker script. You may wish to ensure your loader is properly wiping out the BSS aswell ...

<explanation>
Somewhere in your .bss, you have a byte that tells how much entries are valid in the table. If (by chance) this byte is 0, everything runs as expected.
The new version of GCC/LD seems to write a non-zero (for instance because it better packs strings, with less padding or something alike), which means you start filling your table at offset 0x30 (in my case) ... But you still read it from 0x0 !

GCC is not to blame. It still produced a valid ELF file ... Your loader is the one to blame, having wrongly assumed that the .bss section would have been full of zeroes where zeroes are needed.
</explanation>

<suggestion>
Put a memset(edata, 0, ebss-edata); early in your code and see your troubles flying away
</suggestion>

[aladdin]

@Pype.Clicker

Code: Select all

#define ADD_IMOD_HEAD(module) void module(void)
define ADD_INTERNAL_MODULE(module) k_imod_tab[k_imod_idx++]=(&module)

ADD_IMOD_HEAD will add a header.
ADD_INTERNAL_MODULE will add a pointer to module routine.

Code: Select all

void (* k_imod_tab[NB_IMODS])();

k_imod_tab is a table of function pointers.

Code: Select all

init_internal_modules();        /*Initialisation des modules internes*/
   XOSmsgln("Chargement des modules internes");
   star();
   for(m=0; m<get_last_idx(); m++)   /*Creation de la liste des modules internes*/
   {
          if (k_imod_tab[m])
     (* k_imod_tab[m])();   /****** HERE ********/
     printk("|");
   }

here i'm doing a loop to call all modules added to k_imod_tab

i know that calling (* k_imod_tab[m])() is the cause of my problem, but i dont know why since it was working before.

is there another way to define a table of function pointers ??

[Pype.Clicker]

@Pype.Clicker
is there another way to define a table of function pointers ??

Well, there's a nicer way, actually:

Code: Select all

typedef void (*module_prepare_fct)(void);

module_prepare_fct prepare_table[MAX];

module_prepare[i]();

Btw, your preparation code seems overcomplicated to me: you're filling a table of functions that will fill structures and register them...

Why not simply *initialize* those structures statically (imho, you may do it)

Code: Select all

struct imod pager_module={
    name:"pager",
    init: pager_init_fct,
    ...
};

...
extern struct imod pager_module;
extern struct imod xosmm_module;
...
all_internal_modules[]={
   &pager_module,
   &xosmm_module,
   ...,
   NULL,
};

for (i=0; all_internal_modules[i]; i++) {
    kprint("initializing %s",all_internal_modules[i]->name);
    all_internal_modules[i]->init();
}

[aladdin]

I did some tests and now i'm almost sure that my problem comes from my ld script.
in my kernel makefile i replaced this line

Code: Select all

       ld $^ -T kernel.ld -Map kernel.map -o xosker32.xss

with this one :

Code: Select all

        ld --oformat binary -Ttext 100000 $^ -o xosker32.xss

so the generated binary is not in elf format but a flat binary

and in the second stage of my boot loader, i jump to 0x100000 instead of 0x101000

and everything work fine....

now, can someone tell me what's wrong with my ld script, i want to create an elf kernel with all flat binary sections in the same order
here is my actual ld script

Code: Select all

OUTPUT_FORMAT("elf32-i386")
ENTRY(_start)
SECTIONS {
  . = 0x101000;

  .text : {
    *(.text)
    _etext = .;
    etext = _etext;
  }
  .rodata : {
    *(.rodata)
    _erodata = .;
    erodata = _erodata;
  }

  .data : {
    *(.data)
    _edata = .;
    edata = _edata;
  }
  .bss : {
    *(.bss)
    _ebss = .;
    ebss = _ebss;
  }
}

[Pype.Clicker]

well, imho there's nothing wrong "per se" in the script, simply that it will keep parts in ELF mode ... my knowledge of ELF ABI doesn't tell why this is so, but it obviously *is* so ...

a second pass on .xss with objcopy could help removing unwanted sections, etc.

I don't know too much whether -oformat binary will create a BSS section full of zeroes or not, but ELF will certainly not do it. Instead, it relies on the loader to put zeroes where they're expected to be.

On an emulator, zeroes will be there if nothing else was written, but on real hardware, this will *certainly not* be the case.
Honnestly, i strongly encourage you to wipe out your BSS section either in the bootloader or in the earliest stages of your kernel ...

[aladdin]

Btw, your preparation code seems overcomplicated to me: you're filling a table of functions that will fill structures and register them...

In the future, i want to read an external file which will describe what services will be loaded.
my kernel is actually monolithic but i'm working on a dynamic linking routine so that most services will become external modules.
i want to keep the kernel as small as possible, and want to be able to unload/reload a service on the fly : for example instead of havin one scheduler that use SCHED_FIFO, SCHED_RR and SCHED_OTHERS, i'll have a separate scheduler for each policy, and i want to be able to load one or all schedulers, and when a scheduler is no more used i want ot be able to unload it (this is not a very good example but it illustrate what i'm working on)

[distantvoices]

pfau ... man, I'm dropping dead ashamed and bedazzled. *smirk* Have completely forgotten how those macros expand. :-[ Well ... that comes from reading and having to do work at all the same time - and not obeying to the rule of zen - to fully concentrate on one thing at a time.

regarding "young padawan" ... Maaaaan, I'm of 1975 vintage. *rofl* I'm starting my thirties in this march. *chuckle*