asmutils libc fun and games

asmutils libc fun and games

[Paul Furber]

Hello fellow asm heads,
I've discovered the joys of the asmutils boot disk and now want to make 
it possible to include statically linked code written in C and the 
asmutils libc library on the distro. But I can't get the static versions 
working. Here's the problem:

In the Makefile (in asmutils-0.16/lib/) I have:

BUILD_STATIC = y
BUILD_SHARED = y

But when building the static test proggie I get:

gcc -D__CPU__=386 -Wall -O1 -m386 -g -D__NO_STRING_INLINES -fno-builtin 
-nostartfiles -nostdlib  -static -o test1-static test1.c libc_stub.o libc.a
libc.a(libc.o): In function `_start':
libc.o(.text+0x4): multiple definition of `_start'
libc_stub.o(.text+0x0): first defined here
collect2: ld returned 1 exit status
make: *** [test1] Error 1

If I comment out STUB_OBJS and remake the static portion, then some of 
the static versions are compiled but output the __libc_banner file which 
reads:
A r e  y ou   s i c k ?

To which I reply yes! :) I would like a tiny libc written in asmutils 
that links statically so as to include some demo-style progs on the 
bootdisk. Am Imissing the point of this libc? Even the shared libraries 
that build correctly are dynamically linked to libNoVersion and GNU libc 
when you ldd them. What's up with that?

Paul.

Re: asmutils libc fun and games

[h-peter recktenwald]

On Fri, 17 May 2002 15:24:47 +0200
Paul Furber <paulf@gam.co.za> wrote:

> bootdisk. Am Imissing the point of this libc? Even the shared libraries 
> that build correctly are dynamically linked to libNoVersion and GNU libc 
> when you ldd them. What's up with that?

I made a similar experience, -nostdlib &c just useless. found a workaround 
having "libc.a" first in the search path, which apparently keeps the GNU-ish 
stuff happy but, doesn't forcedly include such nonsense.

regards,
	hp

=====
compiled, tests passed:

> /usr/src/asm/nasm-98-3e-21/nasm 0.98.21 may miscompile asmutils, please 
>	use only clean /usr/src/asm/nasm-98-3e-21/nasm 0.98!
patched version 98.03 (with %xdefine and un-deleted listing output)

> /usr/src/asm/nasm-98-3e-21/nasm -Llibc.lis -w+orphan-labels \
>	-w+macro-params -i/usr/src/asm/asmutils/inc/ -g -f elf \
>	-D__LINUX__ -D__KERNEL__=22 -D__SYSCALL__=__S_KERNEL__ \
>	-D__OPTIMIZE__=__O_SIZE__ -D__ELF__ -DDEBUG libc.asm||:
> libc.asm:154: message:
>	section attributes ignored on redeclaration of section `.text'
(always, as usual...)

> /usr/src/asm/nasm-98-3e-21/nasm -Llibc_stub.lis -w+orphan-labels \
>	-w+macro-params -i/usr/src/asm/asmutils/inc/ -g -f elf -D__LINUX__ \
>	-D__KERNEL__=22 -D__SYSCALL__=__S_KERNEL__ -D__OPTIMIZE__=__O_SIZE__ \
>	-D__ELF__ -DDEBUG libc_stub.asm||:
> ar rcv libc.a libc.o
> a - libc.o
> gcc -mcpu=k6 -march=k6 -Wall -O1 -g -D__NO_STRING_INLINES -fno-builtin \
>	-nostartfiles -nostdlib  -static -o test1-static test1.c \
both! 	^^^^^^^^^^^^^^^^^^^^^^^^
>	libc_stub.o libc.a

> gcc -mcpu=k6 -march=k6 -Wall -O1 -g -D__NO_STRING_INLINES -fno-builtin \
>	-nostartfiles -nostdlib  -static -mregparm=3 -D__FASTCALL__\
> 	-o test1-static-fastcall test1.c libc_stub.o libc.a
> gcc -mcpu=k6 -march=k6 -Wall -O1 -g -D__NO_STRING_INLINES -fno-builtin \
>	-nostartfiles -nostdlib  -static -o test2-static test2.c \
>	libc_stub.o libc.a
> gcc -mcpu=k6 -march=k6 -Wall -O1 -g -D__NO_STRING_INLINES -fno-builtin \
>	-nostartfiles -nostdlib  -static -mregparm=3 -D__FASTCALL__\
> 	-o test2-static-fastcall test2.c libc_stub.o libc.a
> /usr/src/asm/nasm-98-3e-21/nasm -Lmd5.lis -w+orphan-labels -w+macro-params \
>	-i/usr/src/asm/asmutils/inc/ -g -f elf -D__LINUX__ -D__KERNEL__=22 \
>	-D__SYSCALL__=__S_KERNEL__ -D__OPTIMIZE__=__O_SIZE__ -D__ELF__ \
>	-DDEBUG md5.asm||:
> /usr/src/asm/nasm-98-3e-21/nasm -Lrc6.lis -w+orphan-labels -w+macro-params \
>	-i/usr/src/asm/asmutils/inc/ -g -f elf -D__LINUX__ -D__KERNEL__=22 \
>	-D__SYSCALL__=__S_KERNEL__ -D__OPTIMIZE__=__O_SIZE__ -D__ELF__ \
>	-DDEBUG rc6.asm||:
> /usr/src/asm/nasm-98-3e-21/nasm --Lrmd.lis --w+orphan-labels \
>	--w+macro-params -i/usr/src/asm/asmutils/inc/ -g -f elf -D__LINUX__ \
>	-D__KERNEL__=22 -D__SYSCALL__=__S_KERNEL__ -D__OPTIMIZE__=__O_SIZE__\
>	-D__ELF__ -DDEBUG rmd.asm||:
> ar rcv libcrypto.a md5.o rc6.o rmd.o
> a - md5.o
> a - rc6.o
> a - rmd.o

-- 
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de
NO abusive software patents http://petition.eurolinux.org/pr/pr17.html
-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

asmutils - Linux 2.4.18

[h-peter recktenwald]

hi...

found some funny differences w Linux 2.4.18 kernel wrt its predecessors 
where, for instance, the 'umount' system call doesn't work on devices 
and mountpoints, any more, but, only on the device names.

i.e, some systemcalls' names were silently changed, previously valid 
names assigned to different(ly operating) new/old syscalls.

I found this when trying the "eject" program from asmutils which was 
non functional w. 2.4.18. The patch cures the problem:
------
; patch eject.asm for Lx 2.4.18 sys_umount
.eject:
        push ecx                ; mountpoint
        push ebx                ; specialfile
    %ifdef ONLY_CCD
    %else
        test byte[edi],-1
        jnz .opn                ;?; not -ccd, just the syscall
    %endif; <= ONLY_CCD
%if __KERNEL__ < 24; new inconsistency in kernel 2.4.18!	<== !
        sys_umount              ; eject won't work on a mounted device
%else
        sys_umount dword[esp+4] ; 'oldumount' w/ #mountpoint#, only
        mov ebx,[esp]
%endif
.opn:
------

Further, the macro "_xchg" in asmutils' 'system.inc' is not correct 
(which I didn't recognize earlier because I'm using my own version;):

1) ---
 %macro _xchg 2
-%if __OPTIMIZE__=__O_SPEED__
+%if __OPTIMIZE__=__O_SIZE__;
 %assign ea 4
2) ---
@@ -721,7 +723,7 @@
 ;  2 clocks w. reg,reg
 ;      (lea variant wasn't faster, may be cpu dependent?)
 ; 33 clocks w. reg,mem or mem,reg - either case
-    xchg %{1},%{3}
+    xchg %{1},%{2};
-----
btw. the attempts to finding out about the actual addressing mode 
seem useless, "nasm" apparently providing no such means, at all.


regards,
	hp

-- 
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de
NO abusive software patents http://petition.eurolinux.org/pr/pr17.html
-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is this list dead?

[halfdead]

Hi guys,

I have been out for too long and now i see that there is no activity on
this list. Is it like dead or something?

- halfdead

Re: Is this list dead?

[Frederic Marmond]

nope, still alive...
working hard!
(for info: if you want to boot a kernel from an already running kernel, 
you can use 'monte' project. Very good! (for x86 only))

Fred
halfdead wrote:

>Hi guys,
>
>I have been out for too long and now i see that there is no activity on
>this list. Is it like dead or something?
>
>- halfdead
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>

kernel vulnerabilities

[halfdead]

Hey,
Its been rumoured for a while that certain vulnerabilities reside at
kernel level in different unix flavours (solaris/bsd/linux). Some of them
claim to be remotely exploitable (ABfrags.c, ABremkrnl.c, etc.). I have
seen local kernel vulnerabilities and they seem to be pretty tricky to
exploit hence i highly doubt that anyone would be able to work out a
clean remote exploitation. Is any of you guys aware of any method or is
this just FUD?

- halfdead

Re: kernel vulnerabilities

[Robin Miyagi]

Wouldn't a venue such as comp.os.linux.security be a more appropriate venue 
for such a question?

Or are you trolling for help exploiting such vulnerabilities :)

On Sunday 22 September 2002 05:29, halfdead wrote:
> Hey,
> Its been rumoured for a while that certain vulnerabilities reside at
> kernel level in different unix flavours (solaris/bsd/linux). Some of them
> claim to be remotely exploitable (ABfrags.c, ABremkrnl.c, etc.). I have
> seen local kernel vulnerabilities and they seem to be pretty tricky to
> exploit hence i highly doubt that anyone would be able to work out a
> clean remote exploitation. Is any of you guys aware of any method or is
> this just FUD?
>
> - halfdead
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-assembly"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Robin Miyagi<penguin@dccnet.com>
http://www.geocities.com/SiliconValley/Ridge/2544/asm/assembler.html
The funny thing about brakes, is that when they break, they don't brake.

Re: Is this list dead?

[lx]

On Fri, 13 Sep 2002 11:09:54 +0300 (EEST)
halfdead <halfdead@cannabis.daphnes.ro> wrote:

> Hi guys,
> 
> I have been out for too long and now i see that there is no activity on
> this list. Is it like dead or something?
> 
> - halfdead

nice to know that you still seem just half of what this list is not.
all questions answered, nothing new in the kernel which none understands.

best,
	hp

-- 
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de

Is this list dead?

[Tommy McCabe]

Ummm... yeah.


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 

Re: Is this list dead?

[Jody]

Tommy McCabe wrote:

 > Ummm... yeah.


CLEAR!!!!

*zorch*

w00t!

Jody Bruchon
ELKS Lynx Port "Developer"

Re: Is this list dead?

[Gregg C Levine]

Hello from Gregg C Levine
Not dead, just in hibernation. Anyone remember the line Doctor Who told
Harry, in "Ark in Space"? Well that's the status of this list. Besides, I'm
still mentally chewing over the details for the Project of the Century, for
using the ELKS distribution.
---
Gregg C Levine obiwanthejediknight@att.net
<This signature will be replaced, pending an approval from the Jedi Council.
>

----- Original Message ----- 
From: "Jody" <jbruchon@nc.rr.com>
To: "Linux-8086" <linux-8086@vger.kernel.org>
Sent: Sunday, November 21, 2004 1:45 PM
Subject: Re: Is this list dead?


> Tommy McCabe wrote:
>
>  > Ummm... yeah.
>
>
> CLEAR!!!!
>
> *zorch*
>
> w00t!
>
> Jody Bruchon
> ELKS Lynx Port "Developer"
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is this list dead?

[James Tabor]

Hi,
I'm still around, lurking, not developing much with ELKS.
James

Gregg C Levine wrote:
> Hello from Gregg C Levine
> Not dead, just in hibernation. Anyone remember the line Doctor Who told
> Harry, in "Ark in Space"? Well that's the status of this list. Besides, I'm
> still mentally chewing over the details for the Project of the Century, for
> using the ELKS distribution.
> ---
> Gregg C Levine obiwanthejediknight@att.net
> <This signature will be replaced, pending an approval from the Jedi Council.
> 
> 
> ----- Original Message ----- 
> From: "Jody" <jbruchon@nc.rr.com>
> To: "Linux-8086" <linux-8086@vger.kernel.org>
> Sent: Sunday, November 21, 2004 1:45 PM
> Subject: Re: Is this list dead?
> 
> 
> 
>>Tommy McCabe wrote:
>>
>> > Ummm... yeah.
>>
>>
>>CLEAR!!!!
>>
>>*zorch*
>>
>>w00t!
>>
>>Jody Bruchon
>>ELKS Lynx Port "Developer"
>>

IS THIS LIST DEAD ?

[J.K. Hill]

If its not - where can I get info about porting Linux to an O2 ?

Is there a status of (a) port ? The last thing that I have heard is that the
O200 runs it (but only w/ a modified prom).

Re: IS THIS LIST DEAD ?

[Ralf Baechle]

On Wed, Oct 06, 1999 at 11:03:54AM -0400, J.K. Hill wrote:

> If its not - where can I get info about porting Linux to an O2 ?
> 
> Is there a status of (a) port ? The last thing that I have heard is that the
> O200 runs it (but only w/ a modified prom).

That's complete bull - the is no port yet.

If you actually subscribe to this list it doesn't seem as dead ...

  Ralf