[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b66cd5ca-aae4-48eb-a0ba-2d1d4e53f810@zytor.com>
Date: Tue, 5 Nov 2024 13:37:02 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: "Woodhouse, David" <dwmw@...zon.co.uk>,
"peterz@...radead.org" <peterz@...radead.org>,
"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
"jpoimboe@...nel.org" <jpoimboe@...nel.org>
Cc: "horms@...nel.org" <horms@...nel.org>, "x86@...nel.org" <x86@...nel.org>,
"bp@...en8.de" <bp@...en8.de>, "mingo@...hat.com" <mingo@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"kai.huang@...el.com" <kai.huang@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"nik.borisov@...e.com" <nik.borisov@...e.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
Subject: Re: [RFC PATCH 6/7] x86/kexec: Debugging support: Dump registers on
exception
On 11/5/24 12:38, Woodhouse, David wrote:
> On Sun, 2024-11-03 at 05:35 +0000, David Woodhouse wrote:
>>
>> +
>> +/* Print the byte in %bl, clobber %rax */
>> +SYM_CODE_START_LOCAL_NOALIGN(pr_byte)
>> + movb %bl, %al
>> + nop
>> + andb $0x0f, %al
>> + addb $0x30, %al
>> + cmpb $0x3a, %al
>> + jb 1f
>> + addb $('a' - '0' - 10), %al
>> +1: pr_char
>> + ANNOTATE_UNRET_SAFE
>> + ret
>> +SYM_CODE_END(pr_byte)
>> +
>
> Obviously that function name (and comment) are wrong; fixed in my tree.
> at
> https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/kexec-debug
>
> This function (and also pr_qword) are also what objtool is complaining
> about:
>
> vmlinux.o: warning: objtool: relocate_range+0x2f6: unreachable instruction
> vmlinux.o: warning: objtool: relocate_range+0x305: unreachable instruction
>
> I don't quite see why, because pr_qword() quite blatantly calls
> pr_nyblle(), as it's now named. And exc_handler() repeatedly calls
> pr_qword().
>
> But most of the objtool annotations I've added here were just to make
> it shut up and build, without much though. Peter, Josh, any chance you
> can help me fix it up please?
>
> It would also be really useful if objtool would let me have data inside
> a "code" segment, without complaining that it can't decode it as
> instructions — and without also failing to decode the first instruction
> of the *subsequent* function. I've put the GDT at the end to work
> around that, but it's a bit nasty.
>
Looking at your code, you have a much bigger problem here:
+/*
+ * This allows other types of serial ports to be used.
+ * - %al: Character to be printed (no clobber %rax)
+ * - %rdx: MMIO address or port.
+ */
+.macro pr_char
+ outb %al, %dx
+.endm
+
This will overflow your UART buffer very quickly since you are now
dumping a whole bunch of data. The URT buffer -- if you even have one
and it is enabled -- is only 16 bytes in a standard 16550A UART. In
older UARTs (or emulated older UARTs) you might not have a buffer at
all. To print more than a handful of bytes, you need to poll for the
THRE bit=1 (bit 5 of register 5).
What is the point of writing this code in assembly in the first place? A
much more logical thing to do is to just push the registers you haven't
pushed already onto the stack and call a C function to do the actual
dumping? It isn't like it is in any shape, way or form performance critical.
-hpa
Powered by blists - more mailing lists