Thema: nerviges gdb-problem

[derbower]

guten abend .

ich schreibe seit einiger zeit an einem kernel in c++ und assembler.
leider funktioniert irgendwas nicht richtig, weswegen ich mir bochs mit gdb-stub kompiliert habe.
leider folgen daraus nur probleme, aber vllt hatte ja jemand von euch das selbe problem oder weiß eine lösung oder was überhaupt das problem ist.

ich habe das ganze vereinfacht und eine minimale main-funktion in c programmiert. diese wird mit gcc und ld einmal als flatbinary und einmal als elf kompiliert und an adresse 0x40000 gelinkt.
lade ich nun den kernel in bochs so läuft dieser sauber durch. aber nun zum gdb-problem:
ich rufe gdb auf mit: gdb.exe kernel.elf
gdb kann die symboltabelle auslesen und gibt mir die symbole und adressen dieser auch schön sauber und korrekt aus.
wenn ich aber nun einen breakpoint mit "break main" anlege, bekomme ich zwar als meldung korrekterweise:
breakpoint 1 at 0x40000 : file kernel.c line 7
, aber wenn ich mit c bis zum breakpoint durchlaufen möchte, dann bekomme ich :
Program received signal SIGTRAP , Trace/breakpoint trap.
0c0e3258 in ?? ()
und lande an dieser stelle auch immer wieder, wenn ich c eingebe.

was ist denn da los ?

btw: im bochs eigenen debugger läuft das ganze korrekt durch. aber gdb wäre halt doch komfortabler und angenehmer.

vielen dank schon mal für infos und hilfe, falls jemand etwas weiß.

also ich habe offensichtlich entweder einen breakpoint an einer stelle, die ich eigentlich nie erreichen dürfte, oder ich kenne mich einfach nicht mehr aus *g*.

übrigends ein echt tolles forum. hab selten so viel interessantes auf einer seite gesehen.

einen schönen abend noch.

[kevin]

Hm, du benutzt aber schon sowohl für gdb als auch für die tatsächliche Ausführung dieselbe ELF-Datei? Ansonsten könnte ich mir gut vorstellen, dass die flache Binary eben nicht genau gleich aussieht und du deswegen die falsche Stelle bekommst.

Ansonsten , du könntest auch noch qemu probieren, der kann auch mit gdb.

[derbower]

ok also an der elf lag es nicht. unter wemu funktioniert das ganze.

allerdings nur bis zum ersten breakpoint...

aber schon mal vielen dank .