Rocksolid Light

Welcome to Rocksolid Light

mail  files  register  newsreader  groups  login

Message-ID:  

"From there to here, from here to there, funny things are everywhere." -- Dr. Seuss


devel / comp.lang.asm.x86 / x64 address indexed by 32-bit address

SubjectAuthor
* x64 address indexed by 32-bit addressPaul Edwards
`- Re: x64 address indexed by 32-bit addressPaul Edwards

1
x64 address indexed by 32-bit address

<uodu7l$35iiq$1@dont-email.me>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=890&group=comp.lang.asm.x86#890

  copy link   Newsgroups: comp.lang.asm.x86
Path: i2pn2.org!rocksolid2!news.neodome.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@nospicedham.gmail.com (Paul Edwards)
Newsgroups: comp.lang.asm.x86
Subject: x64 address indexed by 32-bit address
Date: Fri, 19 Jan 2024 21:42:14 +0800
Organization: A noiseless patient Spider
Lines: 84
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <uodu7l$35iiq$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: dont-email.me; posting-host="cea25c4caf5c1b09d7408161cba351e2";
logging-data="2308463"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/hhxOBUUjReYQMR5cKTMUyGiAV7jqq5qc="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:uHZNNU2jsi2bJo3HOW4CMkW0OVA=
 by: Paul Edwards - Fri, 19 Jan 2024 13:42 UTC

Hi.

I am using a slightly modified GCC 3.2.3
to generate x64 code, and using PDPCLIB
and running under Linux x64.

I don't trust either (my) PDPCLIB or my
modified GCC 3.2.3

Assuming PDPCLIB is behaving correctly,
it is showing that the stack is above
4 GiB. It seems to be a 48-bit address.

The executable appears to be loaded in
low memory - way below 2 GiB.

kerravon@kerravon-pc:~/scratch/eee/pdos/pdpclib$ ./pdptest ab def
welcome to pdptest
main function is at 00401334
allocating 10 bytes
m1 is 004087A8
allocating 20 bytes
m2 is 00408828
stack is around 7FFC36A1053C
printing arguments
argc = 3
arg 0 is <./pdptest>
arg 1 is <ab>
arg 2 is <def>
kerravon@kerravon-pc:~/scratch/eee/pdos/pdpclib$

Now I have this code:

printf("argv[0] is %p %s\n", argv[0], argv[0]);
printf("len is %d\n", (int)strlen(argv[0]));
p = argv[0] + strlen (argv[0]);
printf("p is %p\n", p);
printf("p as string is %s\n", p);
printf("p current is %x\n", p[0]);
printf("as negative is %x\n", p[-1]);

which is generating (for that last line):

LM1873:
movl $4294967295, %eax
addq -64(%rbp), %rax
movsbl (%rax),%esi
movl $LC445, %edi
movb $0, %al
call _printf

That first instruction - the movl - has
negative 1 as an unsigned value. I tried
manually changing the generated assembler
to $-1 but the result appears to be the
same (I may have stuffed up the test).

And it crashes:

kerravon@kerravon-pc:~/scratch/eee/gcc/gcc$ ./gcc-new.exe
argv[0] is 7FFC8DC50294 ./gcc-new.exe
len is 13
p is 7FFC8DC502A1
p as string is
p current is 0
Segmentation fault (core dumped)
kerravon@kerravon-pc:~/scratch/eee/gcc/gcc$

I suspect what is happening is that it is
adding the entire value of eax as an unsigned
32-bit value to the 64-bit address and so the
address is being offset by nearly 4 GiB
instead of being offset by 1 byte.

GCC 3.2.3 was used to build systems I believe,
so it "must" work in some circumstances.

Any idea how this was meant to work?

Thanks. Paul.

Re: x64 address indexed by 32-bit address

<uqf1hg$1vj10$1@dont-email.me>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=894&group=comp.lang.asm.x86#894

  copy link   Newsgroups: comp.lang.asm.x86
Path: i2pn2.org!i2pn.org!usenet.network!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@nospicedham.gmail.com (Paul Edwards)
Newsgroups: comp.lang.asm.x86
Subject: Re: x64 address indexed by 32-bit address
Date: Tue, 13 Feb 2024 14:17:18 +0800
Organization: A noiseless patient Spider
Lines: 36
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <uqf1hg$1vj10$1@dont-email.me>
References: <uodu7l$35iiq$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: dont-email.me; posting-host="61ede365b96fa02dc7959b4803494c35";
logging-data="2085797"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18/6nlZYSV1rTiO6oibtN1BD104/vxvI+4="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:JhnUFefbvcDuXs0MDseovFRrLbA=
 by: Paul Edwards - Tue, 13 Feb 2024 06:17 UTC

On 19/01/24 21:42, Paul Edwards wrote:

> LM1873:
> movl $4294967295, %eax
> addq -64(%rbp), %rax
> movsbl (%rax),%esi
> movl $LC445, %edi
> movb $0, %al
> call _printf

This has now been resolved. I wasn't building my
modified gcc 3.2.3 properly, so it thought that
size_t was 32 bits instead of 64 and was making
it unsigned.

Now I am getting working code:

D:\devel\gcc\gcc>type foo.s
.file "foo.c"
.text
.p2align 2,,3
..globl foo
foo:
..LFB1:
movsbl -1(%rcx),%eax
ret
..LFE1:

D:\devel\gcc\gcc>

(rcx is because one of my modifications is to use
Win64 function call convention)

BFN. Paul.

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor