Re: CVS/SVN binutils and gcc on MacOS X?
On Sep 4, 2009, at 11:06 PM, Stefan Dösinger wrote: Hi, I tried to install binutils from CVS and the gcc SVN code on my mac to test my msvc_prologue work there, but I ran into an interesting problem: When using the SVN gcc with my own as, I cannot compile any files: Assembler messages: Fatal error: Invalid listing option `r' The support in FSF binutils for Darwin is very preliminary: although the assembler passes all the gas tests, it lacks many Mach-O features. I am working on that in a low priority mode. But contributions are welcome! Tristan.
Please recommend a good vcg viewer
Hello, I currently use aiSee (demo version) to view vcg dump of gcc. One problem is that the tool works too slowly. The another problem is that graph looks ugly, especially when unforlding a big cfg. Who can recommend me a good vcg viewer? Thanks. Best Regards, Eric
Re: MSVC hook function prologue
On 09/06/2009 11:15 AM, Stefan Dösinger wrote: Am Saturday 05 September 2009 17:08:19 schrieb Ross Ridge: If this patch is essentially only for one application, maybe the idea of implementing a more generally useful naked attribute would be the way to go. I implemented a naked attribute in my private sources to do something similar, although supporting hookable prologues was just a small part of its more general use in supporting an assembler based API. We don't really like the naked attribute, because it makes maintaining a C function that uses it a pain. Alexandre once said that he would reject any solution for the hook problem that is based on the naked attribute. This especially becomes a pain when the function has to do stack realignment, like all our Win32 functions on OSX. The naked attribute has been proposed and bashed to death multiple times on the GCC list too. Paolo
Re: MSVC hook function prologue
Paolo Bonzini writes: >The naked attribute has been proposed and bashed to death multiple >times on the GCC list too. No, not really. It's been proposed a few times, but the discussion never gets anywhere because the i386 maintainers quickly put their foot down and end it. That hasn't stopped other ports from implementing a naked attribute or for that matter developers like me creating their own private implementations. Ross Ridge
The reincarnation of PR15242
This seems to be an an old bug that has come back. We're generating L1210: jmp *%eax .L4: .L5: ... jmp .L1210 .L1171: .L1172: ... jmp .L1210 .L1168: .L1169: ... jmp .L1210 instead of .L1210: jmp *%eax .L4: .L5: ... jmp *%eax .L1171: .L1172: ... jmp *%eax .L1168: .L1169: ... jmp *%eax Current gcc trunk, x86, gcc -O3 ef.i -S -m32. Attachment in old Bugzilla entry at http://gcc.gnu.org/bugzilla/attachment.cgi?id=6206&action=view Andrew.
conditional gcov instrumentation
Hi, I have been working on a conditional gcov patch, that calls a function everytime the gcov counter is to be modified, so the function can decide how to increment the counter. The function's prototype is : void __gcov_ctr(gcov_type*) ; where gcov_type would be, for example, long long depending on the architecture. This would be useful for kernel coverage instrumentation (eg) tracking the coverage of only a particular pid, or for implementing atomic counters per cpu, and probably for many others. The libgcov could have a weak default implementation which increments the counter by 1 as usual, and those wanting to add their own implementation could do so. (Suggested by Peter Oberparleiter). I am attaching a patch. Please comment. Regards, Hayawardh gcc-4.4.0-gcov-ctr-ptr.patch Description: Binary data
Re: conditional gcov instrumentation
Reattaching patch if not received.
--- gcc-4.4.0/gcc/tree-profile.c2009-09-03 00:10:48.0 -0400
+++ gcc-4.4.0-gcov-ptr-src/gcc/tree-profile.c 2009-09-03
00:11:01.0 -0400
@@ -183,22 +183,25 @@
static void
tree_gen_edge_profiler (int edgeno, edge e)
{
- tree ref, one;
- gimple stmt1, stmt2, stmt3;
+ tree ref;
+ gimple call;
+ tree decl, gcov_ctr_fn_type, ctr_ptr, gcov_type_ptr;
/* We share one temporary variable declaration per function. This
gets re-set in tree_profiling. */
if (gcov_type_tmp_var == NULL_TREE)
gcov_type_tmp_var = create_tmp_var (gcov_type_node, "PROF_edge_counter");
ref = tree_coverage_counter_ref (GCOV_COUNTER_ARCS, edgeno);
- one = build_int_cst (gcov_type_node, 1);
- stmt1 = gimple_build_assign (gcov_type_tmp_var, ref);
- stmt2 = gimple_build_assign_with_ops (PLUS_EXPR, gcov_type_tmp_var,
- gcov_type_tmp_var, one);
- stmt3 = gimple_build_assign (unshare_expr (ref), gcov_type_tmp_var);
- gsi_insert_on_edge (e, stmt1);
- gsi_insert_on_edge (e, stmt2);
- gsi_insert_on_edge (e, stmt3);
+ gcov_type_ptr = build_pointer_type (get_gcov_type());
+
+ gcov_ctr_fn_type = build_function_type_list(void_type_node,
gcov_type_ptr, NULL_TREE);
+
+ decl = build_decl(FUNCTION_DECL, get_identifier("__gcov_ctr"),
gcov_ctr_fn_type);
+ ctr_ptr = build_addr(ref, current_function_decl);
+
+ call = gimple_build_call (decl, 1, ctr_ptr);
+
+ gsi_insert_on_edge (e, call);
}
/* Emits code to get VALUE to instrument at GSI, and returns the
On Mon, Sep 7, 2009 at 3:51 PM, Hayawardh V wrote:
> Hi,
> I have been working on a conditional gcov patch, that calls a function
> everytime the gcov counter is to be modified, so the function can
> decide how to increment the counter.
> The function's prototype is :
>
> void __gcov_ctr(gcov_type*) ;
>
> where gcov_type would be, for example, long long depending on the
> architecture.
>
> This would be useful for kernel coverage instrumentation (eg) tracking
> the coverage of only a particular pid, or for implementing atomic
> counters per cpu, and probably for many others.
> The libgcov could have a weak default implementation which increments
> the counter by 1 as usual, and those wanting to add their own
> implementation could do so. (Suggested by Peter Oberparleiter).
>
> I am attaching a patch. Please comment.
>
> Regards,
> Hayawardh
>
GNAT mysterious "missing stub for subunit" error.
Hello all, Currently, what you get when you build GNAT on Cygwin is a hybrid port that is mostly based on the MinGW port. This doesn't work well when it does things (such as e.g. creating threads) "behind Cygwin's back" using the Win32 APIs (e.g. CreateThread) rather than by using Cygwin's POSIX interfaces (e.g. pthread_create). I'm trying to build a fully POSIXified Cygwin port by going through the list of LIBGNAT_TARGET_PAIRS for the Windows port, examining all the *-mingw.ad[bs] files listed, and replacing them by references to the existing -linux or -posix versions, or new -cygwin versions in a couple of cases. I had hoped that this would be something I could do with a limited understanding of the Ada build system, but I must have done something wrong. Bootstrap fails during building gnatlib-shared-win32 at the final link stage, with a whole bunch of undefined references to the following functions: > ___gnat_adjust_n_cleanups_for > ___gnat_all_others_value > ___gnat_begin_handler > ___gnat_eid_for > ___gnat_end_handler > ___gnat_is_handled_by_others > ___gnat_others_value As far as I can tell these should come from $objdir/gcc/ada/rts/a-exexpr.adb (which is correctly softlinked to $srcdir/gcc/ada/a-exexpr-gcc.adb), but there is no a-exexpr.o file when the build fails, so make has thought it's not a dependency for some reason, and when I try to build it at the command line, I get the error message mentioned in the subject: > ad...@ubik /gnu/gcc/releases/4.3.4-1/gcc4-4.3.4-1/build/gcc > $ make ada/rts/a-exexpr.o > /gnu/gcc/releases/4.3.4-1/gcc4-4.3.4-1/build/./prev-gcc/xgcc > -B/gnu/gcc/releases /4.3.4-1/gcc4-4.3.4-1/build/./prev-gcc/ > -B/usr/i686-pc-cygwin/bin/ -c -g -O2 -gnatpg -gnata -nostdinc -I- -I. -Iada > -I/gnu/gcc/releases/4.3.4-1/gcc4-4.3.4-1/src/gcc-4.3.4/gcc/ada > ada/rts/a-exexpr.adb -o ada/rts/a-exexpr.o > a-exexpr.adb:42:14: missing stub for subunit > make: *** [ada/rts/a-exexpr.o] Error 1 > > ad...@ubik /gnu/gcc/releases/4.3.4-1/gcc4-4.3.4-1/build/gcc > $ I couldn't find anything about this in the manual, and the comment in sem_ch10.adb where the error is generated is a bit inscrutable to me: > -- If the unit is a subunit whose parent has not been analyzed (which > -- indicates that the main unit is a subunit, either the current one or > -- one of its descendents) then the subunit is compiled as part of the > -- analysis of the parent, which we proceed to do. Basically this gets > -- handled from the top down and we don't want to do anything at this > -- level (i.e. this subunit will be handled on the way down from the > -- parent), so at this level we immediately return. If the subunit > -- ends up not analyzed, it means that the parent did not contain a > -- stub for it, or that there errors were dectected in some ancestor. I don't understand this, but it suggests to me that the error would occur if I had somehow inadvertently altered the position or relations of the a-exexpr module in some kind of dependency graph between the units. I'm not sure how the minor changes I made to the list of target pairs could have done this though, or why the build didn't even try and compile ada/rts/a-exexpr.o before it got to the link stage. I'm working on 4.3 branch to develop this, just because I happened to have a need for it there, but the details of changing LIBGNAT_TARGET_PAIRS should be the same on mainline even after the gcc-interface/ refactoring. (Will of course bring it up to head and submit it once I've got it working... who knows if it'll make stage 1 though.) I've attached a copy of my full working diff, but it's largely extraneous; the critical part is the section that sets the variables for the Cygwin target, which after my changes looks like: -- ifeq ($(strip $(filter-out cygwin% mingw% pe,$(osys))),) [ ... snip irrelevant part ... ] ifneq ($(strip $(filter cygwin%,$(osys))),) W32_TARG=cygwin LIBGNAT_TARGET_PAIRS = \ s-taspri.ads--- Can anyone offer me any advice to help me better understand what must have gone wrong for this error message to appear, which might give me a clue how to fix it? cheers, DaveK --- origsrc/gcc-4.3.4/gcc/ada/Makefile.in 2009-02-28 17:30:26.0 + +++ src/gcc-4.3.4/gcc/ada/Makefile.in 2009-09-08 02:48:54.84375 +0100 @@ -198,6 +198,10 @@ TARGET_ADA_SRCS = # Type of tools build we are doing; default is not compiling tools. TOOLSCASE = +# Which install goal to use. +INSTALL_GNATLIB_MAIN = install-gnatlib +INSTALL_GNATLIB_WIN32 = unused-install-gnatlib + # End of variables for you to override. all: all.indirect @@ -273,7 +277,7 @@ ADA_INCLUDES_FOR_SUBDIR = -I. -I$(fsrcdi $(CC) -c -x assembler $< $(OUTPUT_OPTION) .c.o: - $(CC) -c $(ALL_CFLAGS) $(ADA_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $< \ + $(CC) -c $(ALL_CFLAGS) $(ALL_ADA_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $< \ $(OUTPUT_O
