Re: SIGILL under gdb for AIX 64 bit binaries

[Jonas Maebe <jonas dot maebe at elis dot ugent dot be>]

On 15 Dec 2014, at 09:12, navin p wrote:

>       When i run a program on command line it runs fine. But when i
> run it gdb it gives me a SIGILL.
>       I know that is a problem with the code because dbx for AIX also
> gives the SIGILL instruction.
>       But i've been not able to convince people in my organization it
> is a problem with code.

Executing an instruction is a standard technique to determine whether  
the cpu supports it (e.g. to detect whether an ARM cpu supports  
prefetching instructions). The way this works is that the program  
installs a signal handler for the SIGILL signal, executes the  
potentially unsupported instruction, and sets a global variable inside  
the signal handler, and then returns to the instruction after the  
unsupported instruction. So by checking that variable after attempting  
to execute that instruction, you can know whether the cpu supported it  
or not.

>       What they do is they 'c' (continue) in gdb when it hits a
> SIGILL and keep on continuing 2 times until it crashes somewhere else
> in the code.
>
>       I wanted to know these 2 questions :
>
>       1) Once it hits a SIGILL can we continue and go to the next
> crash and so on ? Is this valid .
>
>        2) How does gdb allow to continue on a SIGILL ?

type
  handle SIGILL

You will see something like

Signal        Stop	Print	Pass to program	Description
SIGILL        Yes	Yes	Yes		Illegal instruction

"Stop = Yes" means that gdb will stop when the program triggers a  
SIGILL. "Print = Yes" means that gdb will print a message telling you  
that it stopped because of a SIGILL. "Pass to program = Yes" means  
that after you continue the execution, the SIGILL will be passed on to  
the program itself, so that its SIGILL handler will be executed. If it  
did not install a SIGILL handler, it will simply be killed.

This means that if your program keeps executing once you continue  
after receiving a SIGILL, it handled the SIGILL in a signal handler  
and continued normally. As a result, it's probably expected behaviour.


Jonas