Re: A more structured approach


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

.

Relevant Pages

  • Re: A more structured approach
    ... For the purpose of a "string compare" routine that'll be ... you might care. ... some assembly language, you don't. ... But I would then pass that as a parameter to my "find environment ...
    (alt.lang.asm)
  • Re: GenEnvironmentVariable and CreateProcess failures under XP
    ... environment variable was not found in the environment block. ... If you first call GetEnvironmentVariable with a 0-length string, ... It does not affect the "system environment" that other ... CreateProcess to launch Notepad or other Win32 executables. ...
    (microsoft.public.vb.winapi)
  • Complex XML Serialization
    ... I've been reading Keith Pijanowski's article - Enrich Your XML Serialization With Schema Providers In The .NET Framework - on how to do custom serialization of objects. ... private string _administratorPassword; ... //foreach (Environment environment in this.Environments) ...
    (microsoft.public.dotnet.xml)
  • Purpose of TZ setting?
    ... Isn't the purpose of the TZ string in ... that the OS is supposed to be able to take care of ST/DST ... Or am I wrong about my expectation? ...
    (comp.os.os2.misc)
  • Re: 15 Answers to Creationists Nonsense Claims
    ... if evolution were a computer program than the ... desired string would be passed to the program as an argument, ... The environment does not interact with the DNA directly, ... with the phenotype that the DNA constructs. ...
    (talk.origins)