On Tue, Feb 17, 2015 at 09:56:20AM +0100, Jakub Jelinek wrote:
On Tue, Feb 17, 2015 at 08:45:09AM +0000, Andrew Haley wrote:
> On 17/02/15 07:21, David Airlie wrote:
>
> > Well I can't provide any info, I don't have an ARM box here, and it
> > happens in the buildroot which I don't think I can access to get the
> > files out from.
>
> I've been bitten by this several times. We need to find a better way
> to handle issues like this: when a build goes wrong a GCC developer
> needs to be able to see what went wrong, and that means direct access
> to the box so that they can reproduce the problem.
>
> So what might we do to solve this? Is there some way that we can
> "freeze" the contents of a buildroot to allow a dev to get in there
> and poke around?
In most cases when the bug is reproduceable and a single preprocessed
source is enough (e.g. not LTO build etc.), the gcc driver dumps all the
required info into /tmp/.
That is the -freport-bug
Preprocessed source stored into /tmp/ccXXXXXX.out file, please attach this to your
bugreport.
message.
So, if mock + koji copied those over (best xz or bzip2 compressed) alongside with
build.log / root.log etc. in case the build failed, that would be very much
appreciated.
Indeed, reproducing the failures only to get a /tmp/ccXXXXXX.out file
is not exactly fun.
In a related vein, I think ABRT should bundle the /tmp/ccXXXXXX.out
files to its reports as well. From time to time we get reports as
<
https://bugzilla.redhat.com/show_bug.cgi?id=1189122>, but such a bug
report is largely useless without preprocessed source + command-line
options.
Sorry if I'm driving this off-topic.
Marek