[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] "Attach Process" dialog for gdb running remotely ?
|
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
> Sent: Friday, January 25, 2013 2:21 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] "Attach Process" dialog for gdb
> running remotely ?
>
> Hi Marc,
>
> Thanks for your help and suggestions. I really appreciate that !
>
> > I found this email that talks about a port of gdbserver to
> Solaris 10, but I'm not sure it was ever submitted.
> > http://www.sourceware.org/ml/gdb/2010-03/msg00219.html
>
> Yes I guess that's the gdbserver that works for me. I found
> some "public patches"
> On the gdb mailing list from 2010 which are relatively large
> ... applied to a 7.1 gdb tree.
> Strange that the patches never made it into the official
> source tree. Would you know
> Whom to ask where's the official location of these patches in
> some CM system ?
>
> Anyways the patches are only for gdbserver, so I assume
> bringing that work inside the gdb itself
> might not be trivial. I've also heard (not yet tried myself)
> that there are issues with pthread programs.
>
> > However, I believe all you need is to bring the binary
> running on solaris and put it on your host.
>
> I'm afraid it's not that easy. My target system has binaries
> in the hundreds, plus sharedlibs
> In the hundreds. And, I would need a cross-gdb. I would get
> that prompt dialog a zillion times,
> Even if I prepare a mirror of the target file system on my host :(
> The nice thing about running gdb on the remote is, that it is
> fully self-contained. It finds all
> the files in their original places. And CDT is really good
> doing the source path mapping :)
>
> The idea that I'm currently entertaining is launch gdb on the
> remote (ssh remote gdb) but
> still have it connect to the gdbserver which also runs on the
> remote, in order to get the
> attach functionality. It sounds crazy but works :)
But you won't get a list of processes to choose from in that
case. It is better than showing a list of the processes
running on the host though :)
> The one thing that gets in the way is the "prompt for
> process" dialog which tries finding
> a file on the local host.
With your original trick of running GDB with a local session
but on the target, that prompt wouldn't show up at all, which
seems more user-friendly...
Wouldn't be better for you to try to solve the 'attach list'
isse instead of the 'prompt for process' issue?
> Do you think it would be possible
> to receive the original file path
> from the remote, apply a single object path mapping ( / -->
> /mirror/of/targetfs) and try
> find the file there, then only show the "find binary" dialog
> if that fails ?
> Ideally have all object path probing / handling through the
> gdb/mi channel and not
> access the file system locally at all.
I like that.
I actually had a similar discussion not too long ago about this
in the hopes of avoiding the prompting.
Could you write an enhancement bug for this?
Thanks!
> If that would work I'd launch my gdb on the remote with an
> identity mapping (/ --> /)
> and all should be fine...
>
> Thanks,
> Martin
> --
> Martin Oberhuber, SMTS / Product Architect – Development
> Tools, Wind River
> direct +43.662.457915.85 fax +43.662.457915.6
>
>
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
> Sent: Friday, January 25, 2013 5:04 PM
> To: 'CDT General developers list.'
> Subject: Re: [cdt-dev] "Attach Process" dialog for gdb
> running remotely ?
>
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
> > Sent: Friday, January 25, 2013 9:37 AM
> > To: CDT General developers list.
> > Subject: Re: [cdt-dev] "Attach Process" dialog for gdb running
> > remotely ?
> >
> > Hi Marc,
> >
> >
> >
> > Looks like you are right - I've built a fresh gdb-7.5.1
> from scratch
> > (standard configure) and here's what I see:
> >
> > -bash-3.00$ ./gdb/gdb -i mi
> > =thread-group-added,id="i1"
> > ~"GNU gdb (GDB) 7.5.1\n"
> > ~"Copyright (C) 2012 Free Software Foundation, Inc.\n"
> > ~"License GPLv3+: GNU GPL version 3 or later
> > <http://gnu.org/licenses/gpl.html>\nThis is free software:
> > you are free to change and redistribute it.\nThere is NO
> WARRANTY, to
> > the extent permitted by law. Type \"show copying\"\nand \"show
> > warranty\" for details.\n"
> >
> > ~"This GDB was configured as \"sparc-sun-solaris2.10\".\nFor bug
> > reporting instructions, please see:\n"
> > ~"<http://www.gnu.org/software/gdb/bugs/>.\n"
> > (gdb)
> > -list-thread-groups --available
> > ^error,msg="Can not fetch data now."
>
> Yes, that is what I've seen when the command is not supported.
>
> > The original solution with just entering “ssh remote gdb” as the
> > debugger to use with the “Local” launch Is what I’d really
> like ; that
> > one did not ask me about the process image to use.
>
> I just realized what you are doing. I hadn't understood before.
> You are running a 'local' session with GDB running on the target.
> That's interesting. But we're not well prepared for that :(
>
> When trying to list the processes, we use -list-thread-groups
> --available and if it does not work, we check if we are
> dealing with a local session. For a local session we assume
> GDB is on the local machine, and CDT gets the list of
> processes itself.
> In your case, that explains why you see the list of processes
> of your host instead of your target.
> The good news is that if -list-thread-groups is supported,
> you won't have this problem.
>
> > Trying to build gdbserver from the gdb-7.5.1 source also fails:
> >
> > -bash-3.00$ cd gdb/gdbserver
> > -bash-3.00$ ./configure
> > […]
> > checking for Elf32_auxv_t... no
> > checking for Elf64_auxv_t... no
> > Error: target not supported by gdbserver.
>
> I found this email that talks about a port of gdbserver to
> Solaris 10, but I'm not sure it was ever submitted.
> http://www.sourceware.org/ml/gdb/2010-03/msg00219.html
>
> But now that I understand what you are doing, I don't think
> you should use gdbserver. So, in the C/C++ Attach to
> Application launch, select 'gdb' in the dropdown box of the
> Debugger subtab next to the "Debugger:" label, intead of 'gdbserver'.
>
> > Funny thing is, I do have a different version of gdbserver
> (not sure
> > how that one was built) which I can Launch as gdbserver –multi and
> > actually use that to attach to a remote process. So the
> functionality
> > of listing Solaris processes is apparently out there somewhere.
>
> So -list-thread-groups --available works with a gdbserver on
> solaris? You should find out if you can get it to work with
> GDB itself...
>
> > The problem with that approach is, that after attaching,
> the CDT asks
> > me to browse to the process executable on the LOCAL file
> system (but I
> > don’t have the image local and don’t want to have – I prefer remote
> > debug over cross-debug).
>
> The prompt will not be shown for a 'local' session, so if you
> avoid using gdbserver, this should work.
>
> However, I believe all you need is to bring the binary
> running on solaris and put it on your host. I think that is
> what GDB needs, it it is running locally. With that, the
> prompt on the LOCAL file system would allow the user to
> choose that binary.
>
> > Do you have any other suggestion how I can provide an “attach to
> > remote process” functionality with gdb on Solaris ?
>
> If -list-thread-groups --available can work on Solaris, then
> your ssh and local debug session solution is probably best.
>
> If not, then a remote session with gdbserver on target and
> GDB on you LOCAL host, is simplest, but you'll need the
> binary locally (the one on the target copied over to the host
> should be ok, but you'll have to try it).
>
> If you don't mind not showing a list of processes to your
> users but letting them type in a pid, you could use your ssh
> trick without -list-thread-groups --available working, but
> you'll need to find a way to have
> CCorePlugin.getDefault().getProcessList() return an empty
> list for that case only. I have not easy suggestion for that.
>
> > Would you recommend patching the gdb, or can you think of anything
> > else ?
>
> I don't have an easy solution I'm afraid.
>
> BR,
>
> Marc
>
> >
> >
> >
> > Thanks,
> >
> > Martin
> >
> > --
> >
> > Martin Oberhuber, SMTS / Product Architect – Development
> Tools, Wind
> > River
> >
> > direct +43.662.457915.85 fax +43.662.457915.6
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
> > Sent: Friday, January 25, 2013 3:34 AM
> > To: CDT General developers list.
> > Subject: Re: [cdt-dev] "Attach Process" dialog for gdb running
> > remotely ?
> >
> >
> >
> > Hi,
> >
> >
> >
> > -list-thread-groups should be available for all GDB's starting with
> > 7.0. However, it is an MI command and therefore will not be
> > understood by the GDB command-line interface as you ran it.
> You can
> > use that command in two ways to try it out:
> >
> > interpreter-exec mi "-list-thread-groups --available"
> >
> > or start gdb in mi mode:
> >
> > gdb -i mi
> >
> > the run the command directly.
> >
> >
> >
> > The problem will not be in recognizing the command but if it is
> > supported on your platform. For example, on Windows
> > "-list-thread-groups --available" will not work, although
> GDB is aware
> > of the command. It is likely that the gdbserver running on Solaris
> > will not support that command, although you'd have to try it to be
> > sure. If it does not, then DSF-GDB cannot get the list of
> processes
> > from the remote target, so no list will be shown to the
> user (getting
> > a list of local processes is not normal).
> >
> >
> >
> > Also, be aware that different advanced features of GDB may
> not work on
> > every platform. Specifically, I don't know if Non-stop or Reverse
> > will work on Solaris (they don't on Windows). Finally, the
> Multicore
> > Visualizer uses /proc/cpuinfo to get the list of cores, as
> available
> > on Linux. This probably won't work on Solaris either which
> > means the Visualizer will stay blank (like on Windows).
> > Note that these features of GDB/CDT could be ported to other
> > platforms, it is just that no one has decided to make that
> investment.
> >
> >
> >
> > If you still want to look into why you are getting a list of
> > _local_ processes when doing a remote debug on Solaris, look
> > (or send me) the gdb traces of the session. I'd be curious
> > to know how that could happen.
> >
> >
> >
> > BR,
> >
> >
> >
> > Marc
> >
> >
> >
> >
> >
> > ________________________________________
> >
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > <mailto:cdt-dev-bounces@xxxxxxxxxxx>
> > [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Oberhuber, Martin
> > [Martin.Oberhuber@xxxxxxxxxxxxx]
> >
> > Sent: January 24, 2013 7:42 PM
> >
> > To: CDT General developers list.
> >
> > Subject: Re: [cdt-dev] "Attach Process" dialog for gdb
> > running remotely ?
> >
> >
> >
> > Hi Marc,
> >
> >
> >
> > Thanks for your answer. Apparently my gdb doesn’t understand
> > –list-thread-groups … I didn’t compile that gdb myself, is
> > there any recommendation how gdb should ideally be compiled
> > for the CDT ? Of course I’ll want non-stop-mode, reverse
> > debug, multi-attach, multicore visualizer and all the other
> goodies ☺
> >
> >
> >
> > My CDT is a recent build from cdt-maint on top of Eclipse
> > 3.8.1 (I think I was using build #388).
> >
> >
> >
> > -bash-3.00$ gdb
> >
> > GNU gdb (GDB) 7.4
> >
> > Copyright (C) 2012 Free Software Foundation, Inc.
> >
> > License GPLv3+: GNU GPL version 3 or later
> > <http://gnu.org/licenses/gpl.html
> <http://gnu.org/licenses/gpl.html> >
> >
> > This is free software: you are free to change and redistribute it.
> >
> > There is NO WARRANTY, to the extent permitted by law. Type
> > "show copying"
> >
> > and "show warranty" for details.
> >
> > This GDB was configured as "sparc-sun-solaris2.10".
> >
> > For bug reporting instructions, please see:
> >
> > <http://www.gnu.org/software/gdb/bugs/
> > <http://www.gnu.org/software/gdb/bugs/> >.
> >
> > (gdb) -list-thread-groups --available
> >
> > Undefined command: "-list-thread-groups". Try "help".
> >
> > (gdb) -list-thread-groups
> >
> > Undefined command: "-list-thread-groups". Try "help".
> >
> > (gdb)
> >
> >
> >
> > Thanks,
> >
> > Martin
> >
> > --
> >
> > Martin Oberhuber, SMTS / Product Architect – Development
> > Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6
> >
> >
> >
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > <mailto:cdt-dev-bounces@xxxxxxxxxxx>
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx
> > <mailto:cdt-dev-bounces@xxxxxxxxxxx> ] On Behalf Of Marc Khouzam
> >
> > Sent: Thursday, January 24, 2013 7:19 PM
> >
> > To: 'CDT General developers list.'
> >
> > Subject: Re: [cdt-dev] "Attach Process" dialog for gdb
> > running remotely ?
> >
> >
> >
> > It is not obvious to me why you would get a local list of
> processes...
> >
> > You can look at the gdb traces and see what is happening
> differently:
> >
> > http://wiki.eclipse.org/CDT/User/FAQ#I.27ve_been_asked_for_.27
> > gdb_traces.27.2C_where_can_I_find_them.3F
> > <http://wiki.eclipse.org/CDT/User/FAQ#I.27ve_been_asked_for_.2
> > 7gdb_traces.27.2C_where_can_I_find_them.3F>
> >
> >
> >
> > To fill the process prompter with values, CDT asks GDB for
> > the list of processes using
> >
> > -list-thread-groups --available
> >
> > If that command does not work (as it may not for Solaris),
> > the remote session should fall back to asking for a pid
> > directly. For the local case, the list will be provided by
> > CDT itself.
> >
> > I wonder if there is some confusion between the remote and
> local case?
> >
> >
> >
> > What version of CDT are you using?
> >
> >
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From:
> > cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx
> >
> > <mailto:cdt-dev-bounces@xxxxxxxxxxx%3cmailto:cdt-dev-bounces@e
> > clipse.org> > [mailto:cdt-dev-bounces@xxxxxxxxxxx
> > <mailto:cdt-dev-bounces@xxxxxxxxxxx> ] On Behalf Of
> Oberhuber, Martin
> >
> > Sent: Thursday, January 24, 2013 11:43 AM
> >
> > To: cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx
> > <mailto:cdt-dev@xxxxxxxxxxx%3cmailto:cdt-dev@xxxxxxxxxxx> >
> >
> > Subject: [cdt-dev] "Attach Process" dialog for gdb running
> remotely ?
> >
> > Hi,
> >
> >
> >
> > I have an odd problem, trying to debug a remote application
> > with gdb running remotely.
> >
> > Here’s what I do:
> >
> >
> >
> >
> >
> > 1. Create a new “C/C++ Attach Application” Launch
> >
> >
> >
> > 2. Leave the project and app fields empty on the main tab
> >
> >
> >
> > 3. Enter “ssh szg-vm01-qa-lx2 gdb“ as the debugger to
> > use on the debugger tab
> >
> >
> >
> > Launch it, and wohoo I get a Process picker dialog showing
> > remote processes, everything works fine !
> >
> > The remote host in that case is RHEL 5.8 with gdb 7.0,
> > NFS-shared file system.
> >
> >
> >
> > BUT
> >
> >
> >
> > When I try the same against a remote Solaris 10 host running
> > gdb-7.4 , I’m getting a LOCAL Process picker dialog, showing
> > the local processes (and the “New…” button enabled).
> >
> > I don’t have the full file system shared in that case.
> >
> >
> >
> > What could be the reason why I don’t get a remote process
> > picker in the 2nd case ?
> >
> > Can I enable logging of any kind to troubleshoot ?
> >
> >
> >
> > Thanks,
> >
> > Martin
> >
> > --
> >
> > Martin Oberhuber, SMTS / Product Architect – Development
> > Tools, Wind River direct +43.662.457915.85 fax
> > +43.662.457915.6 _______________________________________________
> >
> > cdt-dev mailing list
> >
> > cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
> >
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > <https://dev.eclipse.org/mailman/listinfo/cdt-dev>
> >
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>