progress and a problem

progress and a problem

[ron minnich]

I've got xen calling into my hypervisor_callback but i'm seeing a very 
weird problem. On the first instruction, which is a PUSHL %eax, I take a 
page fault. The values of %ss and %esp on stack make no sense, and in 
fact change from run to run of the guest OS. All other values stay the 
same. PC does look right. 

If i just put an IRETL as the first instruction of the hypervisor_callback
all is well -- no problem. Does Xen pass in a read-only stack segment to
the callback? I don't see similar problems on the Linux side.

If I get a stack dump, everything EXCEPT ss/esp look fine -- cs, ds, etc. 
are all right. 

I have done a HYPERVISOR_stack_switch call, and all other interrupts work 
save this one.

what function in Xen calls the hypervisor_callback in the guest?

ron



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: progress and a problem

[Keir Fraser]

If Xen interrupted a ring-1 activation then the hypervisor_callback
stack frame will be pushed onto the stack that was interrupted.

If Xen interrupted rings 2 or 3 then it uses SS:ESP specified in your
call to HYPERVISOR_stack_switch when creating the hypervisor_callback
stack frame.

The code that creates the callback stack frame and jumps to your
handler is in xen/arch/x86/entry.S

 -- Keir

> 
> I've got xen calling into my hypervisor_callback but i'm seeing a very 
> weird problem. On the first instruction, which is a PUSHL %eax, I take a 
> page fault. The values of %ss and %esp on stack make no sense, and in 
> fact change from run to run of the guest OS. All other values stay the 
> same. PC does look right. 
> 
> If i just put an IRETL as the first instruction of the hypervisor_callback
> all is well -- no problem. Does Xen pass in a read-only stack segment to
> the callback? I don't see similar problems on the Linux side.
> 
> If I get a stack dump, everything EXCEPT ss/esp look fine -- cs, ds, etc. 
> are all right. 
> 
> I have done a HYPERVISOR_stack_switch call, and all other interrupts work 
> save this one.
> 
> what function in Xen calls the hypervisor_callback in the guest?
> 
> ron
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: progress and a problem

[ron minnich]

On Fri, 25 Jun 2004, Keir Fraser wrote:

> If Xen interrupted a ring-1 activation then the hypervisor_callback
> stack frame will be pushed onto the stack that was interrupted.
> 
> If Xen interrupted rings 2 or 3 then it uses SS:ESP specified in your
> call to HYPERVISOR_stack_switch when creating the hypervisor_callback
> stack frame.
> 
> The code that creates the callback stack frame and jumps to your
> handler is in xen/arch/x86/entry.S

yeah, I know that code. 

It's odd, but this all works fine for everything but hypervisor callbacks. 
Really odd. 

page faults and all that work fine. I'm looking at a stack dump right now,
from the page fault that occurs after the failed hypervisor_callback, and
i can see my wait loop CS:EIP on the stack, and the hypervisor callback
address on the stack, and the page fault frame that xen built, and it has
a bad SS:SP pair.

The sequence is: 
	Still in kernel, before starting up first user proc, I enable
interrupts (mask = 0) and just start a wait loop, and wait to get 
interrupted. I do. I then take a fault, and CS:EIP is my hypervisor 
callback function in Plan 9, as observed from page fault stack. 

If I do this in hypervisor_callback function:
	IRETL

then I never get the bogus page fault. 

If I do this:
	PUSHL AX
	IRETL

Then I get the trap at the CS:EIP of hypervisor callback, and the SS:SP on 
the stack is just wrong. 

So it's a guest in Ring 1, getting interrupted by Xen, callback function 
is activated, but callback function has an unusable ss:sp. 

blah. So close.

ron



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: progress and a problem

[ron minnich]

On Fri, 25 Jun 2004, ron minnich wrote:

> On Fri, 25 Jun 2004, Keir Fraser wrote:
> 
> > If Xen interrupted a ring-1 activation then the hypervisor_callback
> > stack frame will be pushed onto the stack that was interrupted.

OK, I've confirmed that I have the following situation: 
- Plan 9 in ring 1 in kernel mode (i.e. I really mean ring 1)
- running while(1); at end of main() with mask set to 0
- Xen deschedules Plan 9
- Xen decides to execute a callback to my Ring 1 Plan 9
- Xen is picking up a junk SS/SP pair from the stack
	Reason is that there is not, on the Plan 9 Ring 1 stack, 
	an SS/SP pair! There is only the CS/IP as far as I can see
- Xen calls my Plan 9 callback in Ring 1, with the SS/SP wrong
- Plan 9 hypervisor_callback in Ring 1 does a PUSHAL and takes a 
	page fault
- Plan 9 page fault handler dumps the stack frame , and I see this:
	o trap frame from Xen with good CS/IP, bogus SS/SP, good 
			DS/ES/etc.
	o hypervisor callback page fault frame good CS/IP, bogus SS/IP
	o frame from my while(1) with correct CS/IP but (important) 
		no valid SS/IP on the stack

So, it seems Xen has descheduled my Plan 9 guest but only the CS/IP is on 
the stack. Is there any way at all this could happen? it's very puzzling.
When Xen deschedules a domain does it force an interrupt or ...

Note: I am handling page faults in both kernel and user mode (Ring 1 and 
3) just fine. I can do console I/O. I'm just totally hung up on this 
callback mess.

Also, I should mention: I have not done an LIDT or LTR because I was 
hoping to just use the Xen default one for the domain (as I do for the 
GDT). How much trouble could this cause? It seems to have been working 
fine for a few weeks, so I assumed it was no harm done.

thanks

ron



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: progress and a problem

[Keir Fraser]

> So, it seems Xen has descheduled my Plan 9 guest but only the CS/IP is on 
> the stack. Is there any way at all this could happen? it's very puzzling.
> When Xen deschedules a domain does it force an interrupt or ...

Which stack are you talking about here? When Xen first deschedules
your while(1), the CPU should write CS,EIP,EFLAGS,SS,ESP onto Xen's
ring-0 stack.

When you get a callback, Xen should see that it is 'interrupting' an
existing ring-1 activation, and read the appropriate SS,ESP from its
own (ring-0) stack. When it writes the activation frame for teh
callback, it will only write CS,EIP,EFLAGS. SS,ESP will not be written
to your ring-1 stack because the IRET at the end of your callback
handler will not be changing privilege levels.

The same goes for your page fault: Xen will use the SS,ESP saved on it
own stack, and will not write a SS,ESP pair onto your stack.

> Also, I should mention: I have not done an LIDT or LTR because I was 
> hoping to just use the Xen default one for the domain (as I do for the 
> GDT). How much trouble could this cause? It seems to have been working 
> fine for a few weeks, so I assumed it was no harm done.

Task segments aren't virtualised, so there is no equivalent of
LTR. The quivalent of LIDT is set_trap_table() which you must have
called to be taking page faults.

 -- Keir


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: progress and a problem

[ron minnich]

On Sat, 26 Jun 2004, Keir Fraser wrote:

> Which stack are you talking about here? When Xen first deschedules
> your while(1), the CPU should write CS,EIP,EFLAGS,SS,ESP onto Xen's
> ring-0 stack.

ok, what interrupt does this? 

> When you get a callback, Xen should see that it is 'interrupting' an
> existing ring-1 activation, and read the appropriate SS,ESP from its
> own (ring-0) stack. When it writes the activation frame for teh
> callback, it will only write CS,EIP,EFLAGS. SS,ESP will not be written
> to your ring-1 stack because the IRET at the end of your callback
> handler will not be changing privilege levels.

ok, I see your point. I'm really puzzled about this bad ss/sp pair. It 
makes no sense.

> Task segments aren't virtualised, so there is no equivalent of
> LTR. The quivalent of LIDT is set_trap_table() which you must have
> called to be taking page faults.

good, that's what I was hoping to hear you say.

I'll keep looking, this is really odd.
ron



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: progress and a problem

[Keir Fraser]

> On Sat, 26 Jun 2004, Keir Fraser wrote:
> 
> > Which stack are you talking about here? When Xen first deschedules
> > your while(1), the CPU should write CS,EIP,EFLAGS,SS,ESP onto Xen's
> > ring-0 stack.
> 
> ok, what interrupt does this? 

Any interrupt. Timer, disc, ... whatever happens to cause Xen to next
execute after you disable the mask. Xen always checks the pending and
mask flags on return to ring != 0.

> > When you get a callback, Xen should see that it is 'interrupting' an
> > existing ring-1 activation, and read the appropriate SS,ESP from its
> > own (ring-0) stack. When it writes the activation frame for teh
> > callback, it will only write CS,EIP,EFLAGS. SS,ESP will not be written
> > to your ring-1 stack because the IRET at the end of your callback
> > handler will not be changing privilege levels.
> 
> ok, I see your point. I'm really puzzled about this bad ss/sp pair. It 
> makes no sense.

I'll take a look at stack traces if you want to post me some suitably
annotated ones.

 -- Keir


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: progress and a problem

[ron minnich]

Well, boy do I feel dumb and very relieved. It's not a bad SS/SP stack 
pair. Still working out what is *is*, but I think I'm close.

ron



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

TOT doesn't compile

[Kip Macy]

kmacy@moe make
rm -f linux-xen-sparse
ln -sf linux-2.4.26-xen-sparse linux-xen-sparse
make prefix=/x/eng/raidant/bk/xen-tot/install dist=yes -C xen install
make[1]: Entering directory `/x/eng/raidant/bk/xen-tot/xen'
rm -f include/xen/compile.h common/kernel.o
rm -f include/asm
ln -sf asm-x86 include/asm
cd tools/figlet && make && ./figlet Xen 1.3"-devel"
1>>../../include/xen/compile.h && cd ../..
make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'
make[2]: `figlet' is up to date.
make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'
 __  __            _   _____        _                _
 \ \/ /___ _ __   / | |___ /     __| | _____   _____| |
  \  // _ \ '_ \  | |   |_ \ __ / _` |/ _ \ \ / / _ \ |
  /  \  __/ | | | | |_ ___) |__| (_| |  __/\ V /  __/ |
 /_/\_\___|_| |_| |_(_)____/    \__,_|\___| \_/ \___|_|

make -C tools
make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools'
make -C figlet
make[3]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'
make[3]: `figlet' is up to date.
make[3]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'
make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools'
make -C common
make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/common'
gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -O3
-iwithprefix include -Wall -Werror -DMONITOR_BASE=0xFC500000
-fomit-frame-pointer -I/x/eng/raidant/bk/xen-tot/xen/include
-D__KERNEL__ -Wno-pointer-arith -Wredundant-decls -m32 -march=i686
-DNDEBUG -c kernel.c -o kernel.o
gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -O3
-iwithprefix include -Wall -Werror -DMONITOR_BASE=0xFC500000
-fomit-frame-pointer -I/x/eng/raidant/bk/xen-tot/xen/include
-D__KERNEL__ -Wno-pointer-arith -Wredundant-decls -m32 -march=i686
-DNDEBUG -c sched_bvt.c -o sched_bvt.o
sched_bvt.c: In function `bvt_alloc_task':
sched_bvt.c:99: warning: use of cast expressions as lvalues is
deprecated
sched_bvt.c: In function `bvt_init_scheduler':
sched_bvt.c:413: warning: use of cast expressions as lvalues is
deprecated
make[2]: *** [sched_bvt.o] Error 1
make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/common'
make[1]: *** [/x/eng/raidant/bk/xen-tot/xen/xen] Error 2
make[1]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen'
make: *** [all] Error 2
kmacy@moe gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: TOT doesn't compile

[Jody Belka]

On Sat, Jun 26, 2004 at 03:42:28PM -0700, Kip Macy wrote:
> sched_bvt.c: In function `bvt_alloc_task':
> sched_bvt.c:99: warning: use of cast expressions as lvalues is
> deprecated
> sched_bvt.c: In function `bvt_init_scheduler':
> sched_bvt.c:413: warning: use of cast expressions as lvalues is
> deprecated
> make[2]: *** [sched_bvt.o] Error 1
> make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/common'
  ......
> gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)

ah, looks like i never sent a followup in my "problem building xen"
thread (10 jun). sched_atropos.c also used to have the problem,
was fixed by r1.951. making similar changes in sched_bvt (diff i use
included below) should get it building. this only affects more recent
versions of gcc, as when i built a copy under deb-stable the other
day and forgot to patch first it worked ok.


--- /home/knew/1019/xen/common/sched_bvt.c      2004-06-25 15:03:05.000000000 +0200
+++ sched_bvt.c 2004-06-23 00:52:34.000000000 +0200
@@ -96,7 +96,8 @@
  */
 int bvt_alloc_task(struct domain *p)
 {
-    if ( (BVT_INFO(p) = kmem_cache_alloc(dom_info_cache)) == NULL )
+    p->sched_priv = kmem_cache_alloc(dom_info_cache,GFP_KERNEL);
+    if ( p->sched_priv == NULL )
         return -1;
     
     return 0;
@@ -410,7 +411,8 @@
 
     for ( i = 0; i < NR_CPUS; i++ )
     {
-        CPU_INFO(i) = kmalloc(sizeof(struct bvt_cpu_info));
+        schedule_data[i].sched_priv = kmalloc(sizeof(struct bvt_cpu_info), GFP_KERNEL);
+
         if ( CPU_INFO(i) == NULL )
         {
             printk("Failed to allocate BVT scheduler per-CPU memory!\n");


-- 
Jody Belka
knew (at) pimb (dot) org


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: TOT doesn't compile

[Ian Pratt]

> On Sat, Jun 26, 2004 at 03:42:28PM -0700, Kip Macy wrote:
> > sched_bvt.c: In function `bvt_alloc_task':
> > sched_bvt.c:99: warning: use of cast expressions as lvalues is
> > deprecated
> > sched_bvt.c: In function `bvt_init_scheduler':
> > sched_bvt.c:413: warning: use of cast expressions as lvalues is
> > deprecated
> > make[2]: *** [sched_bvt.o] Error 1
> > make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/common'
>   ......
> > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
> 
> ah, looks like i never sent a followup in my "problem building xen"
> thread (10 jun). sched_atropos.c also used to have the problem,
> was fixed by r1.951. making similar changes in sched_bvt (diff i use
> included below) should get it building. this only affects more recent
> versions of gcc, as when i built a copy under deb-stable the other
> day and forgot to patch first it worked ok.

Thanks for the patch. Gregor is looking at cleaning up some of
the scheduler interface so he'll incorporate this as part of a
larger checkin.

Thanks,
Ian


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: TOT doesn't link with debugging on

[Kip Macy]

make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/arch/x86'
ld -r -o arch.o entry.o trampoline.o acpi.o apic.o delay.o domain_page.o
extable.o flushtlb.o i387.o i8259.o idle0_task.o io_apic.o irq.o mm.o
mpparse.o nmi.o pci-irq.o pci-pc.o pci-x86.o   process.o rwlock.o
setup.o smpboot.o smp.o time.o traps.o usercopy.o
ld -T xen.lds -N  boot/boot.o
/x/eng/raidant/bk/xen-tot/xen/common/common.o
/x/eng/raidant/bk/xen-tot/xen/drivers/char/driver.o
/x/eng/raidant/bk/xen-tot/xen/drivers/acpi/driver.o
/x/eng/raidant/bk/xen-tot/xen/drivers/pci/driver.o
/x/eng/raidant/bk/xen-tot/xen/arch/x86/arch.o -o
/x/eng/raidant/bk/xen-tot/xen/xen-syms
/x/eng/raidant/bk/xen-tot/xen/common/common.o(.text+0x4d9c): In function
`cmain':
: undefined reference to `memguard_init'
make[2]: *** [default] Error 1
make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/arch/x86'
make[1]: *** [/x/eng/raidant/bk/xen-tot/xen/xen] Error 2
make[1]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen'
make: *** [all] Error 2


On Sat, 26 Jun 2004, Kip Macy wrote:

> kmacy@moe make
> rm -f linux-xen-sparse
> ln -sf linux-2.4.26-xen-sparse linux-xen-sparse
> make prefix=/x/eng/raidant/bk/xen-tot/install dist=yes -C xen install
> make[1]: Entering directory `/x/eng/raidant/bk/xen-tot/xen'
> rm -f include/xen/compile.h common/kernel.o
> rm -f include/asm
> ln -sf asm-x86 include/asm
> cd tools/figlet && make && ./figlet Xen 1.3"-devel"
> 1>>../../include/xen/compile.h && cd ../..
> make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'
> make[2]: `figlet' is up to date.
> make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'
>  __  __            _   _____        _                _
>  \ \/ /___ _ __   / | |___ /     __| | _____   _____| |
>   \  // _ \ '_ \  | |   |_ \ __ / _` |/ _ \ \ / / _ \ |
>   /  \  __/ | | | | |_ ___) |__| (_| |  __/\ V /  __/ |
>  /_/\_\___|_| |_| |_(_)____/    \__,_|\___| \_/ \___|_|
>
> make -C tools
> make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools'
> make -C figlet
> make[3]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'
> make[3]: `figlet' is up to date.
> make[3]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'
> make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools'
> make -C common
> make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/common'
> gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -O3
> -iwithprefix include -Wall -Werror -DMONITOR_BASE=0xFC500000
> -fomit-frame-pointer -I/x/eng/raidant/bk/xen-tot/xen/include
> -D__KERNEL__ -Wno-pointer-arith -Wredundant-decls -m32 -march=i686
> -DNDEBUG -c kernel.c -o kernel.o
> gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -O3
> -iwithprefix include -Wall -Werror -DMONITOR_BASE=0xFC500000
> -fomit-frame-pointer -I/x/eng/raidant/bk/xen-tot/xen/include
> -D__KERNEL__ -Wno-pointer-arith -Wredundant-decls -m32 -march=i686
> -DNDEBUG -c sched_bvt.c -o sched_bvt.o
> sched_bvt.c: In function `bvt_alloc_task':
> sched_bvt.c:99: warning: use of cast expressions as lvalues is
> deprecated
> sched_bvt.c: In function `bvt_init_scheduler':
> sched_bvt.c:413: warning: use of cast expressions as lvalues is
> deprecated
> make[2]: *** [sched_bvt.o] Error 1
> make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/common'
> make[1]: *** [/x/eng/raidant/bk/xen-tot/xen/xen] Error 2
> make[1]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen'
> make: *** [all] Error 2
> kmacy@moe gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --disable-libunwind-exceptions --with-system-zlib
> --enable-__cxa_atexit --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
>


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: TOT doesn't link with debugging on

[Keir Fraser]

Looks like you've got an inconsistent build -- common/kernel.c has
been built without NDEBUG defined, in contrast to arch/x86/mm.c.
If you change compile flags you need to 'make clean' for sanity.

 -- Keir


> make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/arch/x86'
> ld -r -o arch.o entry.o trampoline.o acpi.o apic.o delay.o domain_page.o
> extable.o flushtlb.o i387.o i8259.o idle0_task.o io_apic.o irq.o mm.o
> mpparse.o nmi.o pci-irq.o pci-pc.o pci-x86.o   process.o rwlock.o
> setup.o smpboot.o smp.o time.o traps.o usercopy.o
> ld -T xen.lds -N  boot/boot.o
> /x/eng/raidant/bk/xen-tot/xen/common/common.o
> /x/eng/raidant/bk/xen-tot/xen/drivers/char/driver.o
> /x/eng/raidant/bk/xen-tot/xen/drivers/acpi/driver.o
> /x/eng/raidant/bk/xen-tot/xen/drivers/pci/driver.o
> /x/eng/raidant/bk/xen-tot/xen/arch/x86/arch.o -o
> /x/eng/raidant/bk/xen-tot/xen/xen-syms
> /x/eng/raidant/bk/xen-tot/xen/common/common.o(.text+0x4d9c): In function
> `cmain':
> : undefined reference to `memguard_init'
> make[2]: *** [default] Error 1
> make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/arch/x86'
> make[1]: *** [/x/eng/raidant/bk/xen-tot/xen/xen] Error 2
> make[1]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen'
> make: *** [all] Error 2
> 
> 
> On Sat, 26 Jun 2004, Kip Macy wrote:
> 
> > kmacy@moe make
> > rm -f linux-xen-sparse
> > ln -sf linux-2.4.26-xen-sparse linux-xen-sparse
> > make prefix=/x/eng/raidant/bk/xen-tot/install dist=yes -C xen install
> > make[1]: Entering directory `/x/eng/raidant/bk/xen-tot/xen'
> > rm -f include/xen/compile.h common/kernel.o
> > rm -f include/asm
> > ln -sf asm-x86 include/asm
> > cd tools/figlet && make && ./figlet Xen 1.3"-devel"
> > 1>>../../include/xen/compile.h && cd ../..
> > make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'
> > make[2]: `figlet' is up to date.
> > make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'
> >  __  __            _   _____        _                _
> >  \ \/ /___ _ __   / | |___ /     __| | _____   _____| |
> >   \  // _ \ '_ \  | |   |_ \ __ / _` |/ _ \ \ / / _ \ |
> >   /  \  __/ | | | | |_ ___) |__| (_| |  __/\ V /  __/ |
> >  /_/\_\___|_| |_| |_(_)____/    \__,_|\___| \_/ \___|_|
> >
> > make -C tools
> > make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools'
> > make -C figlet
> > make[3]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'
> > make[3]: `figlet' is up to date.
> > make[3]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'
> > make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools'
> > make -C common
> > make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/common'
> > gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -O3
> > -iwithprefix include -Wall -Werror -DMONITOR_BASE=0xFC500000
> > -fomit-frame-pointer -I/x/eng/raidant/bk/xen-tot/xen/include
> > -D__KERNEL__ -Wno-pointer-arith -Wredundant-decls -m32 -march=i686
> > -DNDEBUG -c kernel.c -o kernel.o
> > gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -O3
> > -iwithprefix include -Wall -Werror -DMONITOR_BASE=0xFC500000
> > -fomit-frame-pointer -I/x/eng/raidant/bk/xen-tot/xen/include
> > -D__KERNEL__ -Wno-pointer-arith -Wredundant-decls -m32 -march=i686
> > -DNDEBUG -c sched_bvt.c -o sched_bvt.o
> > sched_bvt.c: In function `bvt_alloc_task':
> > sched_bvt.c:99: warning: use of cast expressions as lvalues is
> > deprecated
> > sched_bvt.c: In function `bvt_init_scheduler':
> > sched_bvt.c:413: warning: use of cast expressions as lvalues is
> > deprecated
> > make[2]: *** [sched_bvt.o] Error 1
> > make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/common'
> > make[1]: *** [/x/eng/raidant/bk/xen-tot/xen/xen] Error 2
> > make[1]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen'
> > make: *** [all] Error 2
> > kmacy@moe gcc -v
> > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
> > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> > --infodir=/usr/share/info --enable-shared --enable-threads=posix
> > --disable-checking --disable-libunwind-exceptions --with-system-zlib
> > --enable-__cxa_atexit --host=i386-redhat-linux
> > Thread model: posix
> > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/xen-devel
> >
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com