[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Participation

From: LRN
Subject: Re: Participation
Date: Fri, 14 Mar 2014 23:56:21 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Thunderbird/30.0a1

Hash: SHA1

On 14.03.2014 22:02, Raghav Pande wrote:
> On 14.03.2014 11:10, LRN wrote:
>> On 14.03.2014 1:15, Raghav Pande wrote:
>>> Hi, I am an undergrad Computer Science student. My interests 
>>> include programming, reverse engineering. So far i have looked
>>> up ideas list in gnu, gdb, wget, libc, gnu net. These projects
>>> are interesting enough for me to work on them, and i have had
>>> past experience in programming under windows. Though the
>>> learning curve won't be steep, i still have got no clue as to
>>> which project i should work upon. Can anyone point me to right
>>> direction?
>> [snip]
>> As for gdb, libc, etc, i'll let other projects' developers speak
>> for themselves. That said, it'll be simply awesome for someone to
>> take a stab at gdb on Windows (there are lots of improvements
>> that could be made there, such as better stack unwinding, support
>> for MS debug info format - and that would require reverse
>> engineering!).
> i always considered windbg, debug, ollydbg (windows) to be better
> than gdb. might be i am wrong since too many people use gbd. so i
> don't think i'll be working on gdb for windows however it can be
> done.

Well, you did mention gdb specifically, and did say that you've had
W32 programming experience, so i figured you'd want that kind of project.

Also, while you seem to be interested in the GNU project, i'm not sure
you grasp the concept of free software, since you seem to consider
free software debugger as not being worthy of development because
existing proprietary debuggers are better (or maybe you didn't
communicate your thoughts clearly enough, there's always that

>> There's also a possibility to teach gcc to use Windows threading
>> model in order to provide C11/C++ threading support without
>> relying on winpthreads compatibility layer (that layer comes
>> under MIT license that some weirdos find too restrictive). Just
>> some things off the top of my head.
> can you elaborate more on threading models? i didn't quite get what
> you meant, simply because i have only used pthreads on *nix
> environments. while windows has native api's like NtCreateThread to
> do that.

libgcc/libstdc++ got threading support code not long ago, to implement
support for threading built into new C/C++ language standards.
However, gcc only ever implemented that support on top of POSIX
threading model (i.e. it uses pthreads interface). Obviously, W32
doesn't have pthreads, it has CreateThread() and other W32 API
functions, so threading support simply can't be compiled as is.

The obvious and simple measure of fixing that was to take a pthread
compatibility layer (winpthreads) and stick it between gcc and
Windows, so that gcc can still use POSIX threads API, while underneath
winpthreads converts those into W32 API and/or NT API calls.

A better (somewhat) solution is to extend gcc threading support code
to work with W32/NT API directly and eliminate the need for a
compatibility layer. At least, that's the idea.

Anyway, i did speak to ktietz about it, and he said that both of these
ideas may be too difficult for a GSoC student. He also suggested the
affiliated ReactOS and/or Wine projects as places where a developer
with your skillset (reverse engineering, W32 programming) is probably
required. If you hear nothing from other GNU projects, you know where
to go now.

And yes, please do reply to individual messages, not to digests. If
you've only subscribed to receive digests, change your subscription
settings. Or use web interface. Or whatever. And trim down the text
you quote, leaving only relevant parts.

- -- 
O< ascii ribbon - stop html email! -
Version: GnuPG v1.4.11 (MingW32)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]