Perl Bindings GSOC Mentors?

[Tekk]

I'm interested in taking on the perl binding gsoc project, but it seems
that there are currently no listed mentors for this project. anyone
want to step up? If not, I'll be willing to try out the python
bindings, assuming that anatoly is still up to it.

GSOC Perl Bindings

[Tekk]

First off, I apologize if you've already read this once, but looking at
the the archive seem to say that the message wasn't believed and I
think there was a race condition between my registering for the list
and the send.

Is anyone around willing to mentor me for the perl bindings project?
I'd be willing to switch to python if no one is available for the
former, since I don't mind either language, I'm just more interested in
picking up perl stuff.

Re: mmap on GNU Hurd

[Jacob Appelbaum]

Thomas Schwinge:
> Hi!
> 
> On Tue, 30 Apr 2013 00:47:47 +, Jacob Appelbaum  
> wrote:
>> I've noticed that mmap() doesn't behave as expected
> 
> There are known issues with mmap, in particular it (currently) doesn't
> work at all on filesystem based on libnetfs (such as NFS, ftpfs, etc.),
> ,
> .
> More details: .  A few
> individual issues filed:
> ,
> .
> And, there's no mremap,
> .
> 
> If you tell us what you're seeing with mmap and what you'd expect to see,
> we should quickly be able to tell "who's at fault".

Hi there,

I'm sure that this is a known issue of sorts or if it isn't it is
probably closely related to one of the above bugs.

Sure - I made a dist tar.gz from git (
https://github.com/ioerror/tlsdate ) tip:
https://people.torproject.org/~ioerror/src/tlsdate-git-tip-dist.tar.gz

It appears that the issue is that when I try to memcpy into my mmap()
created in the parent, the child is unable to write into it properly -
that is - the mmap() is constructed like so:

https://github.com/ioerror/tlsdate/blob/master/src/tlsdate-helper.c#L1115

tlsdate-helper then forks a child process and then attempts to memcpy
into the mmap():

https://github.com/ioerror/tlsdate/blob/master/src/tlsdate-helper.c#L1056

Now - if I inspect the contents of the mmap inside the child process -
sizeof() reports it to be four bytes (expected and the same size as the
32bit uint). However if I print it inside the child, it prints as a very
small integer - it most certainly is not identical to the contents of
ssl->s3->server_random. It gets even weirder from there...

When the child process ends and the parent goes to use it - it is zero.
I've added a clause to ensure that this value is never allowed and so
now on GNU/Hurd it simply fails to get further than this check:

  https://github.com/ioerror/tlsdate/blob/master/src/tlsdate-helper.c#L1194

So far this is good as it caught a bug on all platforms - this value
should never be zero and it shouldn't even attempt to set a clock if the
value is somehow zero. So I've now caught that case - though really it
should ensure the value is sane in a few ways - zero is OK for now but
will likely be extended in the future.

So... whose bug is this anyway? I was planning to just replace mmap()
here with a pipe but now I wonder if this should be fixed in GNU/Hurd or
if a pipe would do the trick in any case?

All the best,
Jacob

Perl Binding GSOC mentors?

[Tekk]

I'm interested in taking on the perl binding gsoc project, but it seems
that there are currently no listed mentors for this project. anyone
want to step up? If not, I'll be willing to try out the python
bindings, assuming that anatoly is still up to it.

Re: Inquiry about GCC Summer Of Code project idea.

[Ian Lance Taylor]

On Tue, Apr 30, 2013 at 6:53 AM, Thomas Schwinge
 wrote:
>
> On  I have just
> updated/posted a getcontext/makecontext/setcontext/swapcontext usage
> analysis.  This might constitute a "road block": the Hurd currently does
> not allow for changing the stack of a process/thread.  Implemented a
> while before TLS/__thread variables came along, we have a legacy
> threadvar mechanism implemented in glibc, which places thread-local
> variables (errno, for example) at the bottom of a thread's stack.  Then,
> when switching the stack of a thread, glibc can't locate these anymore,
> and "bad things" happen.  This threadvar mechanism is scheduled to go
> away (we do implement TLS by now), but when working on that I hit "some
> issues" and have not yet found the time to continue.
> 
> and
> 
> have the details.
>
> Now, it seems the GCC Go port is implemented in a way that makes
> extensive use of switching stacks.  So until this threadvar issue is
> resolved, there is probably no way to really proceed with the GCC Go port
> for GNU Hurd -- unless maybe this stack switching could be hacked around
> (Ian?), say, by limiting oneself to not using Goroutines and similar
> "specials", and having a custom/minimal Go runtime startup.

Go does require switching stacks.  A port of Go that doesn't support
goroutines would be useless--nothing in the standard library would
work.  It might be possible to use pthread_getspecific and friends
instead of TLS.

Ian

Re: Inquiry about GCC Summer Of Code project idea.

[Thomas Schwinge]

Hi!

I'm sorry for the late answer.  Ian, there's a question for you towards
the bottom of the email.

On Mon, 25 Mar 2013 08:22:15 -0700, Ian Lance Taylor  wrote:
> On Mon, Mar 25, 2013 at 7:42 AM, Fotis Koutoulakis
>  wrote:
> >
> > I am writing this email with regard to a potential project idea that's
> > hosted on the GCC wiki about porting the go programming language GCC
> > (gccgo) frontend to the GNU/HURD operating system (information found
> > here-> http://gcc.gnu.org/wiki/SummerOfCode and here->
> > http://www.gnu.org/software/hurd/open_issues/gccgo.html).
> >
> > My specific queries would be:
> >
> > - This particular idea seems to be eligible for this year's Google
> > Summer Of Code. Further research on the GCC wiki shows that this
> > particular idea has never been implemented in the past - or assigned.
> > However, I would like someone else to assert my assumption that this
> > is eligible for this year's GSOC.
> 
> Yes, it is eligible.
> 
> (This is of course no guarantee that this particular project will be
> selected.  It depends on the other proposals we receive.)

As you can see on
, Svante has
been working on this (outside of the GSoC context), but has not yet
published his patches.  (And yet if he did, I'm condfident there'd still
be enough work left for a GSoC project: (continue) porting Go's runtime
library, language/RPC bindings, etc.)

> > - What would be the specific educational and knowledge background that
> > the student who wishes to implement this particular idea should have?
> > I can see mentions of good POSIX API knowledge, go language knowledge
> > and HURD knowledge here, but I would like to know if there would be
> > more requirements regarding this specific project idea that are not
> > immediately obvious.
> 
> I think you're pretty much right.  I think the most important part
> coming in would be a clear understanding of the HURD, its system call
> interface, and its object file format.  You would have to be able to
> dig into the Go library, to understand how implements the system call
> layer.

Yep.  As for understanding of the Hurd, as long as the project doesn't
shift towards the language/RPC bindings, not really too much Hurd
internals should be needed -- use the standard POSIX interface as
exported by glibc.

> > - What would be a skill level estimate for someone wishing to try this
> > project in an attempt to get his feet wet in compiler engineering?
> 
> Unfortunately it's hard for me to judge.  The most important skill
> would be the ability to dig into some large code bases and understand
> how to change them.

Agreed, and as Samuel already followed up, this is not a project that
will require you to know compiler theory proper, or its implementation.


On  I have just
updated/posted a getcontext/makecontext/setcontext/swapcontext usage
analysis.  This might constitute a "road block": the Hurd currently does
not allow for changing the stack of a process/thread.  Implemented a
while before TLS/__thread variables came along, we have a legacy
threadvar mechanism implemented in glibc, which places thread-local
variables (errno, for example) at the bottom of a thread's stack.  Then,
when switching the stack of a thread, glibc can't locate these anymore,
and "bad things" happen.  This threadvar mechanism is scheduled to go
away (we do implement TLS by now), but when working on that I hit "some
issues" and have not yet found the time to continue.

and

have the details.

Now, it seems the GCC Go port is implemented in a way that makes
extensive use of switching stacks.  So until this threadvar issue is
resolved, there is probably no way to really proceed with the GCC Go port
for GNU Hurd -- unless maybe this stack switching could be hacked around
(Ian?), say, by limiting oneself to not using Goroutines and similar
"specials", and having a custom/minimal Go runtime startup.


Grüße,
 Thomas


pgp_AuxlXLLev.pgp
Description: PGP signature

Re: Applying for "Implementing libcap"

[harryxiyou]

On Tue, Apr 30, 2013 at 7:16 PM, harryxiyou  wrote:
> On Tue, Apr 30, 2013 at 5:48 PM, Thomas Schwinge
>  wrote:
>> Hi!
>
> Hi Thomas,
> [...]
>>
>> Nice, so you already have some experience with "systems programming".
>>
>>> Could anyone give me some suggestions for my applying for
>>> "Implementing libcap"?
>>
>> Well, obviously first get some experience with the a Hurd system's
>> structure,
>> ,
>> and generally , and
>> get some user experience -- install a GNU/Hurd system,
>> , maybe start
>> with a KVM/QEMU/VirtualBox image.
>>
>
> Okay, i will try these ones ;-)
>
>> Of course, we're happy to help and answer specific questions.
>>
>> Then, of course, prepare your student application form,

Actually, i am not very familiar with this capability library. I have seen the
capability library of Linux OS but i still not understand it clearly. I usually
use Linux OS for my projects but i cannot feel the exist of capability library.
Would you please give me some explanation with common sense or words?
Thanks in advance ;-)



--
Thanks
Harry Wei

Re: Applying for "Implementing libcap"

[harryxiyou]

On Tue, Apr 30, 2013 at 5:48 PM, Thomas Schwinge
 wrote:
> Hi!

Hi Thomas,
[...]
>
> Nice, so you already have some experience with "systems programming".
>
>> Could anyone give me some suggestions for my applying for
>> "Implementing libcap"?
>
> Well, obviously first get some experience with the a Hurd system's
> structure,
> ,
> and generally , and
> get some user experience -- install a GNU/Hurd system,
> , maybe start
> with a KVM/QEMU/VirtualBox image.
>

Okay, i will try these ones ;-)

> Of course, we're happy to help and answer specific questions.
>
> Then, of course, prepare your student application form,
> ,
> and send it to Google site, in time before this Friday.
>

I will send my application to Google before this Friday ;-)




--
Thanks
Harry Wei

Re: Clean up Mach Google Summer Of Code

[Thomas Schwinge]

Hi Josh!

On Thu, 18 Apr 2013 01:18:15 +0200, Samuel Thibault  
wrote:
> Joshua Branson, le Mon 15 Apr 2013 22:49:22 -0400, a écrit :
> > Should I be focused only on fixing compiler
> > warnings, unneeded variables, removing or modify strange code?
> 
> As the subject says, it's actually quite open, so it is not necessarily
> focused.  But you can try to focus on these for a start, and see what
> else comes through this.
> 
> > There are numerous errors I could start to fix, but I do not want to
> > dive in with no sense of direction.
> 
> Well, you'll have to dive someday :) But it can be better to ask
> advice about what could be easiest to begin with.
> 
> For instance "implicit declaration of function", "format ‘%lu’
> expects argument of type..." are easy to start with.

Indeed for an project as open as this, we can't expect you to come up
with a definitive list of items you're to complete, and the time needed
for doing that.  I think it should be enough if you identify some
specific items that can be worked on (for example, certain classes of
compiler warnings, identifying and ripping out unused functionality, make
the code "more readable").

> > Any ideas where or how I can start
> > cleaning of GNU mach? Or perhaps
> > I should ask, where I should look to find an answer.
> 
> You can come on the #hurd IRC channel, in the freenode network, and ping
> people there (make sure to wait for them to wake up, we are not 24/24 in
> front of our IRC client).

Well, you can easily start by sending a patch to fix one specific
compiler warning.


Don't forget to prepare your student application form,
,
and send it to Google site, in time before this Friday.


Grüße,
 Thomas


pgpmkrdCZT_3E.pgp
Description: PGP signature

Re: Applying for "Implementing libcap"

[Thomas Schwinge]

Hi!

On Thu, 25 Apr 2013 21:03:46 +0800, harryxiyou  wrote:
> I wanna apply for "Implementing libcap" and
> finish this project idea during GSOC 2013.

Thanks for your interest!

> Following are my basic infomations.  [...]

Nice, so you already have some experience with "systems programming".

> Could anyone give me some suggestions for my applying for
> "Implementing libcap"?

Well, obviously first get some experience with the a Hurd system's
structure,
,
and generally , and
get some user experience -- install a GNU/Hurd system,
, maybe start
with a KVM/QEMU/VirtualBox image.

Of course, we're happy to help and answer specific questions.

Then, of course, prepare your student application form,
,
and send it to Google site, in time before this Friday.


Grüße,
 Thomas


pgp5kbaYMcSIf.pgp
Description: PGP signature

Re: [PATCH,HURD] Fix reading core

[Thomas Schwinge]

Hi!

On Tue, 9 Apr 2013 16:41:17 -0700, Joel Brobecker  wrote:
> > The i386 GNU/Hurd ELF core format actually follows the uaccess gregset_t
> > array format, not the Mach thread state format.  This fixes gdb reading
> > it.
> > 
> > * gdb/i386gnu-nat.c (CREG_OFFSET): New macro.
> > (creg_offset): New array.
> > (CREG_ADDR): Use creg_offset instead of reg_offset.

In context with the related Hurd patch,
,
I have now reviewed, tested, and committed this patch.

> Do you have write access to the GDB repository?

Samuel asked me to commit it on his behalf (and likewise his other patch,
once reviewed).

> do you have
> copyright assignment papers on file?

This has been completed.

> > --- a/gdb/i386gnu-nat.c.original2013-02-11 00:46:02.0 +
> > +++ b/gdb/i386gnu-nat.c 2013-02-11 00:48:09.0 +
> > @@ -56,8 +56,21 @@
> >REG_OFFSET (ds), REG_OFFSET (es), REG_OFFSET (fs), REG_OFFSET (gs)
> >  };
> >  
> > +/* Offset to the greg_t location where REG is stored.  */
> > +#define CREG_OFFSET(reg) (REG_##reg * 4)
> > +
> > +/* At CREG_OFFSET[N] is the offset to the greg_t location where
> > +   the GDB register N is stored.  */
> > +static int creg_offset[] =
> > +{
> > +  CREG_OFFSET (EAX), CREG_OFFSET (ECX), CREG_OFFSET (EDX), CREG_OFFSET 
> > (EBX),
> > +  CREG_OFFSET (UESP), CREG_OFFSET (EBP), CREG_OFFSET (ESI), CREG_OFFSET 
> > (EDI),
> > +  CREG_OFFSET (EIP), CREG_OFFSET (EFL), CREG_OFFSET (CS), CREG_OFFSET (SS),
> > +  CREG_OFFSET (DS), CREG_OFFSET (ES), CREG_OFFSET (FS), CREG_OFFSET (GS)
> > +};
> 
> Unless it was done on purpose, we try to limit the size of lines
> to 70 characters, only extending it to up to 80 when it makes
> a difference

I left this as is; the idea is to keep it visually comparable to the
reg_offset definition just above (same sequence of registers; see the
first line of the patch's context).


Grüße,
 Thomas


pgpk97Wo2p_VB.pgp
Description: PGP signature

Re: [GSoC2013] question about "improve the GDB port for GNU Hurd"

[Thomas Schwinge]

Hi!

On Tue, 30 Apr 2013 00:54:26 +0800, 陆岳  wrote:
> I am interested in participating GsoC 2013 with GNU Hurd for improve
> the GDB Port for GNU Hurd.

Thanks for your interest!

> Write this email I mainly to identify which work should I do in this
> project. just Port gdbserver or something else?

Well, as I said in the announcement email,
, and as reflected on
the project idea page,
,
that is basically up for negotiation with the community, the mentor, and
the student.

> Last  may I introduce myself, my name is Yue Lu who is a second-year
> MS student in CS from Tongji University in China. I have worked as a
> FTE  in a company which produce embed-device.
> What's plus, I had experience with linux kernel programming. And I
> know GDB was use ptrace  to commutate with linux kernel.
> Sadly say, I have't enough knowledge about Hurd, but I have great
> enthusiasm to learn that.

Then I suggest you turn that enthusiasm into productivity ;-) -- install
a GNU/Hurd system,
, maybe start
with a KVM/QEMU/VirtualBox image, and do a first run of the GDB testsuite
(please locally apply the attached patch to disable some testcases that
currently cause issues as described).
 can help with how
to configure GDB, and so on.  In parallel, please get an understanding
how, roughly, the Hurd port of GDB works and interacts with the Hurd
system.

Of course, we're happy to help and answer specific questions.


Grüße,
 Thomas


diff --git gdb/testsuite/gdb.base/readline.exp gdb/testsuite/gdb.base/readline.exp
index 2acc664..538dcc6 100644
--- gdb/testsuite/gdb.base/readline.exp
+++ gdb/testsuite/gdb.base/readline.exp
@@ -17,6 +17,9 @@
 
 # This file is part of the gdb testsuite.
 
+untested ""
+return -1
+
 #
 # Tests for readline operations.
 #
diff --git gdb/testsuite/gdb.base/sigall.exp gdb/testsuite/gdb.base/sigall.exp
index 4bd0427..b49fe5b 100644
--- gdb/testsuite/gdb.base/sigall.exp
+++ gdb/testsuite/gdb.base/sigall.exp
@@ -13,6 +13,9 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see .
 
+untested "takes ages: nearly all FAIL with timeout"
+return -1
+
 if [target_info exists gdb,nosignals] {
 verbose "Skipping sigall.exp because of nosignals."
 continue
diff --git gdb/testsuite/gdb.python/py-inferior.exp gdb/testsuite/gdb.python/py-inferior.exp
index ceb0da7..ba98aa8 100644
--- gdb/testsuite/gdb.python/py-inferior.exp
+++ gdb/testsuite/gdb.python/py-inferior.exp
@@ -66,6 +66,9 @@ gdb_breakpoint check_threads
 gdb_continue_to_breakpoint "cont to check_threads" ".*pthread_barrier_wait.*"
 gdb_test "python print (len (i0.threads ()))" "\r\n9" "test Inferior.threads 2"
 
+untested "the following tests get the system into an unresponsive state"
+return -1
+
 # Proceed to the next test.
 
 gdb_breakpoint [gdb_get_line_number "Break here."]


pgpxbM_DHJsPA.pgp
Description: PGP signature

mmap on GNU Hurd

[Thomas Schwinge]

Hi!

On Tue, 30 Apr 2013 00:47:47 +, Jacob Appelbaum  wrote:
> I've noticed that mmap() doesn't behave as expected

There are known issues with mmap, in particular it (currently) doesn't
work at all on filesystem based on libnetfs (such as NFS, ftpfs, etc.),
,
.
More details: .  A few
individual issues filed:
,
.
And, there's no mremap,
.

If you tell us what you're seeing with mmap and what you'd expect to see,
we should quickly be able to tell "who's at fault".


Grüße,
 Thomas



pgpUsR6nIrXKY.pgp
Description: PGP signature