* [Buildroot] Adding google-breakpad to buildroot
@ 2014-04-23 14:21 Pascal Hürst
2014-04-23 15:29 ` Arnout Vandecappelle
0 siblings, 1 reply; 6+ messages in thread
From: Pascal Hürst @ 2014-04-23 14:21 UTC (permalink / raw)
To: buildroot
Hi everyone,
we are planing to add google-breakpad to buildroot.
From the project description at
http://code.google.com/p/google-breakpad/:
[...] "Breakpad is a library and tool suite that allows you to
distribute an application to users with compiler-provided debugging
information removed, record crashes in compact "minidump" files, send
them back to your server, and produce C and C++ stack traces from these
minidumps." [...]
Adding a package to buildroot is easy, but in this case we will have to
find a way to extract all symbols from the target binaries, before they
get stripped. My idea was to add a new target to the Makefile, just
before "target-finalize:" and check against an option in the config
like:
ifeq ($(BR2_ENABLE_BREAKPAD),y)
TARGETS+=target-generate-breakpad-symbols
endif
and then:
target-generate-breakpad-symbols:
extract symbols and deploy result to output/images
Is this basically the way to go, or is there a better way to achieve
this?
regards,
pascal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140423/eebac11d/attachment.asc>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Adding google-breakpad to buildroot
2014-04-23 14:21 [Buildroot] Adding google-breakpad to buildroot Pascal Hürst
@ 2014-04-23 15:29 ` Arnout Vandecappelle
2014-04-23 15:52 ` Samuel Martin
0 siblings, 1 reply; 6+ messages in thread
From: Arnout Vandecappelle @ 2014-04-23 15:29 UTC (permalink / raw)
To: buildroot
On 23/04/14 16:21, Pascal H?rst wrote:
> Hi everyone,
>
> we are planing to add google-breakpad to buildroot.
>
> From the project description at
> http://code.google.com/p/google-breakpad/:
>
> [...] "Breakpad is a library and tool suite that allows you to
> distribute an application to users with compiler-provided debugging
> information removed, record crashes in compact "minidump" files, send
> them back to your server, and produce C and C++ stack traces from these
> minidumps." [...]
>
> Adding a package to buildroot is easy, but in this case we will have to
> find a way to extract all symbols from the target binaries, before they
> get stripped. My idea was to add a new target to the Makefile, just
> before "target-finalize:" and check against an option in the config
> like:
>
> ifeq ($(BR2_ENABLE_BREAKPAD),y)
> TARGETS+=target-generate-breakpad-symbols
> endif
>
> and then:
>
> target-generate-breakpad-symbols:
> extract symbols and deploy result to output/images
>
> Is this basically the way to go, or is there a better way to achieve
> this?
It is easier to add it to the target-finalize target. Then you can be
sure that the ordering is correct (target-finalize already has all the
needed dependencies). You can also easily use conditions there (it's not
inside a define).
However, I think it will be more appropriate to implement breakpad as an
additional strip alternative. You probably don't want to combine strip
with breakpad... Currently we have none, strip or sstrip, it should be
relatively easy to add breakpad as an additional option. Note, however,
that the strip code is very old, it doesn't satisfy our coding style so
we'll probably want you to do some cleanup first. Also, it is currently
untested in the autobuilders AFAIK.
Regards,
Arnout
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140423/bbd825f8/attachment.asc>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Adding google-breakpad to buildroot
2014-04-23 15:29 ` Arnout Vandecappelle
@ 2014-04-23 15:52 ` Samuel Martin
2014-04-23 16:12 ` Pascal Hürst
0 siblings, 1 reply; 6+ messages in thread
From: Samuel Martin @ 2014-04-23 15:52 UTC (permalink / raw)
To: buildroot
Hi Pascal, Arnout, all,
On Wed, Apr 23, 2014 at 5:29 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 23/04/14 16:21, Pascal H?rst wrote:
>> Hi everyone,
>>
>> we are planing to add google-breakpad to buildroot.
>>
>> From the project description at
>> http://code.google.com/p/google-breakpad/:
>>
>> [...] "Breakpad is a library and tool suite that allows you to
>> distribute an application to users with compiler-provided debugging
>> information removed, record crashes in compact "minidump" files, send
>> them back to your server, and produce C and C++ stack traces from these
>> minidumps." [...]
>>
>> Adding a package to buildroot is easy, but in this case we will have to
>> find a way to extract all symbols from the target binaries, before they
>> get stripped.
Here, you mean adding the host-breakpad package, right?
IIRC, the handler in integrated at the source code level in the
projects. Do you plan to provide something for the target?
>> My idea was to add a new target to the Makefile, just
>> before "target-finalize:" and check against an option in the config
>> like:
>>
>> ifeq ($(BR2_ENABLE_BREAKPAD),y)
>> TARGETS+=target-generate-breakpad-symbols
>> endif
>>
>> and then:
>>
>> target-generate-breakpad-symbols:
>> extract symbols and deploy result to output/images
>>
>> Is this basically the way to go, or is there a better way to achieve
>> this?
>
> It is easier to add it to the target-finalize target. Then you can be
> sure that the ordering is correct (target-finalize already has all the
> needed dependencies). You can also easily use conditions there (it's not
> inside a define).
>
> However, I think it will be more appropriate to implement breakpad as an
> additional strip alternative. You probably don't want to combine strip
> with breakpad...
I think breakpad is more like a pre-strip hook, that one can enable or
not. But in the end, the target image will be stripped most of the
time (at least, this is the way I would use such a feature).
> Currently we have none, strip or sstrip, it should be
> relatively easy to add breakpad as an additional option. Note, however,
> that the strip code is very old, it doesn't satisfy our coding style so
> we'll probably want you to do some cleanup first. Also, it is currently
> untested in the autobuilders AFAIK.
>
Regards,
--
Samuel
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Adding google-breakpad to buildroot
2014-04-23 15:52 ` Samuel Martin
@ 2014-04-23 16:12 ` Pascal Hürst
2014-04-23 21:13 ` Arnout Vandecappelle
0 siblings, 1 reply; 6+ messages in thread
From: Pascal Hürst @ 2014-04-23 16:12 UTC (permalink / raw)
To: buildroot
On Mit, 2014-04-23 at 17:52 +0200, Samuel Martin wrote:
> Hi Pascal, Arnout, all,
>
> On Wed, Apr 23, 2014 at 5:29 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> > On 23/04/14 16:21, Pascal H?rst wrote:
> >> Hi everyone,
> >>
> >> we are planing to add google-breakpad to buildroot.
> >>
> >> From the project description at
> >> http://code.google.com/p/google-breakpad/:
> >>
> >> [...] "Breakpad is a library and tool suite that allows you to
> >> distribute an application to users with compiler-provided debugging
> >> information removed, record crashes in compact "minidump" files, send
> >> them back to your server, and produce C and C++ stack traces from these
> >> minidumps." [...]
> >>
> >> Adding a package to buildroot is easy, but in this case we will have to
> >> find a way to extract all symbols from the target binaries, before they
> >> get stripped.
>
> Here, you mean adding the host-breakpad package, right?
I acutally mean both sides. Right now it (*.mk) looks something like
that:
GOOGLE_BREAKPAD_VERSION = 1276
GOOGLE_BREAKPAD_SITE = http://google-breakpad.googlecode.com/svn/trunk
GOOGLE_BREAKPAD_SITE_METHOD = svn
GOOGLE_BREAKPAD_CONF_OPT = --disable-processor --disable-tools
$(eval $(host-autotools-package))
$(eval $(autotools-package))
> IIRC, the handler in integrated at the source code level in the
> projects. Do you plan to provide something for the target?
exactly, host and target are needed
> >> My idea was to add a new target to the Makefile, just
> >> before "target-finalize:" and check against an option in the config
> >> like:
> >>
> >> ifeq ($(BR2_ENABLE_BREAKPAD),y)
> >> TARGETS+=target-generate-breakpad-symbols
> >> endif
> >>
> >> and then:
> >>
> >> target-generate-breakpad-symbols:
> >> extract symbols and deploy result to output/images
> >>
> >> Is this basically the way to go, or is there a better way to achieve
> >> this?
> >
> > It is easier to add it to the target-finalize target. Then you can be
> > sure that the ordering is correct (target-finalize already has all the
> > needed dependencies). You can also easily use conditions there (it's not
> > inside a define).
> >
> > However, I think it will be more appropriate to implement breakpad as an
> > additional strip alternative. You probably don't want to combine strip
> > with breakpad...
>
> I think breakpad is more like a pre-strip hook, that one can enable or
> not. But in the end, the target image will be stripped most of the
> time (at least, this is the way I would use such a feature).
I agree, since the extraction of the symbols should always happen, when
breakpad is used, no mater what strip alternative is selected
> > Currently we have none, strip or sstrip, it should be
> > relatively easy to add breakpad as an additional option. Note, however,
> > that the strip code is very old, it doesn't satisfy our coding style so
> > we'll probably want you to do some cleanup first. Also, it is currently
> > untested in the autobuilders AFAIK.
> >
>
> Regards,
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140423/a29df25c/attachment.asc>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Adding google-breakpad to buildroot
2014-04-23 16:12 ` Pascal Hürst
@ 2014-04-23 21:13 ` Arnout Vandecappelle
2014-04-24 7:52 ` Pascal Hürst
0 siblings, 1 reply; 6+ messages in thread
From: Arnout Vandecappelle @ 2014-04-23 21:13 UTC (permalink / raw)
To: buildroot
On 23/04/14 18:12, Pascal H?rst wrote:
> On Mit, 2014-04-23 at 17:52 +0200, Samuel Martin wrote:
>> Hi Pascal, Arnout, all,
>>
>> On Wed, Apr 23, 2014 at 5:29 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>> On 23/04/14 16:21, Pascal H?rst wrote:
[snip]
>>> It is easier to add it to the target-finalize target. Then you can be
>>> sure that the ordering is correct (target-finalize already has all the
>>> needed dependencies). You can also easily use conditions there (it's not
>>> inside a define).
>>>
>>> However, I think it will be more appropriate to implement breakpad as an
>>> additional strip alternative. You probably don't want to combine strip
>>> with breakpad...
>>
>> I think breakpad is more like a pre-strip hook, that one can enable or
>> not. But in the end, the target image will be stripped most of the
>> time (at least, this is the way I would use such a feature).
>
> I agree, since the extraction of the symbols should always happen, when
> breakpad is used, no mater what strip alternative is selected
OK, I thought breakpad did stripping already.
In that case, I think it's best to put it in target-finalize just before
strip.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140423/84180dd6/attachment.asc>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Adding google-breakpad to buildroot
2014-04-23 21:13 ` Arnout Vandecappelle
@ 2014-04-24 7:52 ` Pascal Hürst
0 siblings, 0 replies; 6+ messages in thread
From: Pascal Hürst @ 2014-04-24 7:52 UTC (permalink / raw)
To: buildroot
On Mit, 2014-04-23 at 23:13 +0200, Arnout Vandecappelle wrote:
> On 23/04/14 18:12, Pascal H?rst wrote:
> > On Mit, 2014-04-23 at 17:52 +0200, Samuel Martin wrote:
> >> Hi Pascal, Arnout, all,
> >>
> >> On Wed, Apr 23, 2014 at 5:29 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> >>> On 23/04/14 16:21, Pascal H?rst wrote:
> [snip]
> >>> It is easier to add it to the target-finalize target. Then you can be
> >>> sure that the ordering is correct (target-finalize already has all the
> >>> needed dependencies). You can also easily use conditions there (it's not
> >>> inside a define).
> >>>
> >>> However, I think it will be more appropriate to implement breakpad as an
> >>> additional strip alternative. You probably don't want to combine strip
> >>> with breakpad...
> >>
> >> I think breakpad is more like a pre-strip hook, that one can enable or
> >> not. But in the end, the target image will be stripped most of the
> >> time (at least, this is the way I would use such a feature).
> >
> > I agree, since the extraction of the symbols should always happen, when
> > breakpad is used, no mater what strip alternative is selected
>
> OK, I thought breakpad did stripping already.
>
> In that case, I think it's best to put it in target-finalize just before
> strip.
Ok, I'll do it that way, then.
Thanks!
> Regards,
> Arnout
Regards
Pascal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140424/990dae1f/attachment.asc>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-04-24 7:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-04-23 14:21 [Buildroot] Adding google-breakpad to buildroot Pascal Hürst
2014-04-23 15:29 ` Arnout Vandecappelle
2014-04-23 15:52 ` Samuel Martin
2014-04-23 16:12 ` Pascal Hürst
2014-04-23 21:13 ` Arnout Vandecappelle
2014-04-24 7:52 ` Pascal Hürst
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox