[PATCH 1/2] Port gdbserver to GNU/Hurd

[Yue Lu]

Hi all,

This is my patch to port gdbserver to GNU/Hurd. Most of code are
copied  from [gdb]/gdb/gnu-nat.c.
Now the gdbserver on GNU/Hurd can set breakpoint and check memory or
register(but without float-register support).

You can also view the code on my github.
https://github.com/hacklu/gdbserver.git under branch gdbserver.

Very glad for your comment.

2013-09-03  Yue Lu  

* configure.tgt: Set build_gdbserver=yes for GNU/Hurd
hosts.
* configure: Regenerate.

diff --git a/gdb/configure.tgt b/gdb/configure.tgt
index b0bee47..3eb2ff7 100644
--- a/gdb/configure.tgt
+++ b/gdb/configure.tgt
@@ -231,6 +231,7 @@ i[34567]86-*-linux*)
 i[34567]86-*-gnu*)
  # Target: Intel 386 running the GNU Hurd
  gdb_target_obs="i386-tdep.o i387-tdep.o i386gnu-tdep.o solib-svr4.o"
+ build_gdbserver=yes
  ;;
 i[34567]86-*-cygwin*)
  # Target: Intel 386 running win32


--
Yue Lu (陆岳)

Re: [PATCH 1/2] Port gdbserver to GNU/Hurd

[Thomas Schwinge]

Hi!

For context, Yue Lu is a student participating in this year's Google
Summer of Code program, to port gdbserver to GNU Hurd, and is both a GDB
as well as a GNU Hurd newbie.  (So, be gentle.)  ;-)

On Tue, 3 Sep 2013 16:00:32 +0800, Yue Lu  wrote:
> This is my patch to port gdbserver to GNU/Hurd. Most of code are
> copied  from [gdb]/gdb/gnu-nat.c.

... and elsewhere.  Our strategy was to first get this into a basic
functional state:

> Now the gdbserver on GNU/Hurd can set breakpoint and check memory or
> register(but without float-register support).

So, this initial port just posted is a great milestone!  Especially so
given your previous lack of experience with both GDB and the Hurd -- both
of which are not always easy to grasp.

There are lots of things to be polished (Yue, don't worry -- this
entirely was to be expected), such as GDB coding standard, and changes
that are unrelated to your port, which all has to be cleared out before I
can commit this initial port to GDB upstream.

There is missing functionality, but we decided this can be enhanced piece
by piece once the initial port is accepted.

There is the issue of code sharing between GDB proper and gdbserver, a
strategy for which has been briefly discussed in
.
Likewise for code sharing between the new Hurd gdbserver port and the
existing x86 Linux kernel port.  Again I suggest this to be done *after*
the initial port is accepted: this will turn into a nice (and easily
reviewable) series of cleanup patches à la: remove from GDB proper
gdb/gnu-nat.c:[function] and from gdbserver
gdb/gdbserver/gnu-low.c:[function], and add
gdb/common/gnu-low.c:[function], and so on.  Likewise for build
infrastructure that can be shared.

Does this strategy generally make sense to you GDB maintainers?


For the curious, in

I describe the MIG usage in GDB.  (This message also states that ptrace
is a system call which it is not; it's a glibc library function using RPC
calls to implement its functionality.)


Grüße,
 Thomas


pgp9h6kGyWOP0.pgp
Description: PGP signature

Join in GNU/Hurd contribution

[901...@gmail.com]

Hello all,

I have read and researched about GNU/Hurd and I think it is an
interesting project. I would like to join to help in development Hurd. I
learned about C language, assembly, and OS. My major is Software and
Embedded System. I have read the contributing questionnaire, and there
are 3 areas that I can help:
- Do research and development of a next-generation microkernel.
- Work on the current Mach microkernel.
- Help with development of new Hurd libraries and servers on top of that.
I appreciate for your respond.

Re: Join in GNU/Hurd contribution

[Richard Braun]

On Tue, Sep 03, 2013 at 01:46:22PM +0700, 901...@gmail.com wrote:
> I have read and researched about GNU/Hurd and I think it is an
> interesting project. I would like to join to help in development Hurd. I
> learned about C language, assembly, and OS. My major is Software and
> Embedded System. I have read the contributing questionnaire, and there
> are 3 areas that I can help:
> - Do research and development of a next-generation microkernel.
> - Work on the current Mach microkernel.
> - Help with development of new Hurd libraries and servers on top of that.
> I appreciate for your respond.

Hello,

As it's commonly the case with any free software/open source project,
just pick something you find interesting and work on it. Don't expect
us to guide you more in your choices than what is already provided on
the wiki. If you really intend to work on such projects, you need a
good amount of autonomy.

-- 
Richard Braun

Re: [PATCH 1/2] Port gdbserver to GNU/Hurd

[Pedro Alves]

On 09/03/2013 10:38 AM, Thomas Schwinge wrote:
> Hi!
> 
> For context, Yue Lu is a student participating in this year's Google
> Summer of Code program, to port gdbserver to GNU Hurd, and is both a GDB
> as well as a GNU Hurd newbie.  (So, be gentle.)  ;-)
> 
> On Tue, 3 Sep 2013 16:00:32 +0800, Yue Lu  wrote:
>> This is my patch to port gdbserver to GNU/Hurd. Most of code are
>> copied  from [gdb]/gdb/gnu-nat.c.
> 
> ... and elsewhere.  Our strategy was to first get this into a basic
> functional state:
> 
>> Now the gdbserver on GNU/Hurd can set breakpoint and check memory or
>> register(but without float-register support).
> 
> So, this initial port just posted is a great milestone!  Especially so
> given your previous lack of experience with both GDB and the Hurd -- both
> of which are not always easy to grasp.

Indeed!

> 
> There are lots of things to be polished (Yue, don't worry -- this
> entirely was to be expected), such as GDB coding standard, and changes
> that are unrelated to your port, which all has to be cleared out before I
> can commit this initial port to GDB upstream.
> 
> There is missing functionality, but we decided this can be enhanced piece
> by piece once the initial port is accepted.
> 
> There is the issue of code sharing between GDB proper and gdbserver, a
> strategy for which has been briefly discussed in
> .

That has been further discussed recently:

 https://sourceware.org/ml/gdb-patches/2013-07/msg00788.html

and we ended up with putting native target files under the
new gdb/nat/ directory, rather than in gdb/common/:

 https://sourceware.org/ml/gdb-patches/2013-08/msg00618.html

> Likewise for code sharing between the new Hurd gdbserver port and the
> existing x86 Linux kernel port.  Again I suggest this to be done *after*
> the initial port is accepted: this will turn into a nice (and easily
> reviewable) series of cleanup patches à la: remove from GDB proper
> gdb/gnu-nat.c:[function] and from gdbserver
> gdb/gdbserver/gnu-low.c:[function], and add
> gdb/common/gnu-low.c:[function], and so on.  Likewise for build
> infrastructure that can be shared.
> 
> Does this strategy generally make sense to you GDB maintainers?

I've been thinking about this this morning, after seeing these
patches.

For new gdbserver ports, this path just seems to swim further away from
a full sharing approach, by adding lots duplication as first step, and
actually making it hard to see what exactly needed to be changed/adapted
for gdbserver use, and puts the tree in a state where any further changes
for the GNU/Hurd target will need to be considered twice going further,
exactly what we're fighting against with the existing ports.  I think
that strategy ultimately is slower to get at where we want to, and
is actually more work than an alternative that does things the other
way around.

I checked out Yue's git branch, and diffed gdb/gnu-nat.c vs
gdbserver/gnu-low.c, and gdb/i386gnu-nat.c vs gdbserver/gnu-i386-low.c.
I didn't diff the rest of the files, as I assume they'll probably have
even less divergence.  There are several spurious formatting differences,
and some reordering of functions, but for the most port, the code is
mostly identical.  There's some expected necessary adjustment to GDBserver's
interfaces, but it turns out it's not that much.  We've been converging
gdb's and gdbserver's interfaces throughout the years, and it now shows.

So my idea would be, instead of adding the new files under gdbserver,
to remove the spurious differences (formatting, reordering, etc.) that
were introduced in the gdbserver copies of the files, eliminating the
unnecessary divergence, and then fold back the resulting differences into
the original gdb/gnu-nat.c etc. files, guarded by #ifdef GDBSERVER.  Some
cleanups might have been identified and done in the gdbserver files, and
it might make sense to do those as preparatory work, in the original files.
This should result in smaller patches, and will actually avoid
the need for most of the polishing Thomas mentioned, and as consequence
review burden -- reviewing the new gnu-low.c etc., for GNU conventions,
formatting, or even appropriate use of the Hurd's debug APIs etc., is
just unnecessary that way, by design, and we'll be able to focus on the
bits that are the real new code -- the glue between the target and gdb, and
the target and gdbserver.

The current state of the work isn't wasted at all!  And I don't
think following this direction is that much work.  I'd do this my
literally moving gdbserver/gnu-low.c on top of gdb/gnu-nat.c (etc.), and
use git diff to guide me through, in identifying what would need to
be restored, and guarded with #if[n]def GDBSERVER.  #ifdef GDBSERVER
is how we've adapting shared code under gdb/common/ and gdb/nat/
to work on both programs.  Medium/long term, core gdb and core
gdbserver target interface

Re: [PATCH 1/2] Port gdbserver to GNU/Hurd

[Thomas Schwinge]

Hi!

On Tue, 03 Sep 2013 12:11:02 +0100, Pedro Alves  wrote:
> On 09/03/2013 10:38 AM, Thomas Schwinge wrote:
> > [strategy]
> 
> I've been thinking about this this morning, after seeing these
> patches.
> 
> For new gdbserver ports, this path just seems to swim further away from
> a full sharing approach, by adding lots duplication as first step, [...]

> So my idea would be, [...]

Understood, and yes, your argumentation is reasonable.

> I'd do this [by]
> literally moving gdbserver/gnu-low.c on top of gdb/gnu-nat.c (etc.), and
> use git diff to guide me through, in identifying what would need to
> be restored, and guarded with #if[n]def GDBSERVER.  [...]

Yes, that's a nice technique for displaying and integrating the
differences between the existing Hurd native port's files and the new
gdbserver port's.  Yue, does the approach of diffing the files as Pedro
described make sense to you?  Please tell if you need help with how to
use Git to do that, etc.

> Could we try that approach?

Thanks for the input!


Grüße,
 Thomas


pgpRG9MIQr0mp.pgp
Description: PGP signature

Re: SOCK_CLOEXEC glibc patches (was: dbus startup problem when built with eglibc-2.17)

[Svante Signell]

On Mon, 2013-09-02 at 23:56 +0200, Thomas Schwinge wrote:
> Hi!
> 

> This is strange -- nearly five years ago, I have implemented SOCK_CLOEXEC
> for socket in TopGit branch t/socket_flags and for socketpair in
> t/socketpair_flags (plus depending branches t/fcntl-internal.h and
> t/verify.h).  Could you please check why this is no longer functional?

Sorry, I cannot find anything hurd specific in these branches. Of course
I've missed something :(

The return error code is from pflocal/pf.c: EPFNOSUPPORT /* Protocol
family not supported */ not from the eglibc __socket/__socketpair
wrapper.
dbus expects to get EINVAL/* Operation not supported */ which in my
opinion is a more sane response since it is a flag, not a protocol.

Re: [PATCH 1/2] Port gdbserver to GNU/Hurd

[Yue Lu]

Thanks for your review!

On Tue, Sep 3, 2013 at 7:11 PM, Pedro Alves  wrote:
>
> For new gdbserver ports, this path just seems to swim further away from
> a full sharing approach, by adding lots duplication as first step, and
> actually making it hard to see what exactly needed to be changed/adapted
> for gdbserver use, and puts the tree in a state where any further changes
> for the GNU/Hurd target will need to be considered twice going further,
> exactly what we're fighting against with the existing ports.  I think
> that strategy ultimately is slower to get at where we want to, and
> is actually more work than an alternative that does things the other
> way around.
>
> I checked out Yue's git branch, and diffed gdb/gnu-nat.c vs
> gdbserver/gnu-low.c, and gdb/i386gnu-nat.c vs gdbserver/gnu-i386-low.c.
> I didn't diff the rest of the files, as I assume they'll probably have
> even less divergence.  There are several spurious formatting differences,
> and some reordering of functions, but for the most port, the code is

The reason is, at first, I plan to write the new file, and then I
found one function can be re-use, so I copy it, it call another one,
so I copy the another one. One by one, so there are some reordering of
functions. The formatting differences comes with "indent program", I
found this from GNU_CODIND_STYLE
(http://www.gnu.org/prep/standards/standards.html ).

> mostly identical.  There's some expected necessary adjustment to GDBserver's
> interfaces, but it turns out it's not that much.  We've been converging
> gdb's and gdbserver's interfaces throughout the years, and it now shows.

I have found some interfaces which must be adjustment. Like use the
lwp as tid in structure ptid_t.

> So my idea would be, instead of adding the new files under gdbserver,
> to remove the spurious differences (formatting, reordering, etc.) that
> were introduced in the gdbserver copies of the files, eliminating the
> unnecessary divergence, and then fold back the resulting differences into
> the original gdb/gnu-nat.c etc. files, guarded by #ifdef GDBSERVER.  Some
> cleanups might have been identified and done in the gdbserver files, and
> it might make sense to do those as preparatory work, in the original files.
> This should result in smaller patches, and will actually avoid
> the need for most of the polishing Thomas mentioned, and as consequence
> review burden -- reviewing the new gnu-low.c etc., for GNU conventions,
> formatting, or even appropriate use of the Hurd's debug APIs etc., is
> just unnecessary that way, by design, and we'll be able to focus on the
> bits that are the real new code -- the glue between the target and gdb, and
> the target and gdbserver.
>
> The current state of the work isn't wasted at all!  And I don't
> think following this direction is that much work.  I'd do this my
> literally moving gdbserver/gnu-low.c on top of gdb/gnu-nat.c (etc.), and
> use git diff to guide me through, in identifying what would need to
> be restored, and guarded with #if[n]def GDBSERVER.  #ifdef GDBSERVER
> is how we've adapting shared code under gdb/common/ and gdb/nat/
> to work on both programs.  Medium/long term, core gdb and core
> gdbserver target interface differences should converge further, and
> the #ifdefs disappear, but for now that's a necessary evil.
>
> It's fine to leave bits of functionality disabled on gdbserver,
> wrapped in #ifndef GDBSERVER.  After that initial work is committed,
> we can then easily progress the gdbserver port by just looking for
> those #ifdefs.
>
> It's fine with me to leave the existing native files under gdb/ while
> doing this; it's probably easier that way.  Moving them under gdb/nat/
> can be left for a cleanup step further down the road.
>
> Could we try that approach?

Ok, I will try to move the gdbserver/gnu-low.c back into gdb/gnu-nat.c.

> --
> Pedro Alves
>



-- 
Yue Lu (陆岳)

Re: [PATCH 1/2] Port gdbserver to GNU/Hurd

[Yue Lu]

Hi,

On Tue, Sep 3, 2013 at 9:09 PM, Thomas Schwinge  wrote:
> Hi!
>
> On Tue, 03 Sep 2013 12:11:02 +0100, Pedro Alves  wrote:
>> On 09/03/2013 10:38 AM, Thomas Schwinge wrote:
>> > [strategy]
>>
>> I've been thinking about this this morning, after seeing these
>> patches.
>>
>> For new gdbserver ports, this path just seems to swim further away from
>> a full sharing approach, by adding lots duplication as first step, [...]
>
>> So my idea would be, [...]
>
> Understood, and yes, your argumentation is reasonable.
>
>> I'd do this [by]
>> literally moving gdbserver/gnu-low.c on top of gdb/gnu-nat.c (etc.), and
>> use git diff to guide me through, in identifying what would need to
>> be restored, and guarded with #if[n]def GDBSERVER.  [...]
>
> Yes, that's a nice technique for displaying and integrating the
> differences between the existing Hurd native port's files and the new
> gdbserver port's.  Yue, does the approach of diffing the files as Pedro
> described make sense to you?  Please tell if you need help with how to
> use Git to do that, etc.

Yeah, I will do that. But in my understand, I will use diff gnu-low.c
../gnu-nat.c and something like this. But I don't know how to use git
do this.  Like git diff a.c b.c?

BTW, I got these patches by  git diff   > gdb.patch.
Then I edit the patch to two file. When I use git format-patch
 I will get a patche for each commit after the
early_commit. What is the better way you generate patches?

-- 
Yue Lu (陆岳)