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

Jan-Simon Moeller dl9pf at gmx.de
Mon Aug 10 14:53:35 UTC 2015


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.



More information about the LLVMLinux mailing list