| |
| |
| |
|
Comments:
<0> help! i can't get a newline to print when i call printf with strings
<0> message: db "Hello!", 10, 0 <---- 10 = newline so what is problem?
<0> oh, shell problem..nevermind
<1> who want help me? http://authors.aspalliance.com/aylar/ViewPasteCode.aspx?PasteCodeID=5889 seems not create any thread...
<2> hey, im having problems with a VERY simple asm program
<2> http://authors.aspalliance.com/aylar/ViewPasteCode.aspx?PasteCodeID=5890
<2> whenever i run it, i get "segmentation fault"
<3> there's bug in linux kernel
<3> makes ANY program segfault if it doesn't have writable data segment
<3> add a data section [can be empty]
<3> just stuff section .data at the end
<2> ok, that worked, thanks
<2> would updating my kernel fix it? or is the newest one still bugged?
<3> all i tested on are bugged.
<3> also, i doubt any kernel developer actually cares about that problem
<2> hmm... you're probably right
<4> maybe not
<5> which is why there needs to be a bug fix and testing cycle! *hides*
<6> could an str instruction (ARM asm) cause a sigfpe?
<7> whats ARM
<8> in 64 bit mode, is it correct to say that segment process level restrictions are completely ignored?
<9> no
<8> it says the segment selectors are ignored, so does that mean it ***umes a segment descriptor with full access rights for ds etc?
<8> or how does that work
<9> the access rights are still used, the base and limit fields aren't (except for fs and gs)
<8> so, if you wanted to make it so you couldn't write to some area of the program in 64 bit mode using segment access rights, how would that be done?
<8> if the base and limit are ignored, if you let ds be writeable, it would seem it would make it writeable everywhere
<9> sure, as long as you're the kernel
<9> you still have the protection rings
<8> yeah, but how would the protection rings help?
<8> if the segment selector things that you have write access everywhere
<8> (ignoring page protection)
<9> if the selector is a pl0 selector and you're running in pl3, you don't touch
<8> well sure, but if you load a pl3 selector into ds
<8> so that you can write into a memory area
<8> wouldn't it let you write into any memory area?
<9> subject to paging, sure
<8> so theres no way in 64 bit mode to make memory that level 1 can't touch
<9> ...paging
<8> paging only has super/user, and level 1 is super
<9> well, you sorta have to trust your privileged code
<9> besides, pl1 and 2 are silly anyways
<8> why?
<9> ask the dozens of OSen which don't use them
<8> well sure, but what if you have code that sometimes needs to modify kernel data structures but the rest of the time you want it seperated for safety?
<9> make it pl3 and provide a protected syscall?
<8> and you can't tell ahead of time which memory in the kernel it wants to modify, so syscalls are out
<9> sure they aren't...what are you trying to modify...make your syscall modify that object, not some memory block
<8> because I don't know the specific object ahead of time
<9> someone knows...communicate that information to the kernel
<8> hmm, if you used a segment selector to jump to the code, kept the code in level 1, and then set the RPL to 3 if it was from level 3, and otherwise let it be 0 if it was from the kernel
<8> would that possibley work? (am I understanding RPL correctly?)
<8> er, no I was not
<8> so it seems the correct answer would be to be make two code segments for the code, one at each privlege level
<8> if you wanted it to be able to touch certian parts of the kernel only at low level privlege level calls
<8> ok, thanks .
<10> Wow, I didn't know Programming From The Ground Up was available for free on the net!
<10> I'm glad that is considered the perfect Linux ***embly book because I bought it over a year ago. :)
<10> Haven't had time to read it though
<11> nn all
<12> ahh.. i feel at home
<13> ok, but remove your feet from the table!
<13> good boy
<14> hehe
<1> why don't write correct values in handle pointer pushed with ebx?
<1> push dword 0x20 ; buffer size
<1> push dword security_attributes
<1> mov ebx, in_write
<1> add ebx, [counter]
<1> push dword ebx
<1> mov ebx, in_read
<1> add ebx, [counter]
<1> push dword ebx
<1> call [CreatePipe]
<14> eww, win32. I surrender.
<14> undesktop, it has to be fast :p
<15> ahhhhhhh horror ahhhhhhh
<14> he usual case
<16> well the rest of windaz is so slow
<15> let's rewrite in asm
<15> then it'll be ff***st
<1> nooo... i'm just learning asm... for fun
<1> but i really don't know what is the prolem... security_attributes is 12 byte long...
<1> 4 byte for PHANDLE...
<1> bah
<15> ?
<1> it give me a NOACCESS error, so don't write handles value where points ebx pushed
<1> hi
<1> a good debugger that let me to see creted threads running?
<17> is this wrong?===> mov byte eax, [esi]
<17> it gives this at ***embly time ==> warning: register size specification ignored
<3> yes. it is wrong.
<3> eax is 4 bytes long. you tried to move only one byte. it's inconsistent.
<3> 'al' is name of lowest byte of eax. mov al, [esi] will move only a byte.
<3> which is probably what you meant
<17> mwk: you can mov one byte in data segment but not a register right? mov byte eax, [my_string] is ok right?
<17> mwk: ...i mean one byte *FROM* data segment
<3> no.
<17> mwk: :(
<3> you cannot move a BYTE to eax register, cause eax is 32-bit wide.
<3> but you can move a byte to a byte-sized register.
<17> mwk: oh yea, sorry...ok, rethinking
<3> one of 8-bit registers is al
<3> interestingly, al overlaps with low 8 bits of eax
<17> mwk: any good reason to avoid mixing 8 bit and 32 bit registers? seems al, ah, ax are archaic
<3> al and ax are needed to move 8-bit or 16-bit quantity
<17> mwk: you could copy 32 bits and shift right 24 bits too right!?? that seems more elegant perhaps
<17> mwk: mov eax, [esi] ; shr eax, 24 <=== cool fully 32 bit to do it!
<17> mwk: ??
<3> no. this 8-bit quantity could be on an edge of accessible memory. accessing a bit higher or lower address [as implied by 32-bit access] could cause segfault.
<3> besides, i see no point in this shift-right thingie.
<17> mwk: i just maybe it would 'keep things simple' to pretend there are no 8/16 bit registers
<3> it's plain dumb.
<3> 8-bits and 16-bits are NEEDED to do 8-bit or 16-bit memory access. period.
<17> mwk: do even sane superelegant nonintel archtectures need various sized registers? (they can't all be 32 or 64 bits?)
<3> no. sane superelegant nonintel architectures have instructions that get 8-bit sized thingie from memory and instantly extend them to 32-bits, either with 0s or with sign bits [to accomodate for C signed/unsigned char].
<3> and insns that store only low 8/16 bits of register to memory
<3> however, intel doesn't have them.
<17> mwk: thanks a lot for help... i really appreciate it
<3> ok. my bad. intel DOES have movsx and movzx insns that can load 8-bit/16-bit memory quantity straight to 32-bit register and even extend it appropriately/.
<3> however, it doesn't have anything for STORING 8-bits/16-bits into memory without use of 8-bit/16-bit registers.
<17> mwk: yay! i'll look into those
<3> and storing is the harder part anyway... with load, you could just ignore higher bits. with storing, you'd overwrite them if using 32-bits. bad.
<17> mwk: i'm unclear what diff is between 'loading' and 'storing'
<3> loading is getting something from memory
<3> storing is putting data to memory
<3> it's RISC terminology, mostly.
<17> k, thanks again
Return to
#asm
or
Go to some related
logs:
sugarcrm origin matched
error im-switch -s uim_anthy
#linux
#linux
error running install command for sound_slot_0
#math
genkernel no rule to make arch/x86
#physics
ubuntu nzbget zlib
!!! Error: Unrecognized option eselect nvidia
|
|