search for: kaboom

...fact it doesn't build :-( >> libcom32.a(bios.o): In function `SEG': >> /root/syslinux/com32/include/com32.h:144: undefined reference to `__bad_SEG' >> /root/syslinux/com32/include/com32.h:144: undefined reference to `__bad_SEG' >> >> It seems that the kaboom.c file is not compiled with the lib to define >> the function, but I'm absolutely unclear on what to do to fix this :-( > >kaboom.c is in the core, not ldlinux.*. I can't say I've ever seen this before. I'm not sure I get your point here. kaboom.c is the file defining...

...: > /root/syslinux/com32/include/com32.h:144: undefined reference to `__bad_SEG' > /root/syslinux/com32/include/com32.h:144: undefined reference to `__bad_SEG' > make[3]: *** [ldlinux.elf] Error 1 > make[3]: Leaving directory `/root/syslinux/bios/core > > It seems that the kaboom.c file is not compiled with the lib to define > the function, but I'm absolutely unclear on what to do to fix this :-( kaboom.c is in the core, not ldlinux.*. I can't say I've ever seen this before. -- -Gene

...tter to open a new thread for this. So, here's my test session: $ qemu -fda extlinux.144 -s -S Then in another terminal: $ gdb extlinux.elf (gdb) set architecture i8086 (gdb) target remote localhost:1234 Remote debugging using localhost:1234 0x0000fff0 in ?? () at localboot.inc:68 68 jmp kaboom ; If we returned, oh boy... How does "jmp kaboom" get here? We are at the BIOS entry point: (gdb) display/10i $cs*16+$eip 1: x/10i $cs * 16 + $eip 0xffff0: ljmp $0xf000,$0xe05b [...] (gdb) info symbol 0x7c00 bootsec in section .text (gdb) b bootsec Note: breakpoint -2 also set at p...

On Wed, Oct 07, 2015 at 05:58:51PM -0500, Clements, James wrote: > James Clement > > Geert Stappers > > > On Wed, Oct 07, 2015 at 05:06:41PM -0500, Clements, James wrote: > > > > The screen displays the following: > > > > > > > > PXE Network Boot using IPv4 > > > > .... > > > > Station IP address is 192.168.205.50

...gt;> [3] http://llvm.org/bugs/show_bug.cgi?id=20329 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian iDirector, Linaro Mobile Group Tech Lead, Chromium, ChromeOS, Graphics, GPGPU Linaro.org │ Open source software for ARM SoCs irc: tgall_foo | skype : tom_gall

...2.c:void load_env32(com32sys_t * regs __unused) core/extern.inc: ; elflink/load_env32.c core/extern.inc: extern load_env32, pm_env32_run core/include/core.h:extern void load_env32(com32sys_t *regs); core/isolinux.asm: pm_call load_env32 core/isolinux.asm: jmp kaboom ; load_env32() should never return. If core/pxelinux.asm: pm_call load_env32 core/pxelinux.asm: jmp kaboom ; load_env32() shouldn't return. If it does, then kaboom! efi/main.c: Print(L"load_env32 start\n"); efi/main.c:...

So far I tested PXELINUX from 4.10-pre12, 4.10-pre9 and 4.10-pre6. The first two take a long time with a TFTP file not found and eventually find my file but error out (presumably to kaboom). The last takes a long time, does a lot of retransmitted packets (didn't watch the first two), then eventually loads the file but continues this behavior for TFTP and HTTP transfers. This is on VMware Server 2.0.2-203138 in Linux using the DHCP server that comes with VMware Server, the PXE R...

...hat, the only problem is the race > condition with the NMI handler, as shift_ist does not work well with > exceptions that can also trigger within the NMI handler. But I have > taken care of that for #VC. > I assume the race you mean is: #VC Immediate NMI before IST gets shifted #VC Kaboom. How are you dealing with this? Ultimately, I think that NMI will need to turn off IST before engaging in any funny business. Let me ponder this a bit. > > Regards, > > Joerg >

...hat, the only problem is the race > condition with the NMI handler, as shift_ist does not work well with > exceptions that can also trigger within the NMI handler. But I have > taken care of that for #VC. > I assume the race you mean is: #VC Immediate NMI before IST gets shifted #VC Kaboom. How are you dealing with this? Ultimately, I think that NMI will need to turn off IST before engaging in any funny business. Let me ponder this a bit. > > Regards, > > Joerg >

...t; > ^ this gets a pointer to the byte after the 4 allocated bytes. > >> %3 = bitcast [0 x i32]* %2 to i8* >> call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* bitcast ([5 x i32]* >> @.gvar_array to i8*), i64 20, i32 4, i1 false) > > This copies 20 bytes there, kaboom! > Such a painfully obvious answer, thank you! I'm assuming this is what happens when I use the unoptimized version of the code and call > %0 = alloca %MainClass then transfer the array into that. If I'm taking a MainClass pointer into my <init> function, can I then just...

..."globs". So, back in the present: this evening that same problem recurred for the 3rd or 4th time since the original event mentioned above. so I deleted that file, logged off and back on (without the log off/on, the problem still occurs). Having done that, I went to fire up firefox and KABOOM!! X dies and I land back at a login prompt. several times. every time. tried running firefox from a terminal but I don't see anything echoed to the terminal before it is blown away. I still have the tarball from mozilla.org, so I moved aside the directory where the firefox runtime stuff is,...

...i32, [0 x i32] }* %0, i64 0, i32 1 ^ this gets a pointer to the byte after the 4 allocated bytes. > %3 = bitcast [0 x i32]* %2 to i8* > call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* bitcast ([5 x i32]* > @.gvar_array to i8*), i64 20, i32 4, i1 false) This copies 20 bytes there, kaboom! Ciao, Duncan.

...2 program? I have a com32 program that sometimes (based upon conditions) needs to reboot the system. I would prefer to do a warm reboot (40:72 = 0x1234), but at this point cold would be OK too. grepping through syslinux-3.51 I only found one reference, in iso/pxelinux.asm at the tail end of 'kaboom' ... but presumably that only happens after things go wrong. It isn't clear to me how to do this since the com32 program is running in 32-bit mode. Q: Can I just make a pointer to a function, set the value to 0x000FFFF0 and make a call into the BIOS ROM, even though I am running in 32-bit...

...r I implemented following code (have to say that I'm assembler newbie): mov si,really_boot call writestr mov si,caution_str call writestr mov cx,20 jmp sleep_loop jmp kaboom sleep_loop: push cx xor ax,ax mov ah,01h ; look for available char from keyboard int 16h jnz booting_dvd ; boot from cd / dvd xor ax,ax mov ax,500 ;...

...n Sat, Apr 25, 2020 at 1:23 PM Joerg Roedel <joro at 8bytes.org> wrote: > > On Sat, Apr 25, 2020 at 12:47:31PM -0700, Andy Lutomirski wrote: > > I assume the race you mean is: > > > > #VC > > Immediate NMI before IST gets shifted > > #VC > > > > Kaboom. > > > > How are you dealing with this? Ultimately, I think that NMI will need > > to turn off IST before engaging in any funny business. Let me ponder > > this a bit. > > Right, I dealt with that by unconditionally shifting/unshifting the #VC IST entry > in do_nmi...

...er the 4 allocated bytes. >>> >>>> %3 = bitcast [0 x i32]* %2 to i8* >>>> call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* bitcast ([5 x i32]* >>>> @.gvar_array to i8*), i64 20, i32 4, i1 false) >>> >>> This copies 20 bytes there, kaboom! >>> >> >> Such a painfully obvious answer, thank you! I'm assuming this is what >> happens when I use the unoptimized version of the code and call >> >>> %0 = alloca %MainClass >> >> then transfer the array into that. If I'm takin...

Hi, I am sorry if this question have been brought up too many times but the document does seems a little bit confusing on this. According to the official feature page[1] ARM is not a supported target (for JIT at least...). However, according to this email[2] on the list and this related bug report[3] from earlier this year, it seems that the JIT engine is working well on ARM. Is the feature

...Scroll Lock). This would provide what I believe is a fair balance between quiet startup for environments with a known working configuration and non-technical end users, and easy access to useful debugging information when it is needed. Error messages would always be printed, including the output of kaboom(). Note that this would be no less output than what is printed by ISOLINUX. Is this acceptable for mainline? Also I have not been able to find where SYSLINUX checks for key presses when starting -- is it in C or assembly? Thanks. David Ward (1): pxelinux: Polish output core/fs/pxe/pxe.c | 2...

...pointer to the byte after the 4 allocated bytes. >> >>> %3 = bitcast [0 x i32]* %2 to i8* >>> call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* bitcast ([5 x i32]* >>> @.gvar_array to i8*), i64 20, i32 4, i1 false) >> >> This copies 20 bytes there, kaboom! >> > > Such a painfully obvious answer, thank you! I'm assuming this is what > happens when I use the unoptimized version of the code and call > >> %0 = alloca %MainClass > > then transfer the array into that. If I'm taking a MainClass pointer into my &g...

Hi, I've been stuck with this problem for a while now, and my supervisor's starting to think it's a bug in lli, but I thought I'd ask here before going down that route. I have this code, which stores an array in my 'MainClass', and prints out an element of it. Note that the print statement is irrelevant here, it segfaults regardless, and this code has been run with -O2