Re: A more structured approach
- From: "Chinlu" <chinluchinawa@xxxxxxxxxxx>
- Date: 10 Jun 2006 04:17:03 -0700
sevagK wrote:
Chinlu wrote:
Hello Frank,
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.
Yes sorry, I've been looking at doing this the most difficult way
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.
I thought not in this case, cause I just wanted to test whether "PWD=",
there is
a "=" short, were the same as the begining of the data the register
points to
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.
I couldn't do it any of the ways. I'm finding gas a bit strict, and
quite raw
and difficult to get to know.
I've been trying the other way round, which is, I get the begining of
the first environment variable, and then start looking in reverse
order till I find the first "/", then I'd have binary name, as well
as current working directory, all in one go.
I've tried all the possible ways one could imagine. Pure heuristic,
none of them
worked, from cmp*, comps*, using rep, using test, etc, etc.
Surprissingly, I get
some decent result with sub. I've uploaded the source:
http://es.geocities.com/ucho_trabajo/asm/test.s.txt
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...
Well, I'm taking this from the programming grund up book, where do you
sugest to save it then?
Since I'm testing so many things one after another, and I don't use to
delete code that doesn't break, although I should have done it before
pasting it, my fault.
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.
Thanks, well I couldn't do that kind of things before the next couple
of moths I reckon.
Kind Regards,
If you're looking for the full program path, I've found this method to
be reliable no matter where the program was launched from (link or
direct).
// HLA code
...
str.talloc (1024); // allocate some string space on stack
mov (eax, ecx);
linux.getpid(); // get process id
// build a string for path "/proc/<programID>/exe"
str.put ((type string ecx), "/proc/", (type uns32 eax ), "/exe");
linux.readlink ((type string ecx), buffer, 299);
if (eax) then
/* zero terminate (maybe not necessary if array */
/* is init. to zeros from start */
mov (0, (type byte buffer[eax]));
endif;
/* at this point, full path name starts at buffer[0] */
-sevag.k
www.geocities.com/kahlinor
Hello, thanks for the tip.
I should really use something different than c and objdump---which can
be quite confusing for a newbie at the begining---to see how things
looks like when written to machine code, say hla or nasm which would be
even closer to gas.
But in the other hand trying to learn two languages when I barely can
with one, could give twice the mess I already have, so I think is gonna
be better to practice with the target compiler and get to there
basically.
Also I didn't mention, cose I didn't know this would vary, in my stack
I've (in order), number of command-line arguments, and then binary name
+ full path, such as /home/usr/test/test.bin, a 0x0000 which is de
delimiter, and then all the environment variables. My fault.
Kind Regards,
.
- References:
- A more structured approach
- From: Chinlu
- Re: A more structured approach
- From: Frank Kotler
- Re: A more structured approach
- From: Chinlu
- Re: A more structured approach
- From: sevagK
- A more structured approach
- Prev by Date: Branch execution
- Next by Date: Re: A more structured approach
- Previous by thread: Re: A more structured approach
- Next by thread: Re: A more structured approach
- Index(es):
Relevant Pages
|
