kernel link problem

[jicama]

I'm using djgpp develop os, program a.c and b.c visit address &proc[ 0 ], obtain two diffent values, a.c is 0x15a4f0, b.c is 0x15a4ac, I'm delete all .o files, and make it again, values stil not changed. :-[

[durand]

Are a.c and b.c different programs in two different binaries?

&proc[ 0 ] points to the address of the first element in proc. And it makes sense that they would be different in two different programs. It seems right because it's just the location of proc. Maybe you should be printing the value "proc[ 0 ]"?

Are a.c and b.c part of the kernel (or one program) and is there only one declaration of proc[]? ( Then it's strange. )

[edit by candy] code was screwed up [/edit]

[Pype.Clicker]

chances are that you're declaring two different proc[] that are local to the object file.

The proper way to have one data structure seen by multiple object file is to declare it in *one* source file and to declare it extern in other source files.

Or even better:

Code: Select all

// - - - 8< - - proc.h - - 8< - - - 
#ifndef __PROC_H
#define __PROC_H
struct process { ... } ;

extern struct process proc[];

struct process* initProcess(...);
#endif

// - - - 8< - - proc.c - - 8< - - - 
#include "proc.h"
#define MAX_PROCESS 32
struct process proc[MAX_PROCESS];

struct proces* initProcess(...)
{

}

// - - - 8< - - other.c - - 8< - - - 
#include "proc.h"

int foo() 
{
    struct process* me=initProcess(...);
    ...
}

[jicama]

a.c and b.c are in one binaries, I'm list code here:

Code: Select all

#define proc_addr(n)        &(proc[(n)])
#define proc_number(p)       ((p)->p_index)

int read_coff(struct filp*  fp,  proc_t *rp, unsigned  *entry)
{
???    if(proc_addr(INIT_PROC)==rp)
      printk("read_coff  proc%d address %X\n", rp->p_index, (unsigned)rp);
    else
       printk("init address %X(%X) [%d-%d] THIS AT %X(%X)\n",
       (unsigned)proc_addr(INIT_PROC), proc[INIT_PROC].magic, proc[INIT_PROC].p_index, rp->p_index,(unsigned)rp, rp->magic);
}

function call it from:(in other.c)

???rp=&proc[INIT_PROC];
???printk("init magic %x address %X\n", rp->magic, (unsigned)rp);
??????r=read_coff(fp, _rp,&e);

RIGHT RESULT IS: magic = 0xf8, proc index = 4;
proc only declaring once, I'm delete all .o files and make it again! please see the screenshot.

[Solar]

I'm list code here...

Huh? I mean... huh?

Your code snippet does not show where / how proc is defined, what a proc_t is, what INIT_PROC is defined to. We have only your word for the equality of proc and INIT_PROC across the object files, since we see neither their definition, nor are they included in the debug output.

Other than that, you did a very good job in obfuscating this code snippet, with one macro that doesn't add either clarity or briefety (equivalent to (proc + n)), one macro and two parameters that aren't used at all, and changing the sequence of the values printed in every printk().

Add (unsigned)proc and INIT_PROC to both printk() statements, and include their declarations in the code snippets. Perhaps it makes sense, then.

[jicama]

some define here:

<proc.h>
#define NR_PROC 32 /*For user peocess*/
#define NR_TASK 16 /*For kernel modules*/
#define MAX_PROCESS NR_PROC+NR_TASK
#define IDLE_PROC??????0 ///this is a kernel process
#define???INIT_PROC??????4
extern???proc_t proc[MAX_PROCESS];
???
<global.c>
#ifdef _JEB_GLOBAL_
#undef extern
#define extern
#endif
#define _JEB_GLOBAL
proc_t proc[MAX_PROCESS] = {{0,}, };

this afternoon, I'm move this code from other.c to main.c,
and it's no problem. code just was not work in other.c.

[Solar]

Let's roll it up from behind:

this afternoon, I'm move this code from other.c to main.c,
and it's no problem. code just was not work in other.c.

Don't do that. At least, not to work around a problem you have not yet identified properly. You have a bug in your code, and if you avoid it this way, it will come back later to really bite you where it hurts.

Besides, I have that nagging suspicion that you don't really know the insides and outsides of multi-source-file C coding yet...

You said you are using [tt]proc[/tt] in two different C files (a.c and b.c). Now, suddenly, you provide us with a C file (global.c) and a header (proc.h). While blissfully avoiding to tell us where / when your header is included in regards to your earlier examples, and what files those earlier examples were in (really a.c and b.c?).

And what are you doing there, undef'ing "extern" and then defining it to nothing? "extern" is the keyword that is supposed to make the whole thing work! Tampering with keywords is bad karma!

And when declaring an [tt]extern[/tt] array, you don't give a size. So, since your compiler didn't yell bloody murder at your [tt]extern proc_t proc[ MAX_PROCESS ][/tt], I guess your undef'ing of [tt]extern[/tt] has completely borked your [tt]proc[/tt] declarations. The initialization of proc also looks smelly, but as I don't have a GCC ATM to check things I'll give it the benefit of doubt.

[Pype.Clicker]

some define here:

Code: Select all

#undef extern
#define extern

*cough* *gasp* *gargl*

[tt]
X x
( )-
U
[/tt]

[Pype.Clicker]

more constructively, what about rebuilding those files with [tt]-Wall[/tt] and studying warnings output with care ??

a non-extern declaration can be co-hosted with an extern declaration in the same file ...