OSDev.org

The Place to Start for Operating System Developers
It is currently Sat May 18, 2024 8:02 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: Newlib raise() - multiple definitions?
PostPosted: Sat Sep 22, 2007 4:25 am 
Offline
Member
Member
User avatar

Joined: Tue Jul 10, 2007 5:27 am
Posts: 2935
Location: York, United Kingdom
I've ported newlib, and was having trouble working out exactly how I was supposed to find out what function a user had registered as a signal handler. As far as I could see, raise() (send signal to the current process) mapped immediately through to kill(getpid(), sig), and there were no macros to get signal functions etc (sigaction isn't implemented in newlib).

So anyway, I decided to write a small test program:
Code:
void func(int sig)
{
  printf("Recieved signal: %d\n", sig);
}

... in main
signal(10, &func);
raise(10);


I ran it, and lo and behold it worked perfectly! Putting trace code into my kill() function (which was a stub) showed it wasn't being called at all - strange.

I then did a grep -r "_raise_r" ./libc/ in case I was missing something. I was. There is a *second* definition of raise(), in signal.c. This one calls a locally defined handler if one exists.

So, my question is - does anyone know why there are two definitions of the same function in two different files in the same directory: raise.c and signal.c ??

It seems strange.

Cheers,
JamesM

_________________
Horizon - a framework and language for SAS-OS development
Project 'Pedigree'
Practical x86 OSDev tutorials


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 22, 2007 8:54 am 
Offline
Member
Member

Joined: Mon Apr 09, 2007 12:10 pm
Posts: 775
Location: London, UK
The one in signal.c is included in the build if the macro SIGNAL_PROVIDED is not defined. This provides a user-space emulation of raise() and signal() such that the only way to signal a process is to call raise() within that process (or its libraries) and is provided as an emulation for small embedded systems.

The one in raise.c is included if SIGNAL_PROVIDED is defined. This does not cause a signal() to be implemented (you must provide it) and it provides a stub raise, which calls the system call kill() which again you must provide.

Basically, either define SIGNAL_PROVIDED (and have configure detect it somehow) and provide kill() and signal() or just let newlib provide its own implementations. If you usethe newlib ones, though, you must ensure crt0 calls _init_signal. Need to add that to the wiki article at some point...

Regards,
John.

edit: You can add newlib_cflags="${newlib_cflags} -DSIGNAL_PROVIDED" to your host definition in newlib/configure.host if you're following [wiki]OS Specific Toolchain[/wiki]. Editing the article is on my todo list when I get a chance.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 22, 2007 9:35 am 
Offline
Member
Member
User avatar

Joined: Tue Jul 10, 2007 5:27 am
Posts: 2935
Location: York, United Kingdom
Cheers for that. I hadn't seen the #ifdef SIGNALS_PROVIDED. Make sense.

_________________
Horizon - a framework and language for SAS-OS development
Project 'Pedigree'
Practical x86 OSDev tutorials


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 13 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group