[llvmlinux] "make test" for x86_64 target just hung there, why?

[Jan-Simon Moeller]

So what I can see in your a2llog is that it fails somewhere between
init/main smp_setup_processor_id 
and the
pr_notice after page_address_init .
It points to memory init imho - there were a lot of small changes in the 
latest cycle (and ASM changes, too). 


What I see on my log is is similar ...
page_address_init ~ setup_arch ~ then arch/x86/kernel/setup.c:898
setup.c:898 is a printk actually ... 
early_idt_handler_array[i]  ~> early_idt_handler_common

then 
early_idt_handler_common at arch/x86/kernel/head_64.S:397
dump_stack at lib/dump_stack.c:27

dump stack is already the stacktrace. 

So somewhere in arch/x86/kernel/setup.c or arch/x86/kernel/head_64.S

commit cdeb6048940fa4bfb429e2f1cba0d28a11e20cd5
Author: Andy Lutomirski <luto at kernel.org>
Date:   Fri May 22 16:15:47 2015 -0700
    x86/asm/irq: Stop relying on magic JMP behavior for early_idt_handlers

maybe ?


Best,
JS


Am Montag, 10. August 2015, 23:26:59 schrieb Peter Teoh:
> Thank you Jan and David,
> 
> here are the a2l.log.gz file as attachment.   Not sure if it make sense to
> you?
> 
> On Mon, Aug 10, 2015 at 10:53 PM, Jan-Simon Moeller <dl9pf at gmx.de> wrote:
> > Yes, its easier to look at -d in_asm.
> > 
> > For that reason (and to not forget the commands ;) ) I added to
> > targets/x86_64 the make goal
> > 
> > "make test-qemu-debug" ... Then take a look at a2l.log .
> > 
> > 
> > It will generate a few files:
> > - qemulog.log  is the full dose of -din_asm,op,int,exec,cpu,cpu_reset,
> > - debugaddr.log  has just the mem addr grep'ed out
> > - addresses.log is the last 2000 of these w/o the rest of the line
> > - a2l.log  is the output of address2line for each of the lines in
> > addresses.log
> > 
> > 
> > In theory it should point to the last functions executed and print out
> > the function name/line right in the llvmlinux kernel.
> > 
> > 
> > Still some grep'ing remains in case there're a lot of prints (e.g.
> > stacktrace).
> > 
> > Possibly limit the amount of data (just limit to -din_asm) in the
> > makefile.
> > 
> > Just compiling now ...
> > 
> > Best,
> > Jan-Simon
> > 
> > Am Montag, 10. August 2015, 09:12:18 schrieb David Woodhouse:
> > > On Sat, 2015-08-08 at 09:33 +0800, Peter Teoh wrote:
> > > > On Sat, Aug 8, 2015 at 8:24 AM, Jan-Simon Moeller <dl9pf at gmx.de>
> > 
> > wrote:
> > > > > This is probably due to a lockup in early boot stages (16bit boot
> > > > > code).
> > > 
> > > I believe I did fix all of that once, except for the clang bug where
> > 
> > it
> > 
> > > doesn't honour -mregparm=3 for calls to intrinsics like memcpy:
> > > https://llvm.org/bugs/show_bug.cgi?id=3997
> > > 
> > > But I'd assume llvmlinux is still carrying the patch which avoids the
> > > issue with an explicit call to its memcpy function instead of just
> > > doing a struct assignment and letting LLVM turn it into a memcpy?
> > > 
> > > Perhaps another such issue has arisen, though?
> > > 
> > > > so is there any way to do debugging through "-s -S" option?
> > > 
> > > Debugging 16-bit code with gdb was relatively painful. A lot of the
> > > time it's easier just to run it with -d in_asm and read what happened.