Re: Participation

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
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
possibility).

> 
>> 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! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJTI17lAAoJEOs4Jb6SI2Cw4AUIAM/KN3xU5t3Axf1C7tOeqVMk
yyjjdQi+C1x2Wm8P74430nPz2S1Rvdnk/W8GXoh2/VANsFKdFkBiglr2j0UytwZf
62qcEzhcyI3pbcT3+xI84DkU4gnCUi+53V+sN0cD4o96mr+LEmmr6doqfRlWneKX
Op6jJ576HBhpBALSV1m4ggt1POhiQcccCFRaGH+adPvVchScrn8qPy6QJkX67p3S
+mc6jJsqcXuBQIycls0diqT+/vM5z+8GIR5u+kqpQVMaiJD5LoI1wWeN5eUPYGqg
qFW0cV39CICIAXVjonOA31r4SVJdyZK+9x+mXYdS1PLIDobkSvYR8YbST2xhQYI=
=3ejb
-----END PGP SIGNATURE-----