Hello friends,

I'm writing a program in C with some bits in inline asm for efficiency.
I'd like to be able to handle illegal instructions from within asm.

Here's an example of a standalone asm program,

..data

..text

..globl _start
_start:

..byte 0xff
..byte 0xff
..byte 0xff

movl $1,%eax
movl $0,%ebx
int $0x80

This generates an illegal instruction but I'd like to be able to ignore
that.

Thanks.

Just another C hacker wrote:
> Hello friends,
>
> I'm writing a program in C with some bits in inline asm for efficiency.
> I'd like to be able to handle illegal instructions from within asm.
>
> Here's an example of a standalone asm program,
>
> .data
>
> .text
>
> .globl _start
> _start:
>
> .byte 0xff
> .byte 0xff
> .byte 0xff
>
> movl $1,%eax
> movl $0,%ebx
> int $0x80
>
> This generates an illegal instruction but I'd like to be able to ignore
> that.
>
> Thanks.

Whan I assemble your program with lcc-win I get
Section Hex Dumps
section 00 (.text) size: 00016 file offs: 00140
[0000000] ff (bad)
[0000001] ff (bad)
[0000002] ff (bad)
[0000003] b801000000 mov $0x1,%eax
[0000008] bb00000000 mov $0x0,%ebx
[0000013] cd80 int $0x80
[0000015] 90 nop

You have 3 illegal instructions, not one.
And why you add them in the first place?

Wouldn't it be better to delete the 3
..byte ff
???????

Anyway this is quite off topic here, we deal with C.
You should go to the group

comp.lang.asm.x86

On 11 Apr 2008 at 12:20, jacob navia wrote:
> Just another C hacker wrote:
>> Hello friends,
>>
>> I'm writing a program in C with some bits in inline asm for efficiency.
>> I'd like to be able to handle illegal instructions from within asm.
[snip]
>> This generates an illegal instruction but I'd like to be able to ignore
>> that.
>
> You have 3 illegal instructions, not one.
> And why you add them in the first place?
>
> Wouldn't it be better to delete the 3
> .byte ff
> ???????

Jacob is right that what you're asking doesn't seem to make much sense -
maybe if you explain what you're ultimately trying to achieve then that
would .

If you just want to catch illegal instructions, then you can use the C
signal function to install a handler for SIGILL (which has numerical
value 4).

Look I don't think it's any of your business what I'm doing, either
answer the question or don't bother.

Yeah signal is ok, but it doesn't let me know which was the address of
the illegal operation that was attempted.


Antoninus Twink wrote:
> On 11 Apr 2008 at 12:20, jacob navia wrote:
>
>>Just another C hacker wrote:
>>
>>>Hello friends,
>>>
>>>I'm writing a program in C with some bits in inline asm for efficiency.
>>>I'd like to be able to handle illegal instructions from within asm.
>
> [snip]
>
>>>This generates an illegal instruction but I'd like to be able to ignore
>>>that.
>>
>>You have 3 illegal instructions, not one.
>>And why you add them in the first place?
>>
>>Wouldn't it be better to delete the 3
>>.byte ff
>>???????
>
>
> Jacob is right that what you're asking doesn't seem to make much sense -
> maybe if you explain what you're ultimately trying to achieve then that
> would .
>
> If you just want to catch illegal instructions, then you can use the C
> signal function to install a handler for SIGILL (which has numerical
> value 4).
>

Just another C hacker wrote:
> Look I don't think it's any of your business what I'm doing, either
> answer the question or don't bother.
>

Look Mr "hacker"
You add illegal instructions and then you want to ignore it...
Fine, you want to screw some program, build some virus,
crash some stuff.

OK.

But do not expect from me in this forum.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Richard Tobin wrote:
> In article <ftnr2q$hkl$1@aioe.org>, Just another C hacker <no@spam.com> wrote:
>
>> Look I don't think it's any of your business what I'm doing, either
>> answer the question or don't bother.
>
> What's in it for us?
>
> -- Richard

Well, if the virus works you will get one!

:-)

The only thing we gain here is YASV!
YET ANOTHER STUPID VIRUS!


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

In article <ftnr2q$hkl$1@aioe.org>, Just another C hacker <no@spam.com> wrote:

>Look I don't think it's any of your business what I'm doing, either
>answer the question or don't bother.

What's in it for us?

-- Richard
--
:wq

On 11 Apr 2008 at 14:03, Just another C hacker wrote:
> Yeah signal is ok, but it doesn't let me know which was the address of
> the illegal operation that was attempted.

If you're using assembler, why not just navigate back up the call stack
to the frame before the handler was called?

In article <ftnrlj$jbh$2@aioe.org>, jacob navia <jacob@nospam.org> wrote:
>Richard Tobin wrote:

>>> Look I don't think it's any of your business what I'm doing, either
>>> answer the question or don't bother.

>> What's in it for us?

>Well, if the virus works you will get one!

Ah yes, that does look quite possible. If he wants writing
viruses, my rates are double, plus indemnity.

-- Richard
--
:wq

Antoninus Twink wrote:
> On 11 Apr 2008 at 14:03, Just another C hacker wrote:
>> Yeah signal is ok, but it doesn't let me know which was the address of
>> the illegal operation that was attempted.
>
> If you're using assembler, why not just navigate back up the call stack
> to the frame before the handler was called?
>

He needs to add 3 illegal instructions to find out the portion
of the code where the call was done. The 3 illegal instructions
are a *marker* for later reference.

This looks like a highly suspect operation. I know what he
should do (it is *obvious* if you know assembler) but I will
not tell him.

1) Anonymous post
2) Highly suspect operations
3) Secrecy paranoia ("None of your business")

I am not for flaming people here that ask legitimate questions
but this one is a virus writer, sorry.



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Antoninus Twink <nospam@nospam.invalid> writes:
[...]
> If you just want to catch illegal instructions, then you can use the C
> signal function to install a handler for SIGILL (which has numerical
> value 4).

There is no reason to assume that SIGILL is 4, no benefit in doing so
(the macro exists precisely so you don't have to assume a particular
value), and no guarantee that the system will raise the signal under
any circumstances other than an explicit call to raise().

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 11 Apr 2008 at 16:45, Keith Thompson wrote:
> Antoninus Twink <nospam@nospam.invalid> writes:
> [...]
>> If you just want to catch illegal instructions, then you can use the C
>> signal function to install a handler for SIGILL (which has numerical
>> value 4).
>
> There is no reason to assume that SIGILL is 4, no benefit in doing so
> (the macro exists precisely so you don't have to assume a particular
> value),

In C, it's certainly preferable to #include <signal.h> and use the
symbolic constant. However, the context was that the OP was using
assembler, so he'd have to specify the int argument to signal() as an
explicit integer pushed onto the stack before calling the function.

> and no guarantee that the system will raise the signal under
> any circumstances other than an explicit call to raise().

I believe POSIX guarantees the signal will be raised upon detection of
an invalid or illegal hardware instruction.

In article <slrnfvv648.qsr.nospam@nospam.invalid>,
Antoninus Twink <nospam@nospam.invalid> wrote:
>On 11 Apr 2008 at 16:45, Keith Thompson wrote:
>> Antoninus Twink <nospam@nospam.invalid> writes:
>> [...]
>>> If you just want to catch illegal instructions, then you can use the C
>>> signal function to install a handler for SIGILL (which has numerical
>>> value 4).

>> There is no reason to assume that SIGILL is 4

>In C, it's certainly preferable to #include <signal.h> and use the
>symbolic constant. However, the context was that the OP was using
>assembler, so he'd have to specify the int argument to signal() as an
>explicit integer pushed onto the stack before calling the function.

POSIX.1 guarantees only that the signal numbers are distinct
positive integers; their numeric values are unspecified by POSIX.1
and can vary from system to system.


>> and no guarantee that the system will raise the signal under
>> any circumstances other than an explicit call to raise().

>I believe POSIX guarantees the signal will be raised upon detection of
>an invalid or illegal hardware instruction.

"detection" is a key word here: the implementation need not be able
to "detect" the problem in a manner that can allow it to generate
a signal.

SIGILL is a "required" POSIX.1 signal, but the POSIX.1-1989 wording
is not clear as to whether that means that a compliant system -must-
raise the signal under those circumstances, or whether it just means
that SIGILL must be in its signals.h header in case kill() or raise()
specifying SIGILL get called.

POSIX.1-1989 says that the behaviour upon return from a signal handler
for SIGILL is unspecified -- e.g., there are no POSIX.1 mechanisms to say
"leave signal-handler status and pick up execution at instruction
address P."
--
"Beauty, like all other qualities presented to human experience,
is relative; and the definition of it becomes unmeaning and
useless in proportion to its abstractness." -- Walter Pater

On 11 Apr 2008 at 17:38, Walter Roberson wrote:
> SIGILL is a "required" POSIX.1 signal, but the POSIX.1-1989 wording
> is not clear as to whether that means that a compliant system -must-
> raise the signal under those circumstances, or whether it just means
> that SIGILL must be in its signals.h header in case kill() or raise()
> specifying SIGILL get called.
>
> POSIX.1-1989 says that the behaviour upon return from a signal handler
> for SIGILL is unspecified -- e.g., there are no POSIX.1 mechanisms to say
> "leave signal-handler status and pick up execution at instruction
> address P."

I am not a language lawyer, but I think it's clear from the context (the
OP was writing asm and trying to use a specially-placed illegal
instruction as some sort of marker, for an unknown reason, possibly
nefarious) that the OP was happy to rely on system-specific behavior for
POSIX signal-handling functions.

As it happens, in this particular case every sane implementation will
produce a SIGILL for an illegal operation, and by playing with the stack
pointer it will be possible to resume from near the illegal operation.
Probably the regulars here will worry about their
strictly-POSIX-compliant Deathstations, but as so often that will be of
precisely zero to the OP.

In article <87r6dc9w7c.fsf@kvetch.smov.org>,
Keith Thompson <kst-u@mib.org> accidentally responded to known "troll"
Antoninus T, thusly:
>Antoninus Twink <nospam@nospam.invalid> writes:
>[...]
>> If you just want to catch illegal instructions, then you can use the C
>> signal function to install a handler for SIGILL (which has numerical
>> value 4).
>
>There is no reason to assume that SIGILL is 4, no benefit in doing so
>(the macro exists precisely so you don't have to assume a particular
>value), and no guarantee that the system will raise the signal under
>any circumstances other than an explicit call to raise().

Does this mean that Keith really doesn't have A.T. kf'd, after all?
Or has his notoriously well kept killfile sprung a leak?

P.S. It looks like Roberson has slipped as well.

Antoninus Twink wrote:
> On 11 Apr 2008 at 17:38, Walter Roberson wrote:
>> SIGILL is a "required" POSIX.1 signal, but the POSIX.1-1989 wording
>> is not clear as to whether that means that a compliant system -must-
>> raise the signal under those circumstances, or whether it just means
>> that SIGILL must be in its signals.h header in case kill() or raise()
>> specifying SIGILL get called.
>>
>> POSIX.1-1989 says that the behaviour upon return from a signal handler
>> for SIGILL is unspecified -- e.g., there are no POSIX.1 mechanisms to say
>> "leave signal-handler status and pick up execution at instruction
>> address P."
>
> I am not a language lawyer, but I think it's clear from the context (the
> OP was writing asm and trying to use a specially-placed illegal
> instruction as some sort of marker, for an unknown reason, possibly
> nefarious) that the OP was happy to rely on system-specific behavior for
> POSIX signal-handling functions.
>
> As it happens, in this particular case every sane implementation will
> produce a SIGILL for an illegal operation, and by playing with the stack
> pointer it will be possible to resume from near the illegal operation.
> Probably the regulars here will worry about their
> strictly-POSIX-compliant Deathstations, but as so often that will be of
> precisely zero to the OP.
>

I think your answer was technically correct and the regulars are wrong
by trying to put forward C portability assumptions for an assembler
program (!!!!!!!)

You did the right thing. What make me more suspicious was his reaction
"none of your business"...

>> I am not a language lawyer, but I think it's clear from the context (the
>> OP was writing asm and trying to use a specially-placed illegal
>> instruction as some sort of marker, for an unknown reason, possibly
>> nefarious) that the OP was happy to rely on system-specific behavior for
>> POSIX signal-handling functions.
>>
>> As it happens, in this particular case every sane implementation will
>> produce a SIGILL for an illegal operation, and by playing with the stack
>> pointer it will be possible to resume from near the illegal operation.

"near" may not be good enough here, and it's a real problem.

At the assembly language level, a typical CPU that even *has* an
illegal instruction trap (on some CPUs, all bit combinations are
legal), will trap and leave the saved program counter (or whatever
it's called) pointed at the offending illegal instruction. Some
will leave the saved program counter pointed at the *next* instruction.
(Figuring out the previous instruction in the presence of variable-length
instructions sometimes leaves ambiguity). Some will do one or the
other depending on various stuff.

S/370 had a couple of "instruction length bits" that were supposed
to let you figure out what the trapping instruction was, given a
pointer to the NEXT one. Unless they were both 0, in which case
you had an "imprecise exception", and you couldn't. "imprecise
exceptions" are primarily caused by extensive pipelining where it's
really hard to figure out where the problem occurred, and modern
processors have the problem more than something as old as S/370.

Even if the saved program counter points at the offending instruction,
it may not be trivial given (a) the saved program counter and (b)
as many bytes starting at that location that are relevant to figure
out where the next instruction starts, although this isn't nearly
as hard as backing up.

Signal handlers don't provide a way to exit them to a particular
place. (The closest would seem to be longjmp() out of a signal
handler, but that may not be sufficient to allow the signal to
happen again.) It's quite possible that if you trap on a special
illegal instruction, and return from the SIGILL handler, that you
immediately trap on that same instruction AGAIN, over and over.
I don't think that is what the OP wanted.

jacob navia wrote, On 11/04/08 19:08:
> Antoninus Twink wrote:
>> On 11 Apr 2008 at 17:38, Walter Roberson wrote:
>>> SIGILL is a "required" POSIX.1 signal, but the POSIX.1-1989 wording

<snip>

>> As it happens, in this particular case every sane implementation will
>> produce a SIGILL for an illegal operation, and by playing with the stack
>> pointer it will be possible to resume from near the illegal operation.
>> Probably the regulars here will worry about their
>> strictly-POSIX-compliant Deathstations, but as so often that will be of
>> precisely zero to the OP.
>
> I think your answer was technically correct and the regulars are wrong
> by trying to put forward C portability assumptions for an assembler
> program (!!!!!!!)

Well, the OP did not specify POSIX so it could be a virus for Windows or
even a DOS virus! Maybe it is for an embedded x86 system and there is no OS!

> You did the right thing.

Actually, you did the right thing on your earlier response where you
redirected the poster to comp.lang.asm.x86 and that should have been the
end of the thread.

> What make me more suspicious was his reaction
> "none of your business"...

Oh indeed.
--
Flash Gordon

Just another C hacker wrote:
>
> Look I don't think it's any of your business what I'm doing, either
> answer the question or don't bother.
>
> Yeah signal is ok, but it doesn't let me know which was the address
> of the illegal operation that was attempted.

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

--
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/> (taming google)
<http://members.fortunecity.com/nnqweb/> (newusers)

** Posted from http://www.teranews.com **

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:480076DE.433713C5@yahoo.com...
> Just another C hacker wrote:
>>
>> Look I don't think it's any of your business what I'm doing, either
>> answer the question or don't bother.
....
>
> Please do not top-post. Your answer belongs after (or intermixed
> with) the quoted material to which you reply, after snipping all
> irrelevant material. See the following links:

You make it sound like Just's reply would have been been perfectly
acceptable otherwise.

Sometimes it's necessary to ask additional questions of posters and a rebuke
like the above would put some people off.

Or are your posts generated automatically so that the actual content you
reply to is irrelevant?

--
Bart