[lldb-dev] SIG values in driver\Platform.h

Zachary Turner zturner at google.com
Mon May 26 09:52:24 PDT 2014


Ahh, I see.  Windows signal() only supports a subset of possible signals.
 But still, shouldn't the #define'd values match the numerical values on
other platforms?


On Mon, May 26, 2014 at 2:01 AM, Colin Riley <colin at codeplay.com> wrote:

>  The Visual Studio signal.h does not include those signals, so that's
> probably the case. I wouldn't call it a bug.
>
> Due to the different toolchain options available to windows, the config
> paths are quite messy. It would be great getting them cleaned up, but
> whilst we don't have windows buildbots up I think it's just going to end in
> broken TOT for at least one configuration option.
>
> Colin
>
>
> On 25/05/2014 06:56, Zachary Turner wrote:
>
> I'm working on cleaning getting rid of all warnings durings a Windows
> build (there are currently thousands), and I've found something unusual in
> tools\driver\Platform.h.  _INC_SIGNAL is explicitly defined with a comment
> indicating that the purpose is so that signal.h is not included, and then
> specific values from signal.h are defined.
>
>  My first question is why not just include signal.h?  Since there is a
> comment here it's clearly intentional, so I'd like to understand the
> reasoning before just removing this and including signal.h. I thought maybe
> it was because some compilers on Windows supported signal.h and others
> didn't, but then in Platform.cpp there is a comment that says "this file is
> only relevant for Visual C++".  So that's not it either.
>
>  My second question is regarding the values of some of the constants.
>  Specifically, these:
>
>      #define SIG_DFL ( (sighandler_t) -1 )
>      #define SIG_IGN ( (sighandler_t) -2 )
>
>      #define SIGCONT  18
>      #define SIGTSTP  20
>
>  These are actually not the correct values.  SIG_DFL is 0, SIG_IGN is 1,
> SIGCONT is 19, and SIGTSTP is 18.  Can I assume this is a bug?   Note that,
> again, simply including signal.h would fix this, so this goes back to my
> first question about the reasoning behind not including it.
>
>  Thanks,
> Zach
>
>
> _______________________________________________
> lldb-dev mailing listlldb-dev at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
> --
> - Colin Riley
> Games Technology Director
>
> Codeplay Software Ltd
> 45 York Place, Edinburgh, EH1 3HP
> Tel: 0131 466 0503
> Fax: 0131 557 6600
> Website: http://www.codeplay.com
> Twitter: https://twitter.com/codeplaysoft
>
> This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
> As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
> Company registered in England and Wales, number: 04567874
> Registered office: 81 Linkfield Street, Redhill RH1 6BY
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140526/189e0813/attachment.html>


More information about the lldb-dev mailing list