GSOC:Remote debugger for minix
mohangupta13
This is in continuation of my previous posts.
While making the remote stub for gdb in Minix which all architecture
are we supposed to implement it on???
I read a i386 stub of gdb and that looks quite manageable in less than
the time given for GSOC , may be i am not quite able to get what
actually is demanded by the paragraph given in the ideas list ..
Hope to hear from you soon!
Mohan Gupta
mohangupta13
as the ideas page say we are just to write the gdbserver which will
run on the target machine(as i interpreted it). What about the routine
which will teach the gdb on the host to understand the a.out file
format of minix and other similar issues???
Mohan Gupta
Ben Gras
> run on the target machine(as i interpreted it). What about the routine
> which will teach the gdb on the host to understand the a.out file
> format of minix and other similar issues???
getting gdb to understand the minix symbols is also part of the
project, in order to make it usable. As long as there is time, there
will be plenty of other work to do; userland symbols and line number
information come to mind..
Arun Thomas
>
> While making the remote stub for gdb in Minix which all architecture
> are we supposed to implement it on???
Minix currently only supports x86 (32-bit), so you only need to support it.
Arun
mohangupta13
I am a student trying for the project handle for remote debugger(for
GSOC).
First of all as i studied the gdb documentation and how to ports etc
for the last week ,i have a few questions before i can start writing
my application.:
(these are what i could interpret from my study)
1. Is the bfd for a.out format of minix already ported in the binutils
package or we have to write it as part of the project?
2. the gdbserver running on the remote host is used to support both
kernel and user processs debugging or we have to write different
servers each for kerenl and user process?
3. As minix only supports x86 (32-bit) architecture the architeture
specification part of the gdb (which runs on the host) has already
been implemented for this arch a lot many times ,so can we just use
the already existing code for that part?
and lastly : sorry for asking it again but different people here on
the google groups have given different answers so i want to confirm it
one more time
that are we just have to write the target side gdbserver that just
takes commands like read N bytes from AAA address and sends the result
back to the host or both the gdbserver and the host part which teaches
gdb to understand minix executable files (by that i mean bfd for
minix ).
hope to hear from you soon!
yours thankfully
Mohan Gupta
On Mar 26, 10:01 pm, Arun Thomas <arun.tho...@gmail.com> wrote:
Antoine Leca
do not take me wrong: my idea is more to show the variety of
possibilities such a project can raise. I am not advocating that all
should be finished by end of September!
mohangupta13 wrote:
> 1. Is the bfd for a.out format of minix already ported in the binutils
> package or we have to write it as part of the project?
>
It is partly ported. Ie one can use BFD as it is used for the basic
tasks of gas and gld (otherwise gcc won't work, obviously). However it
is up to you to check everything, and we are sure some parts are missing
or can be enhanced. Ben signaled that the (PC/IX derived) symbol table
inside a.out are not decoded (is it encoded?); another thread last week
showed the A_SEP flag is unsupported; etc.
Another way is to build twice (perhaps using objcopy), once to produce
Minix-way a.out to be executed, and another to produce another
executable (ELF?) which can handle full symbol tables (inc. locals), and
line numbers, inside a more complete format like DWARF.
Also note that <a.out.h> header for Minix always documented a subset of
the features of the original PC/IX format: the line numbers were always
missing (and presently the 32-or-48-byte format of the a.out header is
so deeply entrenched that probably we cannot restore the 52- and 56-byte
formats), and all the symbols beside extern and static (storage classes)
are not expected to be seen (PC/IX had a format similar to sdb/dbx to
this effect.)
> 2. the gdbserver running on the remote host is used to support both
> kernel and user processs debugging or we have to write different
> servers each for kerenl and user process?
>
You cannot start a gdbserver and expect it to launch the kernel, so
obviously you have to write something specific to the kernel (be it
integrated in the kernel, or a task, or a separate server).
Similarly, it could be helpful to have a form of gdbserver for servers
(which could be integrated within rs, for example).
> 3. As minix only supports x86 (32-bit) architecture the architeture
> specification part of the gdb (which runs on the host) has already
> been implemented for this arch a lot many times ,so can we just use
> the already existing code for that part?
>
Except that you need it to recognize the stuff proper of Minix; the
executable image format with its symbols have been mentionned; the lack
of local symbols there asks for something in addition; also some support
to examine the IPC traffic (and remoting it form and to the debuggee)
could be helpful, see mdb for a hint.
> that are we just have to write the target side gdbserver that just
> takes commands like read N bytes from AAA address and sends the result
> back to the host or both the gdbserver and the host part which teaches
> gdb to understand minix executable files (by that i mean bfd for
> minix ).
>
The latter, and furthermore it would only be the start point.
Antoine
> On Mar 26, 10:01 pm, Arun Thomas wrote:
>
>> On Thu, Mar 26, 2009 at 8:09 AM, mohangupta13 wrote:
>>> While making the remote stub for gdb in Minix which all architecture
>>> are we supposed to implement it on???
>>>
>> Minix currently only supports x86 (32-bit), so you only need to support it.
>>
>>
Supporting i86 is likely to be a BIG hurdle for gdb anyway! ;-)