12 Commits

Author SHA1 Message Date
Michael Krebs
7515d89be7 Dynamically use the 32-bit dump_syms for files when needed
'dump_syms' was recently changed to be built 64-bit, with a 32-bit version
available as 'dump_syms.32'.  This change makes use of the 32b dump_syms if
a file is built 32b.  For almost all targets nowadays, we should only see
64b files, but things like the installer can still be 32b.  Also see
https://gerrit.chromium.org/gerrit/14835.

BUG=chromium-os:22778
TEST=Ran cros_generate_breakpad_symbols on 32/64-bit executables
CQ-DEPEND=I6551fe22fb0caebd3584f76f95a543e9a91b7e1b

Change-Id: I780c20eeb745a919dbe130cf3cede7ec5ca6483a
Reviewed-on: https://gerrit.chromium.org/gerrit/18569
Commit-Ready: Michael Krebs <mkrebs@chromium.org>
Tested-by: Michael Krebs <mkrebs@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
2012-03-26 19:48:21 -07:00
Brian Harring
aa13ea4658 Shift crosutils scripts to use the common.sh they were written against.
Rather than trying to use an old/stale common.sh, use the common.sh
from the invocation point- if invoked via /usr/lib/crosutils, use that
common.sh.  If invoked via src/scripts/, use that, etc.

Trying to intermix it just introduces potential for bugs and invalidly
freezes common.sh api, thus the efforts to revert this and ultimately
revert the existing of a crosutils ebuild.

BUG=chromium-os:27201
TEST=cbuildbot x86-generic-full

Change-Id: I4c6c5fbade3d28c71752bd4c44dccad49af52ec0
Reviewed-on: https://gerrit.chromium.org/gerrit/18303
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Brian Harring <ferringb@chromium.org>
Tested-by: Brian Harring <ferringb@chromium.org>
2012-03-15 23:35:06 -07:00
Michael Krebs
104d20d8ea Don't generate symbols for files that dump_syms can't handle.
dump_syms can only dump the symbols of an executable with the same ELF
format as itself.  Some recent build configurations now have binaries with
differing ELF formats.  For example, issue 25468 has a 64-bit kernel where
everything else is 32-bit, and issue 25466 indicates there's a test that
contains a 32-bit executable.

BUG=chromium-os:25496, chromium-os:25468, chromium-os:25466
TEST=Ran cros_generate_breakpad_symbols on 32/64-bit executables

Change-Id: I15f5115585b3ed54ca7ae7b631216285baef8580
Reviewed-on: https://gerrit.chromium.org/gerrit/14835
Tested-by: Michael Krebs <mkrebs@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Michael Krebs <mkrebs@chromium.org>
2012-01-25 17:47:25 -08:00
Vincent Palatin
08df4201a7 Fix amd64 platform detection for minidump symbols generation
Not all 64-bit platforms have names starting with amd64-, so we should
use portageq to get the board architecture name.

BUG=chromium-os:25228
TEST=./cros_generate_breakpad_symbols --board=x86-alex, amd64-corei7, link

Change-Id: I83769575dbd19112b929724995d0c97ed4df2b02
Reviewed-on: https://gerrit.chromium.org/gerrit/14444
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
2012-01-19 04:57:48 -08:00
David James
2ea8a7859e Don't skip over /usr/local/autotest when generating symbols.
Right now, the buildbot won't symbolize any crash that occurs in autotest
because all symbols in /usr/local/autotest are skipped by breakpad. Tweak
cros_generate_breakpad_symbols to not skip over these symbols so that
browser test crashes can be symbolized.

BUG=chromium-os:25061
TEST=Run cros_generate_breakpad_symbols and verify it still completes
     successfully, and generates working symbols for autotest that can
     be used to symbolize browser test crashes.

Change-Id: I072498060e78b373bd12c94ff95465878301cbce
Reviewed-on: https://gerrit.chromium.org/gerrit/14155
Commit-Ready: David James <davidjames@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
2012-01-13 15:37:51 -08:00
David James
74d6249356 Clean old breakpad symbols prior to generating new ones.
If we're generating new breakpad symbols, we don't need to keep the
old ones around. Keeping the old ones forever means the debug tarballs
get really large (e.g. >10GB).

This problem makes incremental bots get slower and slower over time. The
chromium.chromiumos bot spends over an hour archiving the debug symbols,
for example.

BUG=chromium-os:24994
TEST=Trybot run of archive stage, generating and uploading debug
     symbols.

Change-Id: Ibf57db2561d29085434439ecd4f23e5cec1f598a
Reviewed-on: https://gerrit.chromium.org/gerrit/14040
Commit-Ready: David James <davidjames@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
2012-01-11 17:48:17 -08:00
Anush Elangovan
d2ea8338fe Use 64bit dump_syms for generating minidump syms on amd64
This is very inefficent in calling dump_syms sequentially this can be parallelized easily and reduce the time it takes (~6mins)

BUG=chromium-os:21914
TEST=./cros_generate_breakpad_symbols --board=x86-alex, amd64-corei7

Change-Id: Ic9d3bbcd2dbccfaeb01e60d757549dcb5c45c03b
Reviewed-on: https://gerrit.chromium.org/gerrit/11747
Reviewed-by: Michael Krebs <mkrebs@chromium.org>
Tested-by: Anush Elangovan <anush@chromium.org>
2011-11-15 18:25:00 -08:00
Ken Mixter
d8f9130863 scripts: fall back to linkage symbols when debug info not present
dump_syms bails if you give it a debug info path and the file there
does not have debug info, instead of falling back to dumping
public/linkage symbols (and more importantly, call frame info).
Give it the chance to redeem itself.

Also, instead of not ever uploading CFI for x86 modules, strip it
for any architecture but only when the file is above some
threshold.

BUG=chromium-os:22373 chromium-os:22741

Change-Id: Iad6981efec537868296a6713b1d9ca0cdb750d28
Reviewed-on: https://gerrit.chromium.org/gerrit/11443
Commit-Ready: Ken Mixter <kmixter@chromium.org>
Reviewed-by: Ken Mixter <kmixter@chromium.org>
Tested-by: Ken Mixter <kmixter@chromium.org>
2011-11-09 18:27:05 -08:00
Brian Harring
d5d5dbffa1 Fix/standardize exiting if common.sh can't be found
The problem here is that most were doing their exiting w/in a subshell;
exit within a subshell kills the subshell, not the parent.  Not all scripts
were using set -e (which would pick up the failing subshell); as such
just rewriting them to remove the potential via eliminateing the subshelling.

Beyond that, removed a couple of custom (working, although non-standard)
approaches, and removed a duplicate common.sh sourc'ing w/in mk_memento_images.sh

TEST=force 'find_common_sh' to fail, note the scripts fails to exit
BUG=none

Change-Id: Ia1108a091a6399ad6aedd3cade4a107f4411686c
Reviewed-on: http://gerrit.chromium.org/gerrit/3905
Reviewed-by: Brian Harring <ferringb@chromium.org>
Tested-by: Brian Harring <ferringb@chromium.org>
2011-07-22 12:06:59 -07:00
Greg Spencer
798d75f3be This starts to fix the scripts so that they load from /usr/lib/crosutils
from within the chroot.

It also fixes a number of style issues.

It changes the meaning of cros_workon "list-all" to list all available
packages, and adds "list-live" to list all live packages.

It changes things that load chromeos-common.sh from the installer to
load it from /usr/lib/installer.

BUG=chromium-os:4230
TEST=synced, rebuilt chroot, made packages, made images, built chrome
from source, and wrote an image to a USB stick.

Review URL: http://codereview.chromium.org/6240018

Change-Id: I90c34420af1a64020402bafef8e9e77f56837c02
2011-02-01 22:04:49 -08:00
Ken Mixter
2fb9892ced crosutils: Use upstream dump_syms parameters for supporting splitdebug
Change-Id: If4eba8779496c4fb0283865da48ba38941de9c08

BUG=9281
TEST=ran without obvious errors

Review URL: http://codereview.chromium.org/5308005
2010-12-07 15:10:25 -08:00
Ken Mixter
bc69d7bae4 Utility to generate minidump symbols for developer diagnostics
BUG=4882, 4886

Review URL: http://codereview.chromium.org/2825054
2010-08-12 17:03:47 -07:00