Re: Inquiry about GCC Summer Of Code project idea.

[Fotis Koutoulakis]

Hello Thomas,

First of all, I would like to thank you for your feedback. It means a lot
to me.

> Replacing the (legacy) threadvars
> mechanism with TLS shall not really be your project; yours is to port Go
> (or more specifically, its runtime library) to GNU Hurd.

I do understand this, but if you believe this would not take me out of my
schedule,
I would like to attempt this, as I am given the impression that this is
important for the HURD.
If you believe it would be too hard to do this along with the main
assignment, I could scrap it
if there would be a viable work around - or if you believe it's beyond my
skills.

> As an obvious preparatory task (which in a way is also present in your
> Estimated Project Timeline, Before May 15): have you been able to
> complete a build of GCC for/on GNU/Hurd, and (roughly) reproduced my
> current test results, as per my notes on

Yes, I am on it. Not yet finished, but I am very close to have a working
environment on top of Debian GNU/HURD.

> I think I have found a way so that we can hack around that problem on the
> Hurd/glibc side (that is, implement the setcontext et al. function in the
> threadvars environment) until we're able to address the issue properly
> (replace threadvars with TLS proper).  Not yet implemented and tested,
> but I'm on it; slowly, time is limited.

Again, since my first assignment is to port the go frontend to the HURD, I
could use that work around.
However, keep in my mind, that my objective is not do simply "do
something", I want to do useful work,
so unless I am seriously time constrained, I would like to help advance the
HURD
by doing some infrastructure work on it.

Last but not least, I would like to know if you have some other proposition
for me. Mr Ian could have a suggestion for the go part perhaps?

Thank you for your feedback - it means a lot to me.
Fotis Koutoulakis.


On Wed, May 15, 2013 at 5:04 PM, Thomas Schwinge wrote:

> Hi!
>
> On Fri, 3 May 2013 21:23:49 +0300, Fotis Koutoulakis <
> fotis.koutoula...@gmail.com> wrote:
> > A link to it can be found here:
> >
> https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/nlightnfotis/1
> > (I
> > hope it is publicly visible, it seems to me it is).
> >
> > Of course, I am more than open to comments/criticism as well as
> > clarifications.
>
> Your Estimated Project Timeline is not yet very specific (though I'm well
> aware that this is difficult to do).  Replacing the (legacy) threadvars
> mechanism with TLS shall not really be your project; yours is to port Go
> (or more specifically, its runtime library) to GNU Hurd.
>
> As an obvious preparatory task (which in a way is also present in your
> Estimated Project Timeline, Before May 15): have you been able to
> complete a build of GCC for/on GNU/Hurd, and (roughly) reproduced my
> current test results, as per my notes on
> ?  (Not for Go
> yet, of course, but so that you generally have set up a suitable
> development environment for GCC work.)  You can clone the hurd/web.git
> repository from Savannah, and check out the toolchain/logs/master branch
> (which I have as a Git submodule on toolchain/logs), and compare the
> *.sum files in gcc/coulomb.SCHWINGE/test/ with those you get.
>
> Ian, anything else we would like Fotis to do/provide at this time?
>
>
> As for the roadblock:
>
> > On Tue, Apr 30, 2013 at 4:58 PM, Ian Lance Taylor 
> wrote:
> >
> > > 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.
> > > > <
> http://darnassus.sceen.net/~hurd-web/open_issues/glibc/t/tls-threadvar/>
> > > > and
> > > > <
> http://news.gmane.org/find-root.php?message_id=%3c878vdyqht3%2Efsf%40kepler%2Eschwinge%2Ehomeip%2Enet%3e
> >
> > > > 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

Re: [patch] for mig check in GDB's configure

[Thomas Schwinge]

Hi!

Sorry for the delay.

On Sat, 4 May 2013 16:29:01 +0800, Yue Lu  wrote:
> * configure.ac: Ensure MIG is available when building for GNU
> * Hurd.

After reviewing and testing it, I now checked in your patch (very minor
coding style and wording changes).  Congratulations to your first
contribution!  :-)

2013-05-16  Yue Lu  

* configure.ac: Ensure MIG is available when building for GNU Hurd
hosts.
* configure: Regenerate.

Index: configure.ac
===
RCS file: /cvs/src/src/gdb/configure.ac,v
retrieving revision 1.203
diff -u -p -r1.203 configure.ac
--- configure.ac10 May 2013 16:10:40 -  1.203
+++ configure.ac16 May 2013 21:50:18 -
@@ -486,8 +486,15 @@ AC_CHECK_TOOL(AR, ar)
 AC_CHECK_TOOL(DLLTOOL, dlltool)
 AC_CHECK_TOOL(WINDRES, windres)
 
-# Needed for GNU/Hurd.
-AC_CHECK_TOOL(MIG, mig)
+case $host_os in
+  gnu*)
+# Needed for GNU Hurd hosts.
+AC_CHECK_TOOL(MIG, mig)
+if test x"$MIG" = x; then
+  AC_MSG_ERROR([MIG not found but required for $host hosts])
+fi
+;;
+esac
 
 # -- #
 # Checks for libraries.  #
Index: configure
===
RCS file: /cvs/src/src/gdb/configure,v
retrieving revision 1.391
diff -u -p -r1.391 configure
--- configure   10 May 2013 16:10:40 -  1.391
+++ configure   16 May 2013 21:50:20 -
[...]


Grüße,
 Thomas


pgp6Ux0pE9Rfb.pgp
Description: PGP signature

Re: [patch] for mig check in GDB's configure

[Thomas Schwinge]

Hi!

On Sun, 5 May 2013 10:35:25 -0700, Doug Evans  wrote:
> On Sat, May 4, 2013 at 10:30 PM, Yue Lu  wrote:
> > But I have one more question, why the one run on GNU Hurd which
> > targeting arm doesn't need to use MIG? As it run under GNU Hurd, it
> > must use the message transport facility and need to use MIG to
> > generate the interface file automatically or someone  write it by
> > hands.
> 
> That's a good question (assuming I understand it, it's a bit hard to
> parse as written).  I don't know MIG or GNU Hurd.
> This stuff is pretty straightforward though, there's no magic.
> The answer depends on what GDB uses MIG for.
> 
> If GDB on Hurd uses MIG like GDB on Linux uses ptrace,
> then that would explain it (again, assuming I understand the question).
> But someone who knows Hurd and MIG will need to step up
> and provide a real answer.

That's basically it.  Basically, RPC interface definition files (*.defs,
included with the Hurd system) basically describe all possible "system
calls", including ptrace, and the MIG tool translates these into C code
stub functions.

So, MIG is needed everywhere where a Linux port of GDB would talk to the
kernel.  This means in the Hurd context: a) for a native configuration
(GDB host equals GDB target: runs on the host, speaks to the target
(which is the same system, hence native); the only configuration existing
right now), or b) -- to be worked on -- via gdbserver, where the GDB host
can be anything, the GDB target is Hurd (assuming the GDB host is not
Hurd, then MIG is not needed, because that GDB configuration will not
directly interact with a Hurd system), and for gdbserver itself, again
host equals target, as it runs on the host, and speaks to the target
(which is the same system, hence native).


Grüße,
 Thomas


pgpjzQJktDnjz.pgp
Description: PGP signature

Re: gdb: FTBFS on hurd-i386 (for review)

[Samuel Thibault]

Svante Signell, le Mon 13 May 2013 13:35:37 +0200, a écrit :
> On Sat, 2013-05-11 at 12:03 +0200, Svante Signell wrote:
> > as written in 
> > http://lists.debian.org/debian-hurd/2012/09/msg00018.html
> > replied to here gdb has a PATH_MAX issue in addition to the MACH issue.
> > See the second part of the patch below. This fix was not submitted as a
> > Debian bug, due to the freeze and lack of feedback. The MACH stuff is
> > already fixed upstream I assume.
> > 
> > Svante
> > 
> > On Wed, 2012-09-26 at 16:02 +0200, Svante Signell wrote:
> > > Source: gdb
> > > Version: 7.4.1-1.1
> > > Severity: important
> > > Tags: patch
> > > Usertags: hurd
> > > User: debian-h...@lists.debian.org
> 
> Is there any idea to submit bug reports to the Debian BTS until the
> status of Hurd in Jessie is resolved?

It can't hurt.

> If not I think the PATH_MAX patch should be sent upstream: where to
> report, bug-...@gnu.org?

You can send to both.

Samuel

Re: [patch] for mig check in GDB's configure

[Joel Brobecker]

Hi Thomas and Yue,

> After reviewing and testing it, I now checked in your patch (very minor
> coding style and wording changes).  Congratulations to your first
> contribution!  :-)
> 
> 2013-05-16  Yue Lu  
> 
>   * configure.ac: Ensure MIG is available when building for GNU Hurd
>   hosts.
>   * configure: Regenerate.

I cannot remember if we said Yue had a copyright assignment on file,
or not. I checked the file, and couldn't locate him. Can you clarify?

This patch is small enough that it can be accepted without regardless;
but if we do, I'd like to mark it as such in the ChangeLog entry
(using "(tiny change)", as mentioned by the guide for GNU maintainers).

Thank you!

> 
> Index: configure.ac
> ===
> RCS file: /cvs/src/src/gdb/configure.ac,v
> retrieving revision 1.203
> diff -u -p -r1.203 configure.ac
> --- configure.ac  10 May 2013 16:10:40 -  1.203
> +++ configure.ac  16 May 2013 21:50:18 -
> @@ -486,8 +486,15 @@ AC_CHECK_TOOL(AR, ar)
>  AC_CHECK_TOOL(DLLTOOL, dlltool)
>  AC_CHECK_TOOL(WINDRES, windres)
>  
> -# Needed for GNU/Hurd.
> -AC_CHECK_TOOL(MIG, mig)
> +case $host_os in
> +  gnu*)
> +# Needed for GNU Hurd hosts.
> +AC_CHECK_TOOL(MIG, mig)
> +if test x"$MIG" = x; then
> +  AC_MSG_ERROR([MIG not found but required for $host hosts])
> +fi
> +;;
> +esac
>  
>  # -- #
>  # Checks for libraries.  #
> Index: configure
> ===
> RCS file: /cvs/src/src/gdb/configure,v
> retrieving revision 1.391
> diff -u -p -r1.391 configure
> --- configure 10 May 2013 16:10:40 -  1.391
> +++ configure 16 May 2013 21:50:20 -
> [...]
> 
> 
> Grüße,
>  Thomas



-- 
Joel

Re: [patch] for mig check in GDB's configure

[Yue Lu]

Hi,

On Fri, May 17, 2013 at 1:30 PM, Joel Brobecker  wrote:
> Hi Thomas and Yue,
> I cannot remember if we said Yue had a copyright assignment on file,
> or not. I checked the file, and couldn't locate him. Can you clarify?
>

As this is the first time for me to submit patches, I don't know how
to do the copyright assignment.
Could you please tell me how to do that?
thanks.

-- 
Yue Lu (陆岳)

Re: [patch] for mig check in GDB's configure

[Yue Lu]

Hi Thomas,

On Fri, May 17, 2013 at 5:55 AM, Thomas Schwinge
 wrote:
>
> After reviewing and testing it, I now checked in your patch (very minor
> coding style and wording changes).  Congratulations to your first
> contribution!  :-)

So thanks for your patience to guide me.  I am entering the door of
open source world. Aha ^_^.

-- 
Yue Lu (陆岳)