[9fans] Strings in acid, what am I missing?

[9fans] Strings in acid, what am I missing?

[Grant R. Mather]

I've been trying to learn how to use the acid debugger for a few days
now, but there are a few things I'm having trouble understanding.  One
of which is the syntax for dealing with strings.

I have the following program:

#include <u.h> #include <libc.h>

void main(void) {
	int x = 10;
	int *ip = &x;
	int ia[] = { 1, 2, 3 };
	char ca[] = "Hello";
	char *cp = "World";

	exits(0);
}

In acid, I get the following values:
*main:x\d = 10
**main:ip\d = 10
*main:ia\d = 1
*main:ca\s = *s<integer>*
*(main:ca\s) = Hello
*(main:cp\s) = $

The first three values are expected, but when it gets to strings, I
fail to understand what's happening.  What is the purpose of the
parenthenses?  Why does 'cp' not give me the correct value and just
gives me garbage instead?


Any help would be much appreciated.

Re: [9fans] Strings in acid, what am I missing?

[erik quanstrom]

> *main:ca\s = *s<integer>*
> *(main:ca\s) = Hello
> *(main:cp\s) = $
>
> The first three values are expected, but when it gets to strings, I
> fail to understand what's happening.  What is the purpose of the
> parenthenses?  Why does 'cp' not give me the correct value and just
> gives me garbage instead?

part of the issue is, c does not have strings.  the other part is that
acid doesn't really understand c.  the reason that the () are required
is that * binds tighter than \s in acid.  one thing that's confusing about
acid is main:ca is an *address* of main:ca, not its value.  so *main:ca
is the pointer into the bss, and main:ca is the address of that pointer.

the reason cp gives you garbage is it's not initialized.  in fact when
i compile this for am64, you can see everthing quite clearly.  it is
optimized away!  (it's a good question why a char* is treated differently
than a char[].  perhaps there is some dark corner of the standard that
implies things.)

acid; asm(main)
main 0x00200028	SUBQ	$0x38,SP
main+0x4 0x0020002c	MOVL	$0xa,x+0x34(SP)		// x = 10
main+0xc 0x00200034	LEAQ	x+0x34(SP),AX		// ip = &x
main+0x11 0x00200039	MOVL	$0x1,ia+0x1c(SP)		// ia[0] = 1
main+0x19 0x00200041	MOVL	$0x2,0x20(SP)		// ia[1] = 2
main+0x21 0x00200049	MOVL	$0x3,0x24(SP)		// ia[2] = 3
main+0x29 0x00200051	MOVB	$0x48,ca+0x16(SP)	// ca[0] = 'H'
main+0x2e 0x00200056	MOVB	$0x65,0x17(SP)		// ca[1] = 'e'
main+0x33 0x0020005b	MOVB	$0x6c,0x18(SP)		// ca[1] = 'l'
main+0x38 0x00200060	MOVB	$0x6c,0x19(SP)		// ca[1] = 'l'
main+0x3d 0x00200065	MOVB	$0x6f,0x1a(SP)		// ca[1] = 'o'
main+0x42 0x0020006a	MOVB	$0x0,0x1b(SP)		// ca[1] = '\0'
main+0x47 0x0020006f	MOVL	$.string(SB),AX
main+0x4c 0x00200074	XORQ	BP,BP			// 1st argument to exits -> 0
main+0x4f 0x00200077	CALL	exits(SB)
main+0x54 0x0020007c	ADDQ	$0x38,SP
main+0x58 0x00200080	RET
_main 0x00200081	SUBQ	$0x90,SP

you can also see this in the compile output:

; tmk q.c
6c -FVTw q.c
warning: q.c:11 auto declared and not used: cp
warning: q.c:10 auto declared and not used: ca
warning: q.c:9 auto declared and not used: ia
warning: q.c:8 auto declared and not used: ip
warning: q.c:8 set and not used: ip
warning: q.c:11 set and not used: cp
6l -o 6.q q.6

- erik

Re: [9fans] Strings in acid, what am I missing?

[Grant R. Mather]

> the reason that the () are required
> is that * binds tighter than \s in acid.  one thing that's confusing about
> acid is main:ca is an *address* of main:ca, not its value.  so *main:ca
> is the pointer into the bss, and main:ca is the address of that pointer.

So if I understand you correctly, in acid main:ca is the equivalent to
char ** in C? And furthermore that the \s expression operates on acid
addresses rather than normal char * in C? From trying things out in
acid a little bit, it seems like this is the case, but I'm not
positive.

> the reason cp gives you garbage is it's not initialized.  in fact when
> i compile this for am64, you can see everthing quite clearly.  it is
> optimized away!  (it's a good question why a char* is treated differently
> than a char[].  perhaps there is some dark corner of the standard that
> implies things.)

I see what you're saying about cp not being initialized, but I
compiled with the -N option and I assumed that this would rectify the
situation of things being optimized away.  Interestingly enough if I
do **main:cp\c in acid it gives me 'W', but *(main:cp\s) gives me
garbage, whereas *(main:ca\s) gives me "Hello".

Thanks for the response, any other help would be appreciated!

Re: [9fans] Strings in acid, what am I missing?

[erik quanstrom]

> > the reason that the () are required
> > is that * binds tighter than \s in acid.  one thing that's confusing about
> > acid is main:ca is an *address* of main:ca, not its value.  so *main:ca
> > is the pointer into the bss, and main:ca is the address of that pointer.
>
> So if I understand you correctly, in acid main:ca is the equivalent to
> char ** in C? And furthermore that the \s expression operates on acid
> addresses rather than normal char * in C? From trying things out in
> acid a little bit, it seems like this is the case, but I'm not
> positive.

almost, the \<char> expressions define the type of the object.  you
have to define the type before indirection is sensible.

so you can say x\X (print a 4-byte integer), but *(x\s).

> > the reason cp gives you garbage is it's not initialized.  in fact when
> > i compile this for am64, you can see everthing quite clearly.  it is
> > optimized away!  (it's a good question why a char* is treated differently
> > than a char[].  perhaps there is some dark corner of the standard that
> > implies things.)
>
> I see what you're saying about cp not being initialized, but I
> compiled with the -N option and I assumed that this would rectify the
> situation of things being optimized away.  Interestingly enough if I
> do **main:cp\c in acid it gives me 'W', but *(main:cp\s) gives me
> garbage, whereas *(main:ca\s) gives me "Hello".
>
> Thanks for the response, any other help would be appreciated!

perhaps that's an arguable flaw in the compiler.  in any event, the
correct way to declare something used is
	USED(x, y, z)
this is not a macro, but implemented by the compiler directly.  SET()
is analogous.

- erik