On 08/01/15 14:14, Martin Lucina wrote: > Single-stepping through the code with GDB results in the target freezing > somewhere around 0x00000000000143d7 inside _vsnprintf_l. I say "somewhere" > because I'm not 100% sure that "stepi" combined with gdbsx always steps > only a single instruction. > > Comparing the disassembly of the start of _vsnprintf_l on a known working > machine vs Ubuntu 14.04.1 is interesting:
I think we're getting somewhere. > Known good (Debian jessie, GCC version Debian 4.9.1-19): > > 0x0000000000013d40 <+0>: push %r14 > 0x0000000000013d42 <+2>: push %r13 > 0x0000000000013d44 <+4>: mov %rcx,%r14 > 0x0000000000013d47 <+7>: push %r12 > 0x0000000000013d49 <+9>: push %rbp > 0x0000000000013d4a <+10>: mov %rdx,%r12 > 0x0000000000013d4d <+13>: push %rbx > 0x0000000000013d4e <+14>: mov %rdi,%rbp > 0x0000000000013d51 <+17>: mov %rsi,%rbx > 0x0000000000013d54 <+20>: mov %r8,%r13 > 0x0000000000013d57 <+23>: sub $0x260,%rsp > 0x0000000000013d5e <+30>: test %rsi,%rsi > 0x0000000000013d61 <+33>: je 0x13d6c <_vsnprintf_l+44> > > Ubuntu (14.04.01 LTS, GCC version Ubuntu 4.8.2-19ubuntu1): > > 0x00000000000143c0 <+0>: push %r14 > 0x00000000000143c2 <+2>: mov %r8,%r14 > 0x00000000000143c5 <+5>: push %r13 > 0x00000000000143c7 <+7>: mov %rdx,%r13 > 0x00000000000143ca <+10>: push %r12 > 0x00000000000143cc <+12>: mov %rdi,%r12 > 0x00000000000143cf <+15>: push %rbp > 0x00000000000143d0 <+16>: mov %rcx,%rbp > 0x00000000000143d3 <+19>: push %rbx > 0x00000000000143d4 <+20>: mov %rsi,%rbx > => 0x00000000000143d7 <+23>: sub $0x260,%rsp > => 0x00000000000143de <+30>: mov %fs:0x28,%rax > => 0x00000000000143e7 <+39>: mov %rax,0x258(%rsp) > 0x00000000000143ef <+47>: xor %eax,%eax > 0x00000000000143f1 <+49>: test %rsi,%rsi > 0x00000000000143f4 <+52>: jne 0x14518 <_vsnprintf_l+344> > > The crash happens somewhere around the point marked by => above. > > Oddly enough, %fs is always zero but this does not seem to cause a crash in > previous calls to printk/vsnprintf_l. Maybe memory protection hasn't been set up yet in earlier calls? Somehow the use of %fs smells like the compiler is assuming its building code for the host and applying some trickery. In fact, libc for rumprun-posix on the same ubuntu host contains the same %fs assembly snippet, but works. Maybe you can compare the cc default settings and also the output for cc -E for lib/libc/stdio/vnsprintf.c ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
