From: Albert Antony <albert@newtec.dk>
To: Juergen Borleis <jbe@pengutronix.de>
Cc: ptxdist@pengutronix.de
Subject: Re: [ptxdist] [PATCH] Enable "strip" install option handling for libraries
Date: Wed, 22 Jul 2015 15:28:33 +0200 [thread overview]
Message-ID: <CAHChq8O7PxwYJGd1BjsF7jh-DsRJC0Oyj3hUT0qZsviNsgi9RQ@mail.gmail.com> (raw)
In-Reply-To: <201507221129.17331.jbe@pengutronix.de>
Hi Juergen,
I agree with everything you say there. On our side, what the few
unstripped binaries help us avoid is re-creating a matching rootfs
(which as you know can take anywhere from a few seconds to a few
hours). Since the slight extra storage space is not an issue on our
target platform, unstripped application-specific binaries with
in-target gdb work out to be a simple solution for our needs.
But of course you guys are way more experienced with build systems :)
If you see our requirement as one-off and not in line with the
customary approach, then we don't have to merge the patch in. I just
thought it was better to let the user have a say in the
stripped-vs-unstripped install, with the default of course being a
stripped install.
Cheers,
Albert.
On 22 July 2015 at 11:29, Juergen Borleis <jbe@pengutronix.de> wrote:
> Hi Albert,
>
> On Wednesday 22 July 2015 10:31:45 Albert Antony wrote:
>> I am aware of the root-debug option, and indeed that is what we use
>> for in-house debugging. But we would like to be able to debug a target
>> that is out in the field, with only ssh access available to it. Having
>> an unstripped version of the application of interest makes the
>> debugging a lot easier in this case.
>
> Hmm, PTXdist is a tool which supports exactly this use case. You still can
> debug your target remotely even if it is already in the field.
>
> But you rely on the root filesystem content in the target in the field is
> exactly the one which PTXdist has created (and can re-create on demand at any
> point of time).
>
> Then you can run the 'gdbserver' on your target in the field, start your
> debugger locally and point it to the local "root-debug" directory. That's all.
> Everything runs on your target in the field, but the debugger still finds all
> relevant debug info locally on your host. There is no need for debug infos at
> the target side.
>
> Regards,
> Juergen
>
> --
> Pengutronix e.K. | Juergen Borleis |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
--
ptxdist mailing list
ptxdist@pengutronix.de
next prev parent reply other threads:[~2015-07-22 11:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-21 12:04 Albert Antony
2015-07-21 13:14 ` Juergen Borleis
2015-07-21 14:03 ` Albert Antony
2015-07-21 14:34 ` Juergen Borleis
2015-07-22 8:31 ` Albert Antony
2015-07-22 9:29 ` Juergen Borleis
2015-07-22 13:28 ` Albert Antony [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-07-21 10:09 Albert Antony
2015-07-21 10:26 ` Michael Olbrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHChq8O7PxwYJGd1BjsF7jh-DsRJC0Oyj3hUT0qZsviNsgi9RQ@mail.gmail.com \
--to=albert@newtec.dk \
--cc=jbe@pengutronix.de \
--cc=ptxdist@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox