Re: PATCH: 2 stage BFD linker for LTO plugin
On Mon, Dec 6, 2010 at 5:19 PM, Cary Coutant wrote: I see no particular reason why that should be the case. The issues are conceptually simple. >>> >>> I'd like to a gold implementation which works on all known cases. > > You'd like to what? I'd like to see gold implementation which works on all known cases. >> BTW, gold LTO plugin miscompiled 416.gamess in SPEC CPU 2006: >> >> http://www.sourceware.org/bugzilla/show_bug.cgi?id=12244 >> >> BFD linker plugin is OK. > > I can't tell for sure from either bug report, but is this the -lm > problem discussed earlier in this thread? The gcc driver needs to add > -lm as a pass-through library when -lm is on the command line. > I am using libm.so in this case. I am not sure if add -lm as a pass-through library will help. -- H.J.
Re: PATCH: 2 stage BFD linker for LTO plugin
>>> I see no particular reason why that should be the case. The issues are >>> conceptually simple. >> >> I'd like to a gold implementation which works on all known cases. You'd like to what? > BTW, gold LTO plugin miscompiled 416.gamess in SPEC CPU 2006: > > http://www.sourceware.org/bugzilla/show_bug.cgi?id=12244 > > BFD linker plugin is OK. I can't tell for sure from either bug report, but is this the -lm problem discussed earlier in this thread? The gcc driver needs to add -lm as a pass-through library when -lm is on the command line. -cary
Re: PATCH: 2 stage BFD linker for LTO plugin
On Mon, Dec 6, 2010 at 5:02 PM, H.J. Lu wrote: > On Mon, Dec 6, 2010 at 4:08 PM, Ian Lance Taylor wrote: >> "H.J. Lu" writes: >> >>> On Mon, Dec 6, 2010 at 3:54 PM, Ian Lance Taylor wrote: Alan Modra writes: > On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote: >> Personally, I think 2 stage linking is one way to fix this issue. > > Ian has stated that he thinks this is a really bad idea. I haven't > approved the patch because I value Ian's opinion, and can see why he > thinks it is the wrong way to go. On the other hand, BFD is full of > bad ideas.. I'm not strongly opposed to your patch myself. Why don't we spend a short amount of time fixing these relatively minor issues in lto-plugin without going all the way to two-stage linking? >>> >>> The issues may be "relatively minor". But proper fix without >>> two-stage linking may be quite tricky. >> >> I see no particular reason why that should be the case. The issues are >> conceptually simple. > > I'd like to a gold implementation which works on all known cases. > BTW, gold LTO plugin miscompiled 416.gamess in SPEC CPU 2006: http://www.sourceware.org/bugzilla/show_bug.cgi?id=12244 BFD linker plugin is OK. -- H.J.
Re: PATCH: 2 stage BFD linker for LTO plugin
On Mon, Dec 6, 2010 at 4:08 PM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> On Mon, Dec 6, 2010 at 3:54 PM, Ian Lance Taylor wrote: >>> Alan Modra writes: >>> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote: > Personally, I think 2 stage linking is one way to fix this issue. Ian has stated that he thinks this is a really bad idea. I haven't approved the patch because I value Ian's opinion, and can see why he thinks it is the wrong way to go. On the other hand, BFD is full of bad ideas.. I'm not strongly opposed to your patch myself. >>> >>> Why don't we spend a short amount of time fixing these relatively minor >>> issues in lto-plugin without going all the way to two-stage linking? >> >> The issues may be "relatively minor". But proper fix without >> two-stage linking may be quite tricky. > > I see no particular reason why that should be the case. The issues are > conceptually simple. I'd like to a gold implementation which works on all known cases. -- H.J.
Re: PATCH: 2 stage BFD linker for LTO plugin
"H.J. Lu" writes: > On Mon, Dec 6, 2010 at 3:54 PM, Ian Lance Taylor wrote: >> Alan Modra writes: >> >>> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote: Personally, I think 2 stage linking is one way to fix this issue. >>> >>> Ian has stated that he thinks this is a really bad idea. I haven't >>> approved the patch because I value Ian's opinion, and can see why he >>> thinks it is the wrong way to go. On the other hand, BFD is full of >>> bad ideas.. I'm not strongly opposed to your patch myself. >> >> Why don't we spend a short amount of time fixing these relatively minor >> issues in lto-plugin without going all the way to two-stage linking? > > The issues may be "relatively minor". But proper fix without > two-stage linking may be quite tricky. I see no particular reason why that should be the case. The issues are conceptually simple. Ian
Re: "ld -r" on mixed IR/non-IR objects (
On Mon, Dec 6, 2010 at 3:09 PM, Andi Kleen wrote: >> On Mon, Dec 6, 2010 at 2:43 PM, Andi Kleen wrote: Hi, "ld -r" doesn't work with mixed IR/non-IR objects: http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291 >>> >>> There are various bugs for it in gcc bugzilla too. >>> Some compilers support it. Should it be supported? >>> >>> Yes. I've been working on it (slim lto was the first part needed for it, >>> without slim lto it's imho hopeless) >> >> Slim lto is a workaround, not a real solution. > > Actually I consider fat lto as a workaround for toolchain deficiencies. > Generating everything twice and throwing one copy away is always > inefficient. IMHO slim lto is the natural way to do LTO. The idea is the same object file can be used with compilers which don't support LTO. > The only problem is that you need to fix every piece in the toolchain > to not mess up LTO. > > That's why I did the gcc-ar,nm etc. wrappers. There were other problems > too, like gcc's build system itself not handling LTO correctly (it normally > only works because fat saves the day) > >> I think this support should >> be >> implemented in ld with help from GCC. > > Without slim lto you never know if a duplicate symbol is a mistake > of the programmer or just the "fat lto" copy. Also ELF semantics > like weak are hard if you have multiple copies. > It isn't easy, but doable. -- H.J.
Re: PATCH: 2 stage BFD linker for LTO plugin
On Mon, Dec 6, 2010 at 3:55 PM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> I don't have such programs at hand. Will timings from gccgo, which is >> written in C++, help? > > gccgo by itself is not really a large C++ program. It's only about > 50,000 lines of C++. > > Building gcc with --enable-build-with-cxx would get you a large C++ > program, but of course it would not be very typical of C++ programs. > I can give it a try if it will help make a decision. -- H.J.
Re: PATCH: 2 stage BFD linker for LTO plugin
On Mon, Dec 6, 2010 at 3:54 PM, Ian Lance Taylor wrote: > Alan Modra writes: > >> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote: >>> Personally, I think 2 stage linking is one way to fix this issue. >> >> Ian has stated that he thinks this is a really bad idea. I haven't >> approved the patch because I value Ian's opinion, and can see why he >> thinks it is the wrong way to go. On the other hand, BFD is full of >> bad ideas.. I'm not strongly opposed to your patch myself. > > Why don't we spend a short amount of time fixing these relatively minor > issues in lto-plugin without going all the way to two-stage linking? The issues may be "relatively minor". But proper fix without two-stage linking may be quite tricky. > Both Cary and I made several suggestions for how to do this. Fixing all known/unknown issues may not be easy without two-stage linking. With two-stage linking, everything just works. -- H.J.
Re: PATCH: 2 stage BFD linker for LTO plugin
"H.J. Lu" writes: > I don't have such programs at hand. Will timings from gccgo, which is > written in C++, help? gccgo by itself is not really a large C++ program. It's only about 50,000 lines of C++. Building gcc with --enable-build-with-cxx would get you a large C++ program, but of course it would not be very typical of C++ programs. Ian
Re: PATCH: 2 stage BFD linker for LTO plugin
Alan Modra writes: > On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote: >> Personally, I think 2 stage linking is one way to fix this issue. > > Ian has stated that he thinks this is a really bad idea. I haven't > approved the patch because I value Ian's opinion, and can see why he > thinks it is the wrong way to go. On the other hand, BFD is full of > bad ideas.. I'm not strongly opposed to your patch myself. Why don't we spend a short amount of time fixing these relatively minor issues in lto-plugin without going all the way to two-stage linking? Both Cary and I made several suggestions for how to do this. Ian
The Linux binutils 2.21.51.0.2 is released
This is the beta release of binutils 2.21.51.0.2 for Linux, which is
based on binutils 2010 1206 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.21.51.0.2 release, BFD linker has the working LTO
plugin support. It can be used with GCC 4.5 and above. For GCC 4.5, you
need to configure GCC with --enable-gold to enable LTO plugin support.
Starting from the 2.21.51.0.2 release, binutils fully supports compressed
debug sections. However, compressed debug section isn't turned on by
default in assembler. I am planning to turn it on for x86 assembler in
the future release, which may lead to the Linux kernel bug messages like
WARNING: lib/ts_kmp.o (.zdebug_aranges): unexpected non-allocatable section.
But the resulting kernel works fine.
Starting from the 2.20.51.0.4 release, no diffs against the previous
release will be provided.
You can enable both gold and bfd ld with --enable-gold=both. Gold will
be installed as ld.gold and bfd ld will be installed as ld.bfd. By
default, ld.bfd will be installed as ld. You can use the configure
option, --enable-gold=both/gold to choose gold as the default linker,
ld. IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both/ld --enable-plugins --enable-threads.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.21.51.0.2 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.21.51.0.1:
1. Update from binutils 2010 1206.
2. Fix BFD and GOLD linker for compressed debug section support.
3. Fix BFD linker plugin support. PR ld/12246, ld/12247, ld/12248,
ld/12277, ld/12288 and ld/12289.
4. Update BFD linker to group .text.exit, text.startup and .text.hot
sections.
5. Fix linker for W_EH_PE_datarel handling. PR ld/12253.
6. Fix array access bug in readelf/elfedit. PR binutils/11742 and
binutils/12235.
7. Support dumping GDB .gdb_index section.
8. Install plugin-api.h.
9. Improve gold.
10. Improve Solaris support.
11. Improve VMS support.
12. Improve Windows support.
13. Improve arm support.
14. Improve bfin support.
15. Improve mips support.
16. Improve s390 support.
17. Improve z80 support.
Changes from binutils 2.20.51.0.12:
1. Update from binutils 2010 1110.
2. Fix ld plugin support. PRs lto/46291 and lto/46319.
3. Fix x86 assembler to properly fold _GLOBAL_OFFSET_TABLE_ in Intel
syntax. PR 12186.
4. Update assembler to ensure that group sign
Re: PATCH: 2 stage BFD linker for LTO plugin
On Mon, Dec 6, 2010 at 3:29 PM, Alan Modra wrote: > On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote: >> Personally, I think 2 stage linking is one way to fix this issue. > > Ian has stated that he thinks this is a really bad idea. I haven't > approved the patch because I value Ian's opinion, and can see why he > thinks it is the wrong way to go. On the other hand, BFD is full of > bad ideas.. I'm not strongly opposed to your patch myself. > > HJ, you showed that link times for gcc did not regress too much with > your 2 stage lto link patch. It would be more interesting to see the > results for a large C++ project, mozilla for example. > I don't have such programs at hand. Will timings from gccgo, which is written in C++, help? -- H.J.
Re: PATCH: 2 stage BFD linker for LTO plugin
On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote: > Personally, I think 2 stage linking is one way to fix this issue. Ian has stated that he thinks this is a really bad idea. I haven't approved the patch because I value Ian's opinion, and can see why he thinks it is the wrong way to go. On the other hand, BFD is full of bad ideas.. I'm not strongly opposed to your patch myself. HJ, you showed that link times for gcc did not regress too much with your 2 stage lto link patch. It would be more interesting to see the results for a large C++ project, mozilla for example. -- Alan Modra Australia Development Lab, IBM
Re: "ld -r" on mixed IR/non-IR objects (
> On Mon, Dec 6, 2010 at 2:43 PM, Andi Kleen wrote: >>> Hi, >>> >>> "ld -r" doesn't work with mixed IR/non-IR objects: >>> >>> http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291 >> >> There are various bugs for it in gcc bugzilla too. >> >>> Some compilers support it. Should it be supported? >> >> Yes. I've been working on it (slim lto was the first part needed for it, >> without slim lto it's imho hopeless) > > Slim lto is a workaround, not a real solution. Actually I consider fat lto as a workaround for toolchain deficiencies. Generating everything twice and throwing one copy away is always inefficient. IMHO slim lto is the natural way to do LTO. The only problem is that you need to fix every piece in the toolchain to not mess up LTO. That's why I did the gcc-ar,nm etc. wrappers. There were other problems too, like gcc's build system itself not handling LTO correctly (it normally only works because fat saves the day) > I think this support should > be > implemented in ld with help from GCC. Without slim lto you never know if a duplicate symbol is a mistake of the programmer or just the "fat lto" copy. Also ELF semantics like weak are hard if you have multiple copies. -Andi
Re: "ld -r" on mixed IR/non-IR objects (
On Mon, Dec 6, 2010 at 2:43 PM, Andi Kleen wrote: >> Hi, >> >> "ld -r" doesn't work with mixed IR/non-IR objects: >> >> http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291 > > There are various bugs for it in gcc bugzilla too. > >> Some compilers support it. Should it be supported? > > Yes. I've been working on it (slim lto was the first part needed for it, > without slim lto it's imho hopeless) Slim lto is a workaround, not a real solution. I think this support should be implemented in ld with help from GCC. -- H.J.
Re: "ld -r" on mixed IR/non-IR objects (
> Hi, > > "ld -r" doesn't work with mixed IR/non-IR objects: > > http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291 There are various bugs for it in gcc bugzilla too. > Some compilers support it. Should it be supported? Yes. I've been working on it (slim lto was the first part needed for it, without slim lto it's imho hopeless) But it's going slow for various reasons. Right now I'm not optimistic 4.6 will support it, which implies it won't be able to build a linux kernel with LTO. -Andi
Re: "ld -r" on mixed IR/non-IR objects (
On 12/06/2010 02:30 PM, H.J. Lu wrote: > Hi, > > "ld -r" doesn't work with mixed IR/non-IR objects: > > http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291 > > Some compilers support it. Should it be supported? > As we discussed in person, I think it would be user friendly to support it, otherwise you'll break any build which uses ld -r and includes assembly objects. -hpa
"ld -r" on mixed IR/non-IR objects (
Hi, "ld -r" doesn't work with mixed IR/non-IR objects: http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291 Some compilers support it. Should it be supported? -- H.J.
Re: combine two load insns
roy rosen writes: > If I have two load SI insns. Is there any way to combine them into one > load DI insn? > Not using peephole which can catch only this limited case of being > sequential insns. > I have seen something done in ARM (*arith_adjacentmem) but it is very > awkward and would not be realistic if the DI is being used by many > different intrinsics. As far as I know there is no general pass which does this at present. So it would currently have to a combine pattern like arith_adjacentmem, or a peephole, or a machine specific pass. On many processors the alignment requirements of DImode and SImode loads are different, so it would be hard to do this as a fully general pass. Ian
Re: PATCH: 2 stage BFD linker for LTO plugin
On Mon, Dec 6, 2010 at 10:19 AM, Dave Korn wrote: > On 06/12/2010 17:44, H.J. Lu wrote: >> On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote: >>> Well, I reckon this patch is great (but don't have the approval rights). >>> It's passed an lto-bootstrap of gcc on i686-pc-cygwin and the tests are well >>> underway without anything abnormal showing up. >>> >> >> Can we close >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690 >> >> as invalid > > It's not invalid; GOLD linking with -static (explicit or implicit) would > still have problems without the pass through. > Personally, I think 2 stage linking is one way to fix this issue. -- H.J.
Re: PATCH: 2 stage BFD linker for LTO plugin
On 06/12/2010 17:44, H.J. Lu wrote: > On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote: >> Well, I reckon this patch is great (but don't have the approval rights). >> It's passed an lto-bootstrap of gcc on i686-pc-cygwin and the tests are well >> underway without anything abnormal showing up. >> > > Can we close > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690 > > as invalid It's not invalid; GOLD linking with -static (explicit or implicit) would still have problems without the pass through. > and point the linker bug to > > http://www.sourceware.org/bugzilla/show_bug.cgi?id=12248 I added a reference to it to the gcc PR and closed it. cheers, DaveK
Re: PATCH: 2 stage BFD linker for LTO plugin
On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote: > > Well, I reckon this patch is great (but don't have the approval rights). > It's passed an lto-bootstrap of gcc on i686-pc-cygwin and the tests are well > underway without anything abnormal showing up. > Can we close http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690 as invalid and point the linker bug to http://www.sourceware.org/bugzilla/show_bug.cgi?id=12248 Thanks. -- H.J.
Re: PATCH: 2 stage BFD linker for LTO plugin
On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote:
> On 06/12/2010 02:20, H.J. Lu wrote:
>
>> BTW, the new linker passed bootstrap-lto with all default languages.
>> I am planning to include this patch in the next Linux binutils.
>>
> I missed the IR object in an archive:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690#c34
>
> This updated patch fixed it. OK for trunk?
>
We shouldn't clear SEC_EXCLUDE if BFD_PLUGIN is set:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690#c38
This updated patch fixed it. OK for trunk?
>>> It turns out that my patch also fixes:
>>>
>>> http://sourceware.org/bugzilla/show_bug.cgi?id=12277
>>>
>>
>> Updated patch, adjusted for plugin ELF symbol visibility bug fix.
>> OK for trunk?
>
> Well, I reckon this patch is great (but don't have the approval rights).
> It's passed an lto-bootstrap of gcc on i686-pc-cygwin and the tests are well
> underway without anything abnormal showing up.
>
>> + /* Free the old already linked table and create a new one. */
>> + bfd_section_already_linked_table_free ();
>> + if (!bfd_section_already_linked_table_init ())
>> + einfo (_("%P%F: Failed to create hash table\n"));
>> +
>> + /* Free the old hash table and create a new one. */
>> + bfd_link_hash_table_free (link_info.output_bfd,
>> + link_info.hash);
>> + link_info.hash
>> + = bfd_link_hash_table_create (link_info.output_bfd);
>> + if (link_info.hash == NULL)
>> + einfo (_("%P%F: can not create hash table: %E\n"));
>
> If I had known that there was really this little stored state to be unwound
> and regenerated, I would have wanted to do it this way in the first place.
>
>> +typedef struct cmdlin_header_struct
>
> Typo there.
Fixed.
> Tristan, sorry, you must be sick of hearing from me by now, but I notice the
> branch was still labile a couple of hours ago... it would be really good if we
> could get HJ's patch approved and backported before you spin the release.
I also fixed a bunch other plugin bugs on trrunk. If we want a BFD linker with
working plugin support in binutils 2.21, we should just copy all pluging changes
on my hjl/lto branch at
http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary
into 2.21.
Thanks.
--
H.J.
Re: PATCH: 2 stage BFD linker for LTO plugin
On 06/12/2010 02:20, H.J. Lu wrote:
> BTW, the new linker passed bootstrap-lto with all default languages.
> I am planning to include this patch in the next Linux binutils.
>
I missed the IR object in an archive:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690#c34
This updated patch fixed it. OK for trunk?
>>> We shouldn't clear SEC_EXCLUDE if BFD_PLUGIN is set:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690#c38
>>>
>>> This updated patch fixed it. OK for trunk?
>>>
>> It turns out that my patch also fixes:
>>
>> http://sourceware.org/bugzilla/show_bug.cgi?id=12277
>>
>
> Updated patch, adjusted for plugin ELF symbol visibility bug fix.
> OK for trunk?
Well, I reckon this patch is great (but don't have the approval rights).
It's passed an lto-bootstrap of gcc on i686-pc-cygwin and the tests are well
underway without anything abnormal showing up.
> + /* Free the old already linked table and create a new one. */
> + bfd_section_already_linked_table_free ();
> + if (!bfd_section_already_linked_table_init ())
> + einfo (_("%P%F: Failed to create hash table\n"));
> +
> + /* Free the old hash table and create a new one. */
> + bfd_link_hash_table_free (link_info.output_bfd,
> + link_info.hash);
> + link_info.hash
> + = bfd_link_hash_table_create (link_info.output_bfd);
> + if (link_info.hash == NULL)
> + einfo (_("%P%F: can not create hash table: %E\n"));
If I had known that there was really this little stored state to be unwound
and regenerated, I would have wanted to do it this way in the first place.
> +typedef struct cmdlin_header_struct
Typo there.
Tristan, sorry, you must be sick of hearing from me by now, but I notice the
branch was still labile a couple of hours ago... it would be really good if we
could get HJ's patch approved and backported before you spin the release.
cheers,
DaveK
Re: A possible super feature to add to gcc
AspertameMan wrote:
> Back in the 1970's when we ran fortran on an IBM machine we had this
> really powerful command called CALL FDUMP that if inserted into a
> program would send the names and values of every variable, at the time
> of its call, to a printer or file. [...]
This sounds like a job for a scriptable debugger, or systemtap
probe process("a.out").statement("*...@file.c:444") { log($$vars$$) }
or somesuch run-time tool.
- FChE
how to output function prototypes from a plugin
I am writing a plugin that should dump out function declarations and definitions as the compiler sees them. One thing that I noticed (besides that Brian Hackett's PLUGIN_FINISH_DECL hook should really be applied to future versions) was that there does not seem to be a function that could output the full prototype of a function in a standardized form. I found lhd_decl_printable_name() which only gives me the name but not the full declaration and there are some pretty printer routines for C in c-pretty-print.c and tree-pretty-print.c and for C++ it seems that what I need lives in cp/error.c. All of those functions are static... Have I missed anything? Thank you very much, Joachim
Re: A possible super feature to add to gcc
Aspertame Man writes: > After looking on the internet on the term "dumping core" I noticed that > one had to write a piece of code to cause the crash. Try looking for gcore. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different."
Re: A possible super feature to add to gcc
> Simply building in a small standardized intrinsic function name to a > common crash function that computer scientists might write to cause > a core dump would make the compiler more user friendly to the non > computer science crowd. I'm confused. Why isn't "abort" the function that you want?
Re: A possible super feature to add to gcc
After looking on the internet on the term "dumping core" I noticed that one had to write a piece of code to cause the crash. I noted that one had to know what to do to cause the crash to get the dump and gathered that while computer scientists and most engineers know how to do this, it is not so obvious to say biologists, chemists, physicists and other users of compilers for their research. Simply building in a small standardized intrinsic function name to a common crash function that computer scientists might write to cause a core dump would make the compiler more user friendly to the non computer science crowd. Instead of fdump call it "coredump". Second there are applications that can take hours to days to execute. These sorts of programs are not well suited for debug with an interactive debugger because of the time reason. One may likely have to wait a long time to interactively tell the program to "resume" and possibly multiple times. With coredump() the argument could be used to tell the program whether or not to resume and then the programmer could be in a meeting instead of monitoring an interactive debugger to resume. This would be even more useful if the programmer wanted to make a call to coredump() at multiple places in the program in a single execution and the scientific program may take a very long time to run unlike computer science operating systems. Standardizing a coredump intrinsic function with an argument that can trigger invoking a compiler option to resume cant take more that a couple hours by a good programer thereby adding some user friendly fit and finish for the non computer scientist crowd. I'm out of the loop unless addressed directly On Sun, 2010-12-05 at 18:04 -0500, Joern Rennecke wrote: Quoting Aspertame Man : > > > > > Back in the 1970's when we ran fortran on an IBM machine we had this > > really powerful command called CALL FDUMP that if inserted into a > > program would send the names and values of every variable, at the time > > of its call, to a printer or file. In my opinion this was much more > > useful at times than a symbolic debugger, in scientific number crunching > > applications. > > I don't see how this would be better than dumping core and resuming > execution. > I suppose you might even do a fork before dumping core, that might speed up > if you have multiple CPU cores and copy-on-write memory semantics. >
