Autor Thema: Userspace und Strings  (Gelesen 2529 mal)

Hunter

  • Beiträge: 28
    • Profil anzeigen
Gespeichert
« am: 18. July 2009, 09:41 »
Hallo,

ich habe folgendes Problem:

Wenn ich in einem Userprogramm einen String verwenden möchte tritt ein seltsames Problem auf. Ich versuche die Situation mithilfe eines Codeparts zu erklären:

Ich möchte beispielsweise ein Fenster in meiner GUI erstellen. Dies funktioniert auch nur wird der Titel des Fensters (String) nicht an den Kernel übergeben. Der Codeteil ist ein einfaches Userprogramm welches vom Kernel als normaler Task ausgeführt wird.

char titel[50] = "Hallo";

void main( void )
{
U_WINDOW window_par;
unsigned int window_id;

mem_cpy( titel, window_par.titel,50 );
window_par.x = 10;
window_par.y = 10;
window_par.w = 210;
window_par.h = 230;

window_id = u_gui_window_create( (U_WINDOW *)&window_par );

while (1);
}

Das seltsame ist; Wenn ich jetzt den String mit einzelnen Zeichen beschreibe, kann dieser ohne Probleme an den Kernel übergeben werden:

char titel[50];

void main( void )
{
U_WINDOW window_par;
unsigned int window_id;

titel[0] = 'H';
titel[1] = 'a';
titel[2] = 'l';
titel[3] = 'l';
titel[4] = 'o';


mem_cpy( titel, window_par.titel,50 );
window_par.x = 10;
window_par.y = 10;
window_par.w = 210;
window_par.h = 230;

window_id = u_gui_window_create( (U_WINDOW *)&window_par );

while (1);
}

Hier wird nun das Fenster mit TITEL erstellt.

Ich hoffe jemand weis an was das liegen könnte. Vieleicht an einer Linkereinstellung??

Vielen Dank im Voraus




bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #1 am: 18. July 2009, 13:09 »
Zuerstmal ist es Absicht, dass du ein falschrum-memcpy hast? :-D
Ansonsten fällt mir zu der Art Problem nur ein, dass gcc irgendeine Optimierung im ersten Fall macht, aber im zweiten nicht. Eventuell -O0 mal versuchen (falls du vorher irgendein anderes O verwendet hast). Aber um dazu was sagen zu können müsste man das mem_cpy und u_gui_window_create sehen und wissen, ob die Funktionsdefinition dem Compiler bekannt ist wenn er deine main kompiliert.
Das andere was sein könnte, ist, dass du beim Laden der ELF-Datei einen Fehler machst, sodass zu Beginn in titel nicht "Hallo" drinsteht. Das kann sicherlich passieren, wenn man Sachen an die falsche Position kopiert, etc...
Ansonsten Frage ich mich warum da ein Cast ist, &window_par ist doch schon ein U_WINDOW*.

edit: Wäre eventuell auch interessant U_WINDOW zu sehen.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 18. July 2009, 13:37 »
Ich tippe auf ein Linkerproblem. Wenn man direkt initialisiert, dürfte das doch in einer anderen Sektion landen, oder? .data/.rodata statt .bss oder sowas. Wenn du eine der Sektionen beim Linken unter den Tisch fallen lässt, gibt es Probleme.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Hunter

  • Beiträge: 28
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 18. July 2009, 15:20 »
Danke für eure Antworten  :-) ...

Ja ich weiß mem_cpy( source, dest, ... ) ist nicht gerade normgerecht  ... muss ich mal ändern  :-D ... Du hast recht den Cast brauche ich in diesem Fall nicht ... ich habe den Code jedoch zuvor direkt aus dem Kernel heraus getestet und hier verwende ich die Struktur WINDOW anstelle von U_WINDOW, und daher noch der Cast, da sonst GCC meckert ...

Also ich compiliere das C-File wie folgt mit GCC:

gcc -c guibsp\main.c -I include -Wall -Werror -nostdlib -nostartfiles -nodefaultlibs
anschließend Linke ich die Datei, als Binary, wie folgt:

ld -T guibsp\link.ld -o guibsp.bin

OUTPUT_FORMAT("binary")
INPUT(
main.o
lib\lib_o\gui_window.lib
lib\lib_o\strlib.lib
lib\lib_o\print.lib
lib\lib_o\syscall.lib
lib\lib_o\io.lib
lib\lib_o\staticos_io.lib

)
ENTRY(_main)
phys = 0x000000;
SECTIONS
{
  .text phys : AT(phys) {
    code = .;
    *(.text)
    *(.rodata)
    . = ALIGN(4096);
  }
  .data : AT(phys + (data - code))
  {
    data = .;
    *(.data)
    . = ALIGN(4096);
  }
  .rodata : AT(phys + (rodata - code))
  {
  rodata = .;
     *(.rodata)
     . = ALIGN(4096);
  }
  .bss : AT(phys + (bss - code))
  {
    bss = .;
    *(.bss)
    . = ALIGN(4096);
  }
  end = .;
}

...

Ich vermute zwar dass der Fehler nicht in mem_cpy oder u_gui_window_create liegt aber ich poste die Funktionen einfach mal:

int mem_cpy( unsigned char *s1, unsigned char *d1, unsigned int size )
{
int i;
for( i=0;i<=size;i++ )
d1[i] = s1[i];

return i;
}

unsigned int u_gui_window_create( U_WINDOW *window_par )
{
MESSAGE_t send;

send.com = VIDEO_GUI_WINDOW_CREATE;
send.str1 = (unsigned int)(window_par);

sys_int( &send );

return send.empf1;
}

sys_int( .. ) .. ruft dabei einen Interrupt auf, der veranlasst dass die Struktur send zum Kernel übergeben wird ...

Aja hier noch die Struktur welche die Fenstereigenschaften beinhält ...

typedef struct  {
char titel[50];
int x;
int y;
int x2;
int y2;
int w;
int h;
int w2;
int h2;
unsigned int id;
unsigned char zustand;
unsigned int *draw_buffer;
} __attribute__ ((packed)) U_WINDOW;


Ich habe bereits einige experimente am Linkerfile vorgenommen, jedeoch ohne Erfolg ... Ich habe Rodata hinzugefügt, ... etc.

@bluecode:

Du sagtest ja es könnte sein dass ich einen Fehler beim Laden der ELF - in meinem Fall BIN - Datei mache ... wie meinst du das genau ??

Danke im Voraus
« Letzte Änderung: 18. July 2009, 15:23 von Hunter »

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #4 am: 18. July 2009, 19:48 »
Du hast da zweimal *(.rodata) im Linkerskript. Das ist vielleicht nicht so toll...

Und Fehler beim Laden von ELF-Dateien kann man wohl genug machen: Zuwenig/zuviel kopieren bei den Sections, nicht an die richtige Stelle kopieren, nicht alle Sections kopieren, kA was noch alles.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

 

Einloggen