role of dump_file notably for/in plugins?

[Basile Starynkevitch]

Hello Folks

What is the intended role of the dump_file [the one known in tree-pass.h
near line 101] for plugins?

May plugins print their arbitrary things (e.g. their own debug printing)
inside? I believe that yea, but I am not sure.

May plugins set the dump_file variable (for instance to stderr). I believe
that no, but I am not sure.

Can dump_file be used outside passes (e.g. in the initialization part of a
plugin)? I believe that no, but I hesitate.

Cheers.


-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: role of dump_file notably for/in plugins?

[Richard Guenther]

On Wed, Aug 31, 2011 at 4:24 PM, Basile Starynkevitch
 wrote:
> Hello Folks
>
> What is the intended role of the dump_file [the one known in tree-pass.h
> near line 101] for plugins?
>
> May plugins print their arbitrary things (e.g. their own debug printing)
> inside? I believe that yea, but I am not sure.
>
> May plugins set the dump_file variable (for instance to stderr). I believe
> that no, but I am not sure.
>
> Can dump_file be used outside passes (e.g. in the initialization part of a
> plugin)? I believe that no, but I hesitate.

Look at how it is set.. That answers all of your questions.

Richard.

> Cheers.
>
>
> --
> Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>

Re: role of dump_file notably for/in plugins?

[David Malcolm]

On Wed, 2011-08-31 at 16:28 +0200, Richard Guenther wrote:
> On Wed, Aug 31, 2011 at 4:24 PM, Basile Starynkevitch
>  wrote:
> > Hello Folks
> >
> > What is the intended role of the dump_file [the one known in tree-pass.h
> > near line 101] for plugins?
> >
> > May plugins print their arbitrary things (e.g. their own debug printing)
> > inside? I believe that yea, but I am not sure.
> >
> > May plugins set the dump_file variable (for instance to stderr). I believe
> > that no, but I am not sure.
> >
> > Can dump_file be used outside passes (e.g. in the initialization part of a
> > plugin)? I believe that no, but I hesitate.
> 
> Look at how it is set.. That answers all of your questions.

FWIW, I wrapped writing to "dump_file" in my Python gcc plugin as the
API entrypoint:
   gcc.dump(obj)
but given that it didn't seem to be possible to enable dumping for a
given custom pass by name directly from the command-line, it didn't seem
very useful (you can toggle the dfi->state when the pass is created to
manually enable it, which I've wrapped as the "dump_enabled" property of
a gcc.Pass instance).

Given all of this I tend to simply use "dump_base_name", which I wrapped
as:
   gcc.get_dump_base_name()
to supply a meaningful filename, which I use open a regular file for
writing.

See:
http://readthedocs.org/docs/gcc-python-plugin/en/latest/passes.html#dumping-per-pass-information
and
http://readthedocs.org/docs/gcc-python-plugin/en/latest/passes.html#gcc.Pass.dump_enabled
for more notes on how the Python plugin approaches this.

The relevant code is mostly in:
http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=blob;f=gcc-python.c;h=f6c5f5f284ffddff61195c40bbf6b8d62f7a7a9d;hb=HEAD#l675
and
http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=blob;f=gcc-python-pass.c;h=a54ea9b6d6bd8ecc26f8a305c4e96605d2bd14ab;hb=HEAD#l253

Hope this is helpful
Dave

Linker stumbles over non-grouped .text/.rodata for a C++ function

[Stephan Bergmann]

I am trying to track down an error that can at least be observed when building 
recent versions of LibreOffice (e.g., revision 
bf3ff35d8c96315c35cf8dc8495be4b488b55cb6 of 
git://anongit.freedesktop.org/libreoffice/core) on Fedora 15 i386 (i.e., with 
GCC 4.6.0 20110603 (Red Hat 4.6.0-10)).  The problem is that linking together 
objects via

> g++ -shared vbarange.o vbasheetobjects.o


fails with errors like

> `.L109' referenced in section 
> `.rodata._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_[ScVbaCollectionBase
>  >::Item(com::sun::star::uno::Any const&, com::sun::star::uno::Any const&)]' 
> of vbasheetobjects.o: defined in discarded section 
> `.text._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_[non-virtual
>  thunk to ScVbaCollectionBase 
> >::Item(com::sun::star::uno::Any const&, com::sun::star::uno::Any const&)]' 
> of vbasheetobjects.o

The two C++ files vbarange.cxx and vbasheetobjects.cxx are compiled with 
identical g++ command lines, including switches -fPIC -fno-common -pipe 
-fvisibility=hidden -fvisibility-inlines-hidden -std=c++0x -fexceptions 
-fno-enforce-eh-specs -Os besides more mundane -D, -I, -M, and -W switches.  
Both objects include code for the 
_ZThn20_N19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_
 function, but there are two things that strike me as odd:

First, the code emitted for the two functions is rather different in the two 
object files, even though both are compiled with identical command line 
switches.  One difference is that In vbasheetobjects.o, the code contains a 
.rodata section (see below) with a number of labels into code that follows, 
whereas the code in vbarange.o does not contain such a .rodata section.  Could 
it be that -Os can cause these differences?  (If necessary, I can easily make 
available the -S output for the relevant code from the two different files.)

Second, the directive for the .rodata section mentioned above is

> .section 
> .rodata._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_,"aG",@progbits,_ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_,comdat

while the directive for the corresponding .text section (split in multiple 
parts) is

> .section 
> .text._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_,"axG",@progbits,_ZThn20_N19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_,comdat

Note the difference in the GroupName part of the .section directives, the text 
section using the symbol denoting a non-virtual thunk to the function in 
question.  My understanding of such ELF section groups is weak, but my theory 
is that the .rodata and .text sections should belong to a single group, so that 
the linker would either keep or remove them together. What apparently happens 
instead is that the linker uses the .text section from vbarange.o, drops the 
corresponding .text section from vbasheetobjects.o, and then stumbles over the 
left-over .rodata section.  (Manually adapting the GroupName of the .rodata 
section directive to match the .text section makes the link succeed.)

The problem has been worked around for now in LIbreOffice by compiling 
vbasheetobjects.o without -Os (see 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=148e0ccb50ce419e18e452eb7ccfe03cb4881634
 -- i.e., that change must be reverted before the problem can be observed in 
the code revision mentioned at the beginning).

Can somebody enlighten me why the generated code differs in the first place, 
and whether my theory of non-matching GroupNames is correct?

Thanks,
-Stephan

Re: Linker stumbles over non-grouped .text/.rodata for a C++ function

[Ian Lance Taylor]

Stephan Bergmann  writes:

> I am trying to track down an error that can at least be observed when 
> building recent versions of LibreOffice (e.g., revision 
> bf3ff35d8c96315c35cf8dc8495be4b488b55cb6 of 
> git://anongit.freedesktop.org/libreoffice/core) on Fedora 15 i386 (i.e., with 
> GCC 4.6.0 20110603 (Red Hat 4.6.0-10)).  The problem is that linking together 
> objects via
>
>> g++ -shared vbarange.o vbasheetobjects.o
>
>
> fails with errors like
>
>> `.L109' referenced in section 
>> `.rodata._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_[ScVbaCollectionBase
>>  >::Item(com::sun::star::uno::Any const&, com::sun::star::uno::Any const&)]' 
>> of vbasheetobjects.o: defined in discarded section 
>> `.text._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_[non-virtual
>>  thunk to ScVbaCollectionBase 
>> >::Item(com::sun::star::uno::Any const&, com::sun::star::uno::Any const&)]' 
>> of vbasheetobjects.o

This sounds like a compiler bug.  You are correct that the .text and
.rodata sections should be using the same section group.  Please file a
bug report so it is not forgotten.

That said, this message from the linker is a warning, and you can
normally ignore it.

Ian

Re: Linker stumbles over non-grouped .text/.rodata for a C++ function

[Stephan Bergmann]

On Aug 31, 2011, at 10:07 PM, Ian Lance Taylor wrote:
> Stephan Bergmann  writes:
> 
>> I am trying to track down an error that can at least be observed when 
>> building recent versions of LibreOffice (e.g., revision 
>> bf3ff35d8c96315c35cf8dc8495be4b488b55cb6 of 
>> git://anongit.freedesktop.org/libreoffice/core) on Fedora 15 i386 (i.e., 
>> with GCC 4.6.0 20110603 (Red Hat 4.6.0-10)).  The problem is that linking 
>> together objects via
>> 
>>> g++ -shared vbarange.o vbasheetobjects.o
>> 
>> 
>> fails with errors like
>> 
>>> `.L109' referenced in section 
>>> `.rodata._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_[ScVbaCollectionBase
>>>  >::Item(com::sun::star::uno::Any const&, com::sun::star::uno::Any 
>>> const&)]' of vbasheetobjects.o: defined in discarded section 
>>> `.text._ZN19ScVbaCollectionBaseIN4cppu15WeakImplHelper1IN3ooo3vba11XCollection4ItemERKN3com3sun4star3uno3AnyESD_[non-virtual
>>>  thunk to ScVbaCollectionBase 
>>> >::Item(com::sun::star::uno::Any const&, com::sun::star::uno::Any const&)]' 
>>> of vbasheetobjects.o
> 
> This sounds like a compiler bug.  You are correct that the .text and
> .rodata sections should be using the same section group.  Please file a
> bug report so it is not forgotten.

Done, .

> That said, this message from the linker is a warning, and you can
> normally ignore it.

Hm, for me it resulted in an ld exit code of 1, but maybe that was due to one 
of the additional command line switches apart from -shared when linking (but 
which did not otherwise affect the problem).

-Stephan

Re: ARM summit at Plumbers 2011

[Steve McIntyre]

[ Last big cross-post; I'll just post to the cross-distro list in
  future! ]

On Tue, Aug 23, 2011 at 05:11:34PM +0100, Steve McIntyre wrote:
>On Tue, Aug 09, 2011 at 07:15:34PM +0100, Steve McIntyre wrote:
>
>> [ARM summit at Plumbers, Thursday 8th September]
>
>UPDATE: we've not had many people confirm interest in this event yet,
>which is a shame. If you would like to join us for this session,
>please reply and let me know. If we don't get enough interest by the
>end of Sunday (28th August), then we'll have to cancel the meeting.

And that seemed to provoke enought interest from people all over,
which is good. This event is definitely going on. Let's look forwards
to some good discussion. :-)

Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs

Re: Linker stumbles over non-grouped .text/.rodata for a C++ function

[Ian Lance Taylor]

Stephan Bergmann  writes:

>> That said, this message from the linker is a warning, and you can
>> normally ignore it.
>
> Hm, for me it resulted in an ld exit code of 1, but maybe that was due to one 
> of the additional command line switches apart from -shared when linking (but 
> which did not otherwise affect the problem).

Whoops, you're right, somebody has changed it to an error.  That seems
unfortunate, as it is often harmless.  Sorry about that.

In a pinch you could try -Wl,--noinhibit-exec.

Ian

I am work with lm32 and want to help with the lm32 target in gcc

[Xiangfu Liu]

Hi

I am work with lm32 and want to help with the lm32 target in gcc.
the device name is milkymist one. with FPGA software CPU core lm32.

what is the first step I should do for help with lm32 target in gcc?
I have read this http://gcc.gnu.org/contribute.html#legal
I have to start with small contributions. should I do this legal stuff?

thanks

Re: I am work with lm32 and want to help with the lm32 target in gcc

[Liu]

On Thu, Sep 1, 2011 at 11:00 AM, Xiangfu Liu  wrote:
> Hi
>
> I am work with lm32 and want to help with the lm32 target in gcc.
> the device name is milkymist one. with FPGA software CPU core lm32.
>
> what is the first step I should do for help with lm32 target in gcc?
> I have read this http://gcc.gnu.org/contribute.html#legal
> I have to start with small contributions. should I do this legal stuff?
>
> thanks
>

ask for a assignment, sign it, send it back to FSF, and summit your patch.

--Liu

Re: I am work with lm32 and want to help with the lm32 target in gcc

[Xiangfu Liu]

Hi

can you send me the copyright assignment forms.
it should be an assignment for all future changes, right?

thanks for reply

On 09/01/2011 11:32 AM, Liu wrote:

On Thu, Sep 1, 2011 at 11:00 AM, Xiangfu Liu  wrote:

Hi

I am work with lm32 and want to help with the lm32 target in gcc.
the device name is milkymist one. with FPGA software CPU core lm32.

what is the first step I should do for help with lm32 target in gcc?
I have read this http://gcc.gnu.org/contribute.html#legal
I have to start with small contributions. should I do this legal stuff?

thanks



ask for a assignment, sign it, send it back to FSF, and summit your patch.

--Liu