Adding statement to an already defined function
Hello, I am working on modifying GCC and I would like to ask you one question. I am trying figure out a way to add an external statement to already generated function. Is that possible? For example, let's say that if I want to check is function with name "DoSomething" already generated/parsed (bottom line, does it exist). Can I do that somehow? And if I can, is there a way to add new statement (e.g call of some function) into to body of "DoSomething"? This situation could for example happen when the "DoSomething" is in A.c file and the compiler is currently parsing B.c and it needs to look has DoSomething been already processed in files before (in this case A.c file). Is that possible somehow? Thank you in advance! Best regards, Nikola
Re: optimizing the pushing of constant parameters to functions
Hi,
On Sat, 27 Feb 2010, Joern Rennecke wrote:
> > >I wonder whether there is a plan to optimize code such as this:
> > >
> > >extern int (const int x);
> > >void () {
> > > (444);
> > > (444);
> > > }
> > >
> > >by not pushing the constant argument twice. It seems safe to do so,
> > >because the function called will not modify its argument on the stack.
> >
> >I can think of one case where this is not true. Sibcalling where
> >arguments are the same size and the order are different or just
> >different in general.
>
> In that case, the sibcall optimization really actually goes against the
> function declaration. It's basically an ABI decision if we consider that
> valid.
Most (all?) ABI(s) make the outgoing parameter passing area on the stack
belong to the called function (there as incoming paramater area), with no
differentiation between const or non-const arguments. Hence the callee
may do whatever it likes with it, including reading out the passed
parameter into somewhere else (register) and reuse the stack space for
some temporary calculations. The 'const' concept of language doesn't
change this.
So, no, we can't do the transformation the OP suggested.
> If it's not valid for a target, then the push optimization should
> be safe; this might be indicated by a target hook.
... or that. But it could be set only for very few ABIs (are there any?).
Ciao,
Michael.
Re: Defining a libobjc.so.2 ABI
Andreas Schwab writes: > Rainer Orth writes: > >> * Several global variables are obviously implementation details, and >> thus not part of the ABI (e.g. idxsize, narrays, nbuckets, nindices). > > They should probably be renamed to be namespace-clean. Right, probably something like __objc_. This way, even targets without symbol versioning can benefit. Any other comments on the proposed ABI? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: why multiple libiberty directories
> But I've previously noted that target libiberty seems completely useless; It's a target library, like newlib, libz, libstdc++, or anything else. How do you know there are no target applications that want to link against it?
Defining a libffi.so.4 ABI
I've posted the message below to the gcc@gcc.gnu.org, but got no
response other than pointing out to me that posting to libffi-discuss
might be helpful.
So here we go. Please keep me on the Cc: since I'm not subscribed to
libffi-discuss.
Rainer
--- Begin Message ---
After I'm done with supporting Sun symbol versioning in the currently
versioned GCC runtime libraries, I've started investigating versioning
the remaining unversioned ones.
One of them is libffi.so.4. To start, I've looked at the global symbols
in the library with
$ nm -Pgn libffi.so.4 | awk '$2 !~ /U/ {print $1}'
on i386-pc-solaris2.11. Here's what I found:
__bss_start created by gld
_edata dto.
_enddto.
_etext dto.
_fini dto.
_init dto.
_lib_versionimported from values-*.o
ffi_assert ffi_common.h [FFI_DEBUG]
ffi_calllibffi.texi
ffi_call_SYSV implementation detail
ffi_closure_alloc libffi.texi
ffi_closure_freelibffi.texi
ffi_java_ptrarray_to_rawffi.h.in
ffi_java_raw_size ffi.h.in
ffi_java_raw_to_ptrarrayffi.h.in
ffi_prep_args implementation detail
ffi_prep_ciflibffi.texi
ffi_prep_cif_machdepffi_common.h
ffi_prep_closurelibffi.texi (deprecated)
ffi_prep_closure_loclibffi.texi
ffi_prep_raw_closureffi.h.in
ffi_prep_raw_closure_loclibffi.texi
ffi_ptrarray_to_raw ffi.h.in
ffi_raw_callffi.h.in
ffi_raw_sizeffi.h.in
ffi_raw_to_ptrarray ffi.h.in
ffi_stop_here ffi_common.h [FFI_DEBUG], unused
ffi_type_double libffi.texi
ffi_type_float libffi.texi
ffi_type_longdouble libffi.texi
ffi_type_pointerlibffi.texi
ffi_type_sint16 libffi.texi
ffi_type_sint32 libffi.texi
ffi_type_sint64 libffi.texi
ffi_type_sint8 libffi.texi
ffi_type_test ffi_common.h [FFI_DEBUG]
ffi_type_uint16 libffi.texi
ffi_type_uint32 libffi.texi
ffi_type_uint64 libffi.texi
ffi_type_uint8 libffi.texi
ffi_type_void libffi.texi
So obviosly the public ABI consists solely of symbols starting with
ffi_ (quel surprise :-).
* Those tagged libffi.texi are part of the documented API and thus are
part of the ABI, too.
* Those tagged with ffi.h.in are also part of the public API, though not
yet properly documented ;-(
* Some symbols are declared in ffi_common.h inside FFI_DEBUG blocks, but
are obviously internal and don't belong to the ABI.
* ffi_call_SYSV, ffi_prep_args, ffi_prep_cif_machdep are implementation
details and shouldn't be exported.
With this in place, I've provided an initial version map below, grouped
into Base API, Types, Closure API, Raw API, and Java raw API. There are
two open issues:
* ffi_prep_closure (and thus ffi_prep_raw_closure and
ffi_prep_java_raw_closure) are documented as deprecated. They
shouldn't probably be part of the FFI_4.0 version, but rather moved
into a (say) FFI_3.0 version which FFI_4.0 inherits from. Ok?
* There's a problem with the Java Raw API functions: src/java_raw_api.c
implements them (ffi_java_raw_call and ffi_prep_java_raw_closure*)
only if !FFI_NATIVE_RAW_API, which is false on x86. Thus we are left
without an implementation. Is this supposed to be so?
With the version map below in place, I could rebuild libffi.so.4 and
rerun the testsuite without failures, so it seems like a reasonable
start.
Comments?
If this is deemed acceptable, I'll probably go ahead and implement
proper support for this in libffi, but only after providing a common
symbol versioning infrastructure in GCC instead of again duplicating
what we already have in several runtime libraries.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
# FIXME:
# * How to handle deprecated functions (at least ffi_prep_closure,
# probably also ffi_prep_raw_closure and ffi_prep_java_raw_closure?
# * How to name the version anyway? (cf. libgcc_s.so.1, others)
# * Determine status of missing functions.
# * Perhaps group symbols instead of sorting alphabetically?
# cf. libffi.texi: base API, types, closure API, raw API, Java raw API
FFI_4.0 {
global:
# Base API
ffi_call;
ffi_prep_cif;
# Types
ffi_type_double;
ffi_type_float;
ffi_type_longdouble;
ffi_type_pointer;
ffi_type_sint16;
ffi_type_sint32;
ffi_type_sint64;
ffi_type_sint8;
ffi_type_uint16;
ffi_type_uint32;
ffi_type_uint64;
ffi_type_
Re: why multiple libiberty directories
On 03/01/2010 09:48 PM, DJ Delorie wrote: But I've previously noted that target libiberty seems completely useless; It's a target library, like newlib, libz, libstdc++, or anything else. How do you know there are no target applications that want to link against it? Is it still used outside the "Cygnus tree"? Paolo
Re: why multiple libiberty directories
> Is it still used outside the "Cygnus tree"? How should I know? I don't know what users of free software do with it... It's a target library. Anyone writing code for any target might use it.
Re: why multiple libiberty directories
On Mon, 1 Mar 2010, DJ Delorie wrote: > > But I've previously noted that target libiberty seems completely useless; > > It's a target library, like newlib, libz, libstdc++, or anything else. > How do you know there are no target applications that want to link > against it? GCC target libraries provide either functions to which GCC may implicitly generate calls, or the customary runtime for languages and language extensions implemented by GCC. libiberty provides a random selection of other functions used in various host-side tools; as such, it should not be installed for the target by GCC. (In my view it should not be installed for the host either; from GCC's perspective it's just an internal piece of the implementation. The associated headers are only installed if anywhere in the plugin include directory, which would indicate that if libiberty is installed anywhere it should also be a clearly version-specific plugin-specific directory. But I think we concluded that it would be best to link the whole of libiberty.a into the cc1 etc. binaries to provide a stable interface for plugins, which indicates no need to install libiberty.a for them.) GCC target libraries use GPL+exception; newlib uses various permissive licenses. libiberty has a mixture of GPL and LGPL, which are generally considered unsuitable for GCC target libraries and for newlib, plus some files with exceptions. The question is not whether some target applications want to use it - it is whether it is a facility that GCC should be providing to target (or host) applications, and I think it is not. An application wanting to use it can always build its own copy of libiberty, just like GCC does; building libiberty at application build time is what GCC, Binutils, GDB etc. do and I think is what other applications should do (subject to e.g. --enable-install-libbfd also causing Binutils to install host libiberty as a dependency of host libbfd). (I would also note that libiberty is rather specialized to the particular toolchain uses it has on the host side, and random pieces of software might be better off using gnulib which provides a larger and more general-purpose collection of miscellaneous utility and portability functions.) -- Joseph S. Myers jos...@codesourcery.com
