Re: A more structured approach
- From: Frank Kotler <fbkotler@xxxxxxxxxxx>
- Date: Fri, 02 Jun 2006 17:02:34 -0400
Chinlu wrote:
Hello,
After I've seen Frank's code to print out an specified envrinonment
variable, I'm trying to imitate it.
Heh! Better to improve it than to "imitate" it - which is what you're doing...
Acutally I'm trying to know whether
the program has been called with it's name, or with a hard link I've
setup.
Yup, that's one thing it's good for. IIRC, "true" and "false" in the "asmutils" package work that way.
I've started by storing beginning and end addresses for the environment
variables,
Okay... I'm not sure how *much* advantage this gives you, since the "end" is fairly plainly marked, but it won't hurt.
and then I wanted to look for PWD,
Okay. There's a getcwd sys_call, too, but finding it in environment strings is probably faster.
and substract it's value
from the program's name.
Hmmm... I don't see what that's going to do. To get a "full path", you'd want to concatenate the two strings. To tell if you were called as the real file, or a link, you may not care what the full path is - "it depends", I guess.
This is what I've got so far:
.section .data
pwd: .ascii "PWD"
I'm not familiar with Gas syntax. Do you want ".ascii" or ".asciz"? Maybe the same thing, but it sounds as if one is zero-terminated and the other not(?). You want this to be zero-terminated. If there's nothing after it, it will probably be followed by zero padding, so it'll still work, but if you put anything after it, it'll break.
.section .bss
.lcomm end_vars, 4
.lcomm start_vars, 4
.section .text
.globl _start
_start:
movl %esp, %ebp # save the stack pointer
movl $1, %edi # set edi to 1
movl 8(%esp, %edi, 4), %eax # mov before any command line
args
movl %eax, start_vars # save the address to
start_vars
find_end_vars:
cmpl $0, %eax # whatch out for the 0x0
delimiter
jz save_end_vars # go and save it if so
inc %edi # or increment edi by 1
movl 8(%esp, %edi, 4), %eax # move it onto the next address
jmp find_end_vars # and repeat it
save_end_vars:
decl %edi # substract 1 to edi
movl 8(%esp, %edi, 4), %eax # save the address on eax
movl %eax, end_vars # save it to end_vars
exit:
movl $1, %eax
movl $0, %ebx
int $0x80
Right after save_end_vars, I might need to start looking for PWD
string,
That sounds right.
I think I should use scas for this.
Well, it won't make any difference in this case, I don't think, but "scas*" is slow, compared to individual instructions. For this *one* purpose, a simple dword cmp with 'PWD=' would do. For a more general "find an environment variable" routine - which would be more useful - you'd want a general "string compare" routine. "cmps*" might be more appropriate than "scas*" - I think that even a naive "instruction by instruction" routine will be plenty "fast enough" - we only have a small amount of data - and may well beat "cmps*". My understanding is that "rep movsb" has been kept optimized, but that the other "string" instructions have gotten slow, compared to equivalent discrete instructions. For the purpose of a "string compare" routine that'll be fast on large data sets, you might care. For the purpose of learning some assembly language, you don't. Anything that works will be fine.
Basically I'd like anyone to tell me somethig about the approach used,
so I can have feedback o how I'm understanding assembler.
One thing that comes to mind, is that you've set %ebp equal to initial %esp, but not used it. Does no harm. Saving the initial %esp is a good idea... I'm not sure %ebp is the best place...
I'm not good at "structure". Probably a result of not learning a "structured" language before asm. What C does (I think), is to push what you're calling "start_vars", then push "start_args" (the address where the command-line args start), then push the argument count, then call "main". I think what I'd do is to save initial %esp someplace "global". But I would then pass that as a parameter to my "find environment variable" routine. The environment for this program "is where it is", but it's possible to spawn a child process with a "fake" environment, and we might want to be able to search that, too.
That's about all I can think of. Seems to me you "get the idea" alright.
Best,
Frank
.
- Follow-Ups:
- Re: A more structured approach
- From: Chinlu
- Re: A more structured approach
- References:
- A more structured approach
- From: Chinlu
- A more structured approach
- Prev by Date: Re: MASM Expert needed immediately
- Next by Date: Re: MASM Expert needed immediately
- Previous by thread: A more structured approach
- Next by thread: Re: A more structured approach
- Index(es):
Relevant Pages
|