[patch 0/10] debug-early merge

[patch 0/10] debug-early merge

[Aldy Hernandez]

Hi folks.

I have divided the patches into 10 pieces.  The patches are 
interdependent and cannot be applied independently.  I am merely 
dividing them up to aid the relevant reviewers.

As I've mentioned elsewhere, the patchset as posted has been 
bootstrapped and GCC tested on:

	x86_64-unknown-linux-gnu
	powerpc-ibm-aix7.1.2.0
	powerpc64-unknown-linux-gnu
	aarch64-unknown-linux-gnu

I have also GDB tested the patchset on x86_64-linux.

Thanks for your help in this ordeal.

Bring it on!
Aldy

Re: [patch 0/10] debug-early merge

[Richard Biener]

On Fri, May 8, 2015 at 2:30 AM, Aldy Hernandez <aldyh@redhat.com> wrote:
> Hi folks.
>
> I have divided the patches into 10 pieces.  The patches are interdependent
> and cannot be applied independently.  I am merely dividing them up to aid
> the relevant reviewers.
>
> As I've mentioned elsewhere, the patchset as posted has been bootstrapped
> and GCC tested on:
>
>         x86_64-unknown-linux-gnu
>         powerpc-ibm-aix7.1.2.0
>         powerpc64-unknown-linux-gnu
>         aarch64-unknown-linux-gnu
>
> I have also GDB tested the patchset on x86_64-linux.

I've looked over all but the middle-end changes (heh), and I wonder if most
of the other stuff (Java method aliases cleanup, global-decl-wrapup and other
FE specific stuff) can be split out from the main work and reviewed / committed
independently.

I'll go over the "meat" of the changes early next week.

Thanks for doing all this work!

Richard.

> Thanks for your help in this ordeal.
>
> Bring it on!
> Aldy

Re: [patch 0/10] debug-early merge

[David Malcolm]

On Thu, 2015-05-07 at 17:30 -0700, Aldy Hernandez wrote:
> Hi folks.
> 
> I have divided the patches into 10 pieces.  The patches are 
> interdependent and cannot be applied independently.  I am merely 
> dividing them up to aid the relevant reviewers.
> 
> As I've mentioned elsewhere, the patchset as posted has been 
> bootstrapped and GCC tested on:
> 
> 	x86_64-unknown-linux-gnu
> 	powerpc-ibm-aix7.1.2.0
> 	powerpc64-unknown-linux-gnu
> 	aarch64-unknown-linux-gnu
> 
> I have also GDB tested the patchset on x86_64-linux.
> 
> Thanks for your help in this ordeal.

Aldy: did you test the jit with this?  Specifically, is gdb still able
to step through the generated code/inspect values? 
etc; see e.g:
https://gcc.gnu.org/onlinedocs/jit/intro/tutorial04.html#single-stepping-through-the-generated-code

Sadly the jit testsuite doesn't yet automatically verify that sane
debuginfo is generated; I've only ever hand-tested that (this is PR
jit/64196).

Alternatively, I guess I can try your branch if that's easier (exactly
which should I test?)

Dave

Re: [patch 0/10] debug-early merge

[Aldy Hernandez]

On 05/08/2015 07:41 AM, David Malcolm wrote:
> On Thu, 2015-05-07 at 17:30 -0700, Aldy Hernandez wrote:
>> Hi folks.
>>
>> I have divided the patches into 10 pieces.  The patches are
>> interdependent and cannot be applied independently.  I am merely
>> dividing them up to aid the relevant reviewers.
>>
>> As I've mentioned elsewhere, the patchset as posted has been
>> bootstrapped and GCC tested on:
>>
>> 	x86_64-unknown-linux-gnu
>> 	powerpc-ibm-aix7.1.2.0
>> 	powerpc64-unknown-linux-gnu
>> 	aarch64-unknown-linux-gnu
>>
>> I have also GDB tested the patchset on x86_64-linux.
>>
>> Thanks for your help in this ordeal.
>
> Aldy: did you test the jit with this?  Specifically, is gdb still able
> to step through the generated code/inspect values?
> etc; see e.g:
> https://gcc.gnu.org/onlinedocs/jit/intro/tutorial04.html#single-stepping-through-the-generated-code
>
> Sadly the jit testsuite doesn't yet automatically verify that sane
> debuginfo is generated; I've only ever hand-tested that (this is PR
> jit/64196).

If the jit doesn't have a testsuite that runs from "make check", then no.

>
> Alternatively, I guess I can try your branch if that's easier (exactly
> which should I test?)

I will not be upset if you can test :).  Just checkout the branch 
(origin/aldyh/debug-early) and build/use it normally.  There should not 
be any differences to mainline.  If there are, it's a bug that must be 
fixed.

Let me know, and thanks!

Aldy

Re: [PATCH] Non-working jit patch for debug-early (was Re: [patch 0/10] debug-early merge)

[Aldy Hernandez]

On 05/08/2015 10:38 AM, David Malcolm wrote:

> I tested your branch (at 09263eae7c260c305fa19ffa186afd1d89654fb8) with
> the jit configuration from the docs:
>
> ../src/configure \
>   --enable-host-shared \
>     --enable-languages=jit,c++ \
>     --disable-bootstrap \
>     --enable-checking=release \
>     --prefix=$PREFIX
>
> Sadly, the jit "frontend" fails to compile:

Whoops.  My bad.  I was unaware `jit' needed to be added to 
--enable-languages.  I thought it was tested automatically.

>
> ../../src/gcc/jit/jit-playback.c: In member function ‘void
> gcc::jit::playback::context::write_global_decls_2()’:
> ../../src/gcc/jit/jit-playback.c:710:20: error: ‘const struct
> gcc_debug_hooks’ has no member named ‘global_decl’
>         debug_hooks->global_decl (decl);

The basic idea is that if your globals do NOT make it to 
rest_of_decl_compilation(), you need to call 
debug_hooks->early_global_decl() on them manually after parsing.

On the other hand, if your functions do NOT make it to the symbol table 
then you also need to call debug_hooks->early_global_decl() on them 
after parsing (see finalize_compilation_unit()).

The call to debug_hooks->late_global_decl() should be handled 
automagically.  I mean, I assume your symbols (functions and globals, 
etc) make it to the symbol table, in which case they'll be picked up by 
either compile_file() or by analyze_functions().  The latter in case the 
symbol was optimized away and is about to be removed from the symbol table.

Does this help?  If it doesn't, I can gladly take over this on Monday.

>                      ^
> since the "global_decl" debug hook has gone away.  I see that
>    LANG_HOOKS_WRITE_GLOBALS
> also is no more, and this leads to various code in the jit becoming
> dead:
> ../../src/gcc/jit/dummy-frontend.c:225:1: warning: ‘void
> jit_langhook_write_globals()’ defined but not used [-Wunused-function]
>
>
> The attached patch gets it to compile, and eliminates the now-dead code,
> but it's not clear to me how global variables are meant to be created in
> the debug-early world.

Thanks for working on this.

Aldy

Re: [patch 0/10] debug-early merge

[Kyrill Tkachov]

Hi Aldy,

On 08/05/15 01:30, Aldy Hernandez wrote:
> Hi folks.
>
> I have divided the patches into 10 pieces.  The patches are
> interdependent and cannot be applied independently.  I am merely
> dividing them up to aid the relevant reviewers.
>
> As I've mentioned elsewhere, the patchset as posted has been
> bootstrapped and GCC tested on:
>
> 	x86_64-unknown-linux-gnu
> 	powerpc-ibm-aix7.1.2.0
> 	powerpc64-unknown-linux-gnu
> 	aarch64-unknown-linux-gnu

I bootstrapped the branch (aldyh/debug-early from the git mirror, I hope ;))
on arm-none-linux-gnueabihf --with-float=hard --with-cpu=cortex-a15 --with-mode=thumb --with-fpu=neon-vfpv4 --enable-languages=c,c++,fortran which is my usual arm bootstrap config.

It completed ok.

Cheers,
Kyrill

>
> I have also GDB tested the patchset on x86_64-linux.
>
> Thanks for your help in this ordeal.
>
> Bring it on!
> Aldy
>

Re: [patch 0/10] debug-early merge

[Aldy Hernandez]

Perfect. Thanks for doing this.

Aldy

On May 11, 2015 4:23 AM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
>
> Hi Aldy, 
>
> On 08/05/15 01:30, Aldy Hernandez wrote: 
> > Hi folks. 
> > 
> > I have divided the patches into 10 pieces.  The patches are 
> > interdependent and cannot be applied independently.  I am merely 
> > dividing them up to aid the relevant reviewers. 
> > 
> > As I've mentioned elsewhere, the patchset as posted has been 
> > bootstrapped and GCC tested on: 
> > 
> > x86_64-unknown-linux-gnu 
> > powerpc-ibm-aix7.1.2.0 
> > powerpc64-unknown-linux-gnu 
> > aarch64-unknown-linux-gnu 
>
> I bootstrapped the branch (aldyh/debug-early from the git mirror, I hope ;)) 
> on arm-none-linux-gnueabihf --with-float=hard --with-cpu=cortex-a15 --with-mode=thumb --with-fpu=neon-vfpv4 --enable-languages=c,c++,fortran which is my usual arm bootstrap config. 
>
> It completed ok. 
>
> Cheers, 
> Kyrill 
>
> > 
> > I have also GDB tested the patchset on x86_64-linux. 
> > 
> > Thanks for your help in this ordeal. 
> > 
> > Bring it on! 
> > Aldy 
> > 
>