Re: wie lese ich meine kerneldumps?

Guten Morgen,

Am 13.10.2016 um 23:43 schrieb Peter:

> […]
> 0xc0e8617b <arc_buf_clone+27>: movl $0x2,0x4(%esp)
> 0xc0e86183 <arc_buf_clone+35>: call 0xc1055ef0 <kmem_cache_alloc>
>
> (kgdb) p $edi
> $8 = 0x0
> (kgdb) p $ecx>
> $9 = 0x0
>
> Wo kommt die 0 her?

Kann es sein, daß der Debugger hier versucht, $edi und $ecx als
Hex-Zahlen zu interpretieren, über das fehlende 0x am Anfang stolpert
und dann 0 ausgibt; und es stattdessen %ecx wie im Listing heißen müßte?

Nur so als Gedanke, ohne es wirklich zu wissen.

> Ich konnte zwar mal Assembler (8bit), aber Compiler ist halt noch was
> anderes. (Und nach meinem Handbuch -für iAPX88- wird beim mov der
> *rechte* parameter in den *linken* gebracht, aber hier ist es
> offenbar andersrum.)

Das ist sicher dem alten Streit um die 'richtige' Reihenfolge der
Operanden geschuldet:

http://x86asm.net/articles/what-i-dislike-about-gas/

Bei Intel und -kompatiblen ist es eigentlich immer

<Befehl> <Ziel>, <Quelle>

bei Motorola 68k dagegen immer

<Befehl> <Quelle>, <Ziel>

Diese Konventionen haben schon vor einem Vierteljahrhundert für
Verwirrung gesorgt, wenn man die Architektur wechseln mußte, selbst wenn
man ursprünglich vom 6502 kam, wo es nur einen expliziten Operanden gab.
Daß die Programmierer von Assemblern noch eine zusätzliche Meinung über
die richtige Reihenfolge haben, macht die Sache nicht unbedingt
einfacher. ;)

> Ich täte jetzt meinen, der "sub" Befehl schafft
> platz auf dem Stack für die lokalen Variablen der Funktion (0x10 für
> zwei Pointer und einen int64), und die zwei mov danach gehören schon
> zur Funktion selber. Was geht da ab?

Ich würde es vorsichtig so zuordnen, wenn man mal annimmt, daß in %edi
schon "from" steht und ich in der richtigen Quelle nachgesehen habe:

arc_buf_clone(arc_buf_t *from)
{
         arc_buf_t *buf;
                                                push %ebp
                                                mov %esp,%ebp
                                                push %ebx
                                                push %edi
                                                push %esi
                                                sub $0x10,%esp
                                                mov %ecx,%edi

         arc_buf_hdr_t *hdr = from->b_hdr; mov (%edi),%ebx
         uint64_t size = hdr->b_size; mov 0x24(%ebx),%eax

> ASSERT(HDR_HAS_L1HDR(hdr));
> ASSERT(hdr->b_l1hdr.b_state != arc_anon);

Ich sehe nicht, wo die Assertions ausgewertet werden sollten, aber das
sind ohnehin nur Makros, die vielleicht abgeschaltet sind.

Der Rest wäre dann wohl Parameterübergabe und das auf den ersten Blick
intransparente Gerechne, das optimierende Compiler gerne mal halten, bis
zum Aufruf von "kmem_cache_alloc".

Aber abseits von allem Assembler: Was sagt denn der SMART-Status der
Platte? Kann es sein, daß sie wirklich nur ein paar defekte Flash-Seiten
hat und deswegen zwischendurch IO-Fehler wirft?

Viele Grüße,

        Alexander

-
Alexander Klein
Physiologisches Institut der JLU-Gießen
Aulweg 129
35392 Gießen

http://www.med.uni-giessen.de/physio/

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 14 Oct 2016 - 10:20:43 CEST