Help Logs Database

Undernet  |  EFnet  |  Quakenet  |  Freenode  |  Ircnet  |  Dalnet
Page: 1 2

<intero> hello
<dust-puppy> is the instruction movl 80386 ***embly ?
<Robert> It exists for the 80386, yes.
<Robert> But it's usually called "mov" (except by as)
<dust-puppy> I'm looking at gdb output
<dust-puppy> I'm going to see if I can get nasm-style dis***embly in gdb, which is what I'm used to
<Robert> OK, it uses as syntax, so movl sounds about right.
<Robert> I know we've had this question before in here... and I'm not sure.
<Robert> I'd just get used to the as syntax
<Robert> You'll be exposed to it sooner or later, anyway. :)
<dust-puppy> ok.. I'll try
<dust-puppy> what does the 'l' stand for ?
<dust-puppy> in movl
<Robert> "long".
<Robert> Indicateds that the operands are 32-bit.
<dust-puppy> ok, I was confused there for a while
<dust-puppy> thanks
<dust-puppy> mov %eax,0xffffffe0(%ebp)
<dust-puppy> this is very confusing
<dust-puppy> I understand what it means but
<Robert> But?
<dust-puppy> I guess it's a negative index
<dust-puppy> it's confusing to read the code with that syntax
<Robert> Well... the gdb coders thought like this: Real Programmers have no problems converting unsigned hexadecimal integers to signed ones in their head. Thus, it's unnecessary to automatically convert.
<Syco54645> i know that mips isnt really the topic of this channel, but i am trying to get help on something in it. does anyone know mips that could lend me a hand?
<Robert> Hmm...
<Robert> The only mips expert I know isn't here at the moment.
<Syco54645> well it isnt really help with code even
<Syco54645> the problem that i am having is that i need to read in a file that the user would enter the name for
<Syco54645> so i need to remove the newline
<Syco54645> i did that
<Syco54645> but the strange thing is that the program wont work with that code. fair enough i figure i did something wrong. so i made it use a hardcoded file name. still doesnt work so i delete the newline strip code and it works. so i run the newline strip code alone and it works. but when put together the program explodes
<Robert> Heh, that's odd.
<Robert> Unfortunately I don't know any mips ***embly.
<Robert> So I can't help you debug it.
<Syco54645> oh well
<Syco54645> thanks anyways
<Syco54645> i really dont see how it could matter though, the code that is as after the nl is stripped, that codes lifetime has expired. that is why i am so confused
<Robert> Well, I'd start looking for side effects of the stripping.
<Syco54645> what it is doing is loading foo[bar] when bar=10000 and it has a max array size of lets say 10
<Syco54645> that is what the error is exactly
<Syco54645> but it shouldnt do that
<Syco54645> oh wow
<Syco54645> i found the error, but i have no idea why it occurred
<Syco54645> ok
<Syco54645> i am gonna quit this for a bit then
<Syco54645> thanks for the info Robert
<Robert> Ah, OK. Good thing you found it.
<Syco54645> dont know how to fix it though
<imaginator> Syco54645: do you have the manuals from MIPS.com?
<dust-puppy2> I'm trying to understand stack overflows, and I realized my linux kernel randomizes the address of the stack for each execution
<dust-puppy2> is there a technique to make simple stack overflows work in spite of that ?
<prolific> dust-puppy2, There definitely are but it's not a good way to learn. If you're dedicated, install an earlier version of linux. I don't think 2.4 has implemented randomized stacks
<imaginator> dust-puppy2: I ***ume you're talking about the ability to overflow a stack-allocated buffer?
<dust-puppy2> imaginator, yes
<dust-puppy2> prolific, I'm learning with a book: "the shellcoder's handbook"
<dust-puppy2> I'll try with an older version of linux
<Robert> Heh.
<prolific> dust-puppy2, That book's not bad but make sure you have sufficient skill in C/asm and a stack's layout prior to reading it :)
<dust-puppy2> you're right, I started reading it figuring I would learn on the go but I had to go back and relearn x86 ***embly
<dust-puppy2> the tutorial listed in the topic is really good
<prolific> PtGU? Yeah, very good
<prolific> PftGU :/
<dust-puppy2> http://www.drpaulcarter.com/pcasm/
<dust-puppy2> this one
<prolific> Ah. I use gas
<Julian> Hi!
<aToaster> Heya guys, I'm not too sure if this is the right place to ask for MIPS help, but does anyone know how to invert the bits in MIPS?
<aToaster> xark, whenever ya get this message, forgot to say thanks for all the help =)
<iojkl_> hello
<eaumechant> hey guys
<eaumechant> I'm not an asm programmer, but I'm writing a C program
<eaumechant> in which I'd like to move the terminal cursor to the top left of the terminal after printing multiple lines of output
<eaumechant> with just one line, this could be done with the escape \r
<eaumechant> but with multiple lines, there doesn't seem to be a way to do it easily
<eaumechant> so I was wondering if anyone here might be able to point me to some way I might be able to do it with ***embler
<wcstok> look up the ansi terminal sequences and output that
<eaumechant> ansi terminal sequences!
<wcstok> ?
<dustyC> h
<dustyC> anyone could
<dustyC> pls tell me
<dustyC> USER32.dll!Dispatchmessage+0x1f
<dustyC> wut does that mean by Dispatcmessgae
<joshux> join dosbox
<chille_> if i have one bit, only one single bit, somewhere in memory and want to move that bit somewhere else. how do i do that?
<chille_> i want the code to be fast :-)
<chille_> (x86)
<markos_64> btc, sh{l|r}, or
<markos_64> and
<markos_64> or other variants of bt*
<markos_64> eg. move bit 2 from [eax] to bit 6 of [ebx] (both are bytes):
<markos_64> and ebx, 0xbf
<markos_64> er
<markos_64> and [ebx], 0xbf
<markos_64> "and byte [ebx], 0xbf" would be even better
<markos_64> bt byte [eax], 2
<markos_64> jnc .dontset
<markos_64> or byte [ebx], 0x40
<markos_64> .dontset: (rest of code)
<markos_64> that's four lines, pretty fast too
<markos_64> or
<markos_64> and byte [ebx], 0xbf
<markos_64> bt byte [eax], 2
<markos_64> setc dl
<markos_64> shl dl, 6
<markos_64> or [ebx], dl
<markos_64> etc, etc
<Robert> chille_: Personligen skulle jag anvaenda AND och OR.
<Robert> Depending on the alignment of the bit, of course.
<Robert> A more general solution with shl/shr may be necesarry, but you didn't provide any details.
<chille_> hmm..
<chille_> maybe it is a better/faster idea to use one byte instead of just one bit
<Robert> What are you trying to do?
<Robert> (dword alignment is recommended for speed, as long as things don't grow large enough to produce cache misses)
<chille_> i'm trying to optimize my code :) i have one bit in my memory at a random place and i want to move that bit to another place in the ram
<chille_> for the moment i use float's for everything. even i use only two states (1/0)
<chille_> even if i...
<Robert> "optimize my code"... that's pretty meaningless without a context.
<Robert> How many of these bits do you have?
<archivist_> flots for bit manipulation is just daft
<chille_> maybe around 10-100 bits.
<Robert> Ah.
<Robert> Then you should use dwords.
<chille_> okay
<chille_> o_0
<Robert> Say 64 bits... then you have 256 bytes if you use dwords. That's like 4 or 8 cache lines.
<Malebranche> hi
<markos_64> anyone knows a way to make this work with nasm on linux/elf:
<markos_64> call .geip
<markos_64> .geip: pop esi
<markos_64> add esi, dstart-.geip+4
<Robert> That works.
<markos_64> i want to make PIC code without involving whole GOT burden for one small function
<markos_64> the problem is: it doesn't.
<Robert> Ah, so that's what you wanted to do.
<markos_64> if/is.asm:41: error: invalid operand type
<Robert> Which line is 41?
<markos_64> dstart is in the same source file
<markos_64> 41 is add esi, ...
<Robert> Ah.
<Robert> I think you can't do calculations with those addresses like that.
<markos_64> why not?
<markos_64> ELF specifies that i can
<markos_64> that's in fact how R_386_GOTOFF works
<markos_64> and all immediates in call/jmp instructions
<Robert> Then I'm not sure why it doesn't work - sorry.
<markos_64> this is the fourth time i'm forced to edit nasm source


Return to asm
or
Go to some related logs:

hand of edward odd drop
politics
fglrx exa xorg"
tcl

Copyright © 2005 www.irclogs.ws. All rights reserved. » disclaimer » contact