Previously, if the input file was missing, the symupload tool on Mac
would happily process, try to parse it (calling a method on nil) and
fail when trying to create the payload to send to the server as one
of the method raised a NSInvalidArgumentException when receiving a
nil value.
Change to code to instead check the file for existence which makes it
easier to understand what is happening when part of the build system
is misconfigured and invoke symupload without first creating the symbol
file.
BUG=449348
Change-Id: Icc0f08958114da4be0cbbd7a7c2aeef905bc0db1
Reviewed-on: https://chromium-review.googlesource.com/367260
Reviewed-by: Mark Mentovai <mark@chromium.org>
symupload printed -[NSData length], an NSUInteger, using %lu. %lu is proper
to print a "long" as unsigned, but NSUInteger is a typedef for "unsigned int"
when building for 32-bit. This would not have caused any problems, because in
the 32-bit model, both int and long are 32 bits wide. In the 64-bit model,
long is 64 bits wide, but NSUInteger is defiend as "unsigned long", so there
wouldn't have even been a warning in that case.
This addresses the following warning:
symupload.m:137:30:{137:28-137:31}{137:46-137:59}: warning: conversion specifies type 'unsigned long' but the argument has type 'NSUInteger' (aka 'unsigned int') [-Wformat]
Review URL: http://breakpad.appspot.com/313002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@860 4c0a9323-5329-0410-9bdc-e9ce6186880e
- Calculate unique file id for mach-o files
- Add file id support to dump_syms and symupload tools
- Fix return values of tools to indicate success or failure
- Change dump_syms class to be Objective-C++
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@109 4c0a9323-5329-0410-9bdc-e9ce6186880e
