Re: No .got section in ELF
yunfeng zhang wrote: > The idea I got is about removing .got section in ELF format totally. > > Before we go, let's see the limitation on the idea > 1) It must be deployed on aligned segment model, such as Linux, which cs.start > = ds.start. > 2) Currently, I only know how to do on x86 ELF. > > Here is a typical sample in PIC model (shared library) when library want to > access its global data > ... > // Later code snippet template is used by gcc in almost all shared > function > // to imitate `mov %ip, %ebx'. > call next: > next: > pop %ebx // << A. > ... > movl new_offset(%ebx), %eax // << B. load global variable foo to eax. > ... > .global foo // << C. > OK!, to ld, offsetof(C - A) is const, and to gcc offsetof(B - A) is also > const, so to aligned segment model, new_offset = offset(C - A) - offset(B - > A), > right? Surely not, because in a shared library the address of the data varies. There are in theory many copies of the library, each one with its r/w data in a different place. Andrew.
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
Paul Edwards wrote:
> So, given the scope below, can someone please explain what
> 4.4 changes are affecting me and what I need to do to overcome
> them? Note that I have never had to do the machine changes
> myself - in the past I simply waiting for Dave Pitts to do the
> upgrade to the new version, and then with a working 370 code
> generator I would make all the changes necessary for MVS.
Most of the things seem just minor changes, e.g. "warning" got
another argument, or target macros were replaced by targetm
callbacks.
I can see one significant change: the GCC middle-end now no
longer supports base-16 floating point at all. The old i370
port was the only user of this feature, and some time after
the port was removed, the middle-end support was removed as
well in order to simplify floating-point handling code.
The s390 port uses IEEE float instead of hex float throughout,
so it is not affected by this change.
> + i370-*-mvspdp)
> + xm_defines='POSIX' # 'FATAL_EXIT_CODE=12'
> + xm_file="i370/xm-mvs.h"
> + tm_file="i370/mvspdp.h i370/i370.h"
> + tmake_file="i370/t-mvs i370/t-i370"
> + c_target_objs="i370-c.o"
> + cxx_target_objs="i370-c.o"
> + ;;
> + s390-*-linux*)
> + tm_file="s390/s390.h dbxelf.h elfos.h svr4.h linux.h s390/linux.h"
> + tmake_file="${tmake_file} t-dfprules s390/t-crtstuff s390/t-linux"
> + ;;
The s390 lines should not be added here.
> ! /* +++ c_lex has gone. however, we don't use it for anything important
> anyway */
> ! #define c_lex(a)
Pragma handlers are now apparently supposed to use "pragma_lex" instead,
which is declared in the c-pragma.h header. See e.g. config/sol2-c.c
for examples of pragma handlers.
> /* We're 370 floating point, not IEEE floating point. */
> memset (real_format_for_mode, 0, sizeof real_format_for_mode);
> ! REAL_MODE_FORMAT (SFmode) = &i370_single_format;
> ! REAL_MODE_FORMAT (DFmode) = &i370_double_format;
This is a problem, see above.
> /* We're 370 floating point, not IEEE floating point. */
> memset (real_format_for_mode, 0, sizeof real_format_for_mode);
> ! /*REAL_MODE_FORMAT (SFmode) = &i370_single_format;
> ! REAL_MODE_FORMAT (DFmode) = &i370_double_format;*/
> ! /* +++ this is wrong */
> ! REAL_MODE_FORMAT (SFmode) = &ibm_extended_format;
> ! REAL_MODE_FORMAT (DFmode) = &ibm_extended_format;
ibm_extended_format is certainly wrong here; that's the
64 + 64 "long double" format used on PowerPC.
> for (note = REG_NOTES (insn); note; note = XEXP(note,1))
> {
> +/* +++ what is reg_label? */
> +/*
> if (REG_LABEL == REG_NOTE_KIND(note))
>{
Instead of REG_LABEL notes, the middle-end now generates two different
kinds of notes, REG_LABEL_TARGET and REG_LABEL_OPERAND.
REG_LABEL_TARGET is used in JUMP_INSNs to refer to a potential target
of this jump. REG_LABEL_OPERAND is used in other insns to denote labels
that are used otherwise, e.g. to load the address into a register.
In the context of this code in i370.c, it would appear you're concerned
about the second type of usage here. This means the REG_LABEL should
probably simply be replaced by REG_LABEL_OPERAND.
> ***
> *** 1568,1574
> fprintf (f, "* Function %.*s prologue: stack = %ld, args = %d\n",
> nlen, mvs_function_name,
> l,
> ! current_function_outgoing_args_size);
> #endif
current_function_outgoing_args_size must be replaced by crtl->outgoing_args_size
throughout. There was no change in semantics, just where the value is stored.
> fprintf (f, "* Function %.*s prologue: stack = %ld, args = %d\n",
> nlen, mvs_function_name,
> l,
> ! 0 /*cfun->machine->frame_size*/);
> #endif
The cfun->machine->frame_size stuff does not seem correct here; use
crtl->outgoing_args_size.
> + #if 0
> + This unused (in mvspdp) stuff is now poisoned
> /* Macro to define tables used to set the flags. This is a list in braces
> of pairs in braces, each pair being { "NAME", VALUE }
> where VALUE is the bits to set or minus the bits to clear.
> ***
> *** 99,104
> --- 101,107
> { "pickax", 2, "Experimental i370 PIC"}, \
> { "no-pickax", -2, "Disable experimental i370 PIC"}, \
> { "", TARGET_DEFAULT, 0} }
> + #endif
Command line options are now defined in a .opt file. If you want to
keep those extra options, you should provide a config/i370/i370.opt
file. See any of the other targets for examples.
> + #if 0 /* +++ now poisoned */
> #define PREDICATE_CODES \
> {"r_or_s_operand", { REG, SUBREG, MEM }}, \
> {"s_operand", { MEM }},
> + #endif
Predicates must now be defined in a predicates.md file. Again, see
other targets for examples.
> ! #if 0 /*def TARGET_PDPMAC*/
> ! +++ this variable is now poisoned - check structs still get returned
> ! properly
> #define STRUCT_VALUE_REGNUM 0
> ! #elif
AIX C++ failures
A change on November 23 is causing every C++ testcase to fail on AIX because of _ZNSsD1Ev not being exported. c++filt reports the symbol corresponds to std::basic_string, std::allocator >::~basic_string [in-charge]() David
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
I can see one significant change: the GCC middle-end now no longer supports base-16 floating point at all. The old i370 port was the only user of this feature, and some time after the port was removed, the middle-end support was removed as well in order to simplify floating-point handling code. Hmmm. Well I don't know anything about floating point. Thanks very much for all your comments. I will see what difference that makes. Note that I'd expect that with the above obvious issues fixed, you may well run into additional problems in moving the port forward ... At some point, it will be necessary to be able to debug the back-end and resolve problems. Ok, well what I did in the original (3.2) port was to ANSIfy it and then use different debuggers (Borland, Watcom) on my Windows box. I'll see what I can come up with this time. Overall, I still think that adding HLASM support to the s390 back-end would probably be a simpler task ... Well in that case, maybe now is the time to be doing exactly that. I could make 3.4.6 the last of the i370 ports. Can you tell me what is required to convert s390, which has a very alien assembler output, into hlasm? And that brings me to another question. The i370 hlasm port uses tabs in every instruction to separate the instruction and operand. This is not valid in hlasm. In order to get around this, I ended up doing a #define for putc etc to channel everything through my own routine which converted those tabs into an appropriate number of spaces. I suspect there's a neater way to do things, but I never stumbled across that in my travels. Thanks. Paul.
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
H.J. Lu wrote: > On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley wrote: >> H.J. Lu wrote: >>> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote: Steven Rostedt wrote: > Ingo, Thomas and Linus, > > I know Thomas did a patch to force the -mtune=generic, but just in case > gcc decides to do something crazy again, this patch will catch it. > > Should we try to get this in now? I'm sure this makes sense, but a gcc test case would be even better. If this can be detected in the gcc test suite it'll be found and fixed long before y'all in kernel land get to see it. That's the only way to guarantee this never bothers you again. H.J., who wrote the code in question, is hopefully looking at why this odd code is being generated. Once he's done I can put a suitable test case in the gcc test suite. >>> See: >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109#c7 >> I saw that, but does it mean you're going to investigate? There is >> no obvious reason why -mtune=generic should affect code generation >> in this way, but it does. > > Why not, there is > > static const unsigned int x86_accumulate_outgoing_args > = m_AMD_MULTIPLE | m_ATOM | m_PENT4 | m_NOCONA | m_PPRO | m_CORE2 > | m_GENERIC; > > -mtune=generic turns on -maccumulate-outgoing-args. Alright, so let's at least try to give the kernel people the information that they need. What you're saying is, to avoid this: 05f0 : 5f0: 57 push %edi 5f1: 8d 7c 24 08 lea0x8(%esp),%edi 5f5: 83 e4 f0and$0xfff0,%esp 5f8: ff 77 fcpushl -0x4(%edi) 5fb: 55 push %ebp 5fc: 89 e5 mov%esp,%ebp you should compile your code with -maccumulate-outgoing-args, and there's no need to use -mtune=generic. Is that right? Andrew.
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
On Tue, 24 Nov 2009, Andrew Haley wrote: > H.J. Lu wrote: > > On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley wrote: > >> H.J. Lu wrote: > >>> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote: > Steven Rostedt wrote: > > Ingo, Thomas and Linus, > > > > I know Thomas did a patch to force the -mtune=generic, but just in case > > gcc decides to do something crazy again, this patch will catch it. > > > > Should we try to get this in now? > I'm sure this makes sense, but a gcc test case would be even better. > If this can be detected in the gcc test suite it'll be found and > fixed long before y'all in kernel land get to see it. That's the > only way to guarantee this never bothers you again. > > H.J., who wrote the code in question, is hopefully looking at why > this odd code is being generated. Once he's done I can put a > suitable test case in the gcc test suite. > > >>> See: > >>> > >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109#c7 > >> I saw that, but does it mean you're going to investigate? There is > >> no obvious reason why -mtune=generic should affect code generation > >> in this way, but it does. > > > > Why not, there is > > > > static const unsigned int x86_accumulate_outgoing_args > > = m_AMD_MULTIPLE | m_ATOM | m_PENT4 | m_NOCONA | m_PPRO | m_CORE2 > > | m_GENERIC; > > > > -mtune=generic turns on -maccumulate-outgoing-args. > > Alright, so let's at least try to give the kernel people the information > that they need. > > What you're saying is, to avoid this: > > 05f0 : > 5f0: 57 push %edi > 5f1: 8d 7c 24 08 lea0x8(%esp),%edi > 5f5: 83 e4 f0and$0xfff0,%esp > 5f8: ff 77 fcpushl -0x4(%edi) > 5fb: 55 push %ebp > 5fc: 89 e5 mov%esp,%ebp > > you should compile your code with -maccumulate-outgoing-args, and there's > no need to use -mtune=generic. Is that right? Seems to work. What other side effects has that ? Thanks, tglx
Re: Possible endless loop in lto-wrapper
> Hi Rafael, > > I'm sorry I cannot try the patch until next weekend. > However, from a first look, it should work but I wonder: if the first > maybe_unlink_file fails the others are never reached, leaving some > temporary files in place. Is this ok? > Yes, I talked with Diego and he thinks that this is an unusual case and it is better to just give up when the first unlink fails. I have committed the patch, let me know if you see any issues. > Thank you, > Leandro > -- > Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP > autenticato? GRATIS solo con Email.it: http://www.email.it/f > Cheers, -- Rafael Ávila de Espíndola
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote: > > you should compile your code with -maccumulate-outgoing-args, and there's > > no need to use -mtune=generic. Is that right? > > Seems to work. What other side effects has that ? Faster code, significant increase in code size though. Note that on many architectures it is the only supported model. Jakub
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
Jakub Jelinek wrote: > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote: >>> you should compile your code with -maccumulate-outgoing-args, and there's >>> no need to use -mtune=generic. Is that right? >> Seems to work. What other side effects has that ? > > Faster code, significant increase in code size though. Does it affect code size when we don't have to realign the stack pointer? Andrew.
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
On Tue, Nov 24, 2009 at 03:32:20PM +, Andrew Haley wrote: > Jakub Jelinek wrote: > > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote: > >>> you should compile your code with -maccumulate-outgoing-args, and there's > >>> no need to use -mtune=generic. Is that right? > >> Seems to work. What other side effects has that ? > > > > Faster code, significant increase in code size though. > > Does it affect code size when we don't have to realign the stack pointer? Yes, a lot. The difference is that -maccumulate-outgoing-args allocates space for arguments of the callee with most arguments in the prologue, using subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc. and the stack pointer doesn't usually change within the function (except for alloca/VLAs). With -mno-accumulate-outgoing-args args are pushed using push instructions and stack pointer is constantly changing. Jakub
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
Jakub Jelinek wrote: > On Tue, Nov 24, 2009 at 03:32:20PM +, Andrew Haley wrote: >> Jakub Jelinek wrote: >>> On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote: > you should compile your code with -maccumulate-outgoing-args, and there's > no need to use -mtune=generic. Is that right? Seems to work. What other side effects has that ? >>> Faster code, significant increase in code size though. >> Does it affect code size when we don't have to realign the stack pointer? > > Yes, a lot. The difference is that -maccumulate-outgoing-args allocates > space for arguments of the callee with most arguments in the prologue, using > subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc. > and the stack pointer doesn't usually change within the function (except for > alloca/VLAs). > With -mno-accumulate-outgoing-args args are pushed using push instructions > and stack pointer is constantly changing. Alright. So, it is possible in theory for gcc to generate code that only uses -maccumulate-outgoing-args when it needs to realign SP. And, therefore, we could have a nice option for the kernel: one with (mostly) good code density and never generates the bizarre code sequence in the prologue. Andrew.
Re: On strategies for function call instrumentation
Derrick Coetzee wrote:
> 1. We have a C/C++ source-to-source translation framework. We could
> translate each function call "f(a,b,c)" to something like "({ _asm {
> ... }; typeof(f(a,b,c)) result = f(a,b,c); _asm { ... }; result; })"
> 2. We could modify the code generation of gcc in a private fork.
I think you will need to do (2). The source-to-source approach probably
isn't robust enough for what you need to do. You *might* be able to do
it if you pull all calls out of the arguments, but then you have to do
things like:
f(g()) -> temp = g(), f(temp)
before you put in your asm, and if you're in C++ land, you're now
doomed, since creating named temporaries can change the semantics of
programs.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Re: On strategies for function call instrumentation
Mark Mitchell wrote:
Derrick Coetzee wrote:
1. We have a C/C++ source-to-source translation framework. We could
translate each function call "f(a,b,c)" to something like "({ _asm {
... }; typeof(f(a,b,c)) result = f(a,b,c); _asm { ... }; result; })"
2. We could modify the code generation of gcc in a private fork.
With the next GCC, it can be done inside a plugin. I tend to believe this could be a good use case for a plugin, and the
plugin infrastructure is probably mature for that. You probably could do that in GIMPLE/SSA without adding a new port.
Regards.
--
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: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
On 11/24/2009 07:46 AM, Andrew Haley wrote: >> >> Yes, a lot. The difference is that -maccumulate-outgoing-args allocates >> space for arguments of the callee with most arguments in the prologue, using >> subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc. >> and the stack pointer doesn't usually change within the function (except for >> alloca/VLAs). >> With -mno-accumulate-outgoing-args args are pushed using push instructions >> and stack pointer is constantly changing. > > Alright. So, it is possible in theory for gcc to generate code that > only uses -maccumulate-outgoing-args when it needs to realign SP. > And, therefore, we could have a nice option for the kernel: one with > (mostly) good code density and never generates the bizarre code > sequence in the prologue. > If we're changing gcc anyway, then let's add the option of intercepting the function at the point where the machine state is well-defined by ABI, which is before the function stack frame is set up. -maccumulate-outgoing-args sounds like it would be painful on x86 (not using its cheap push/pop instructions), but I guess since it's only when tracing it's less of an issue. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Re: On strategies for function call instrumentation
Hi!
I totally agree with Basille. Actually pretty similar thing was
implemented by Liang Peng (ICT) as GCC GSoC'09 project -
http://ctuning.org/wiki/index.php/CTools:ICI:Projects:GSOC09:Function_cloning_and_program_instrumentation
So, probably you should take a look at the code in the
instrumentation part of this project.
On Tue, Nov 24, 2009 at 5:38 PM, Basile STARYNKEVITCH
wrote:
> Mark Mitchell wrote:
>>
>> Derrick Coetzee wrote:
>>
>>> 1. We have a C/C++ source-to-source translation framework. We could
>>> translate each function call "f(a,b,c)" to something like "({ _asm {
>>> ... }; typeof(f(a,b,c)) result = f(a,b,c); _asm { ... }; result; })"
>>> 2. We could modify the code generation of gcc in a private fork.
>
>
> With the next GCC, it can be done inside a plugin. I tend to believe this
> could be a good use case for a plugin, and the plugin infrastructure is
> probably mature for that. You probably could do that in GIMPLE/SSA without
> adding a new port.
>
> Regards.
>
>
>
> --
> 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: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
Andrew Haley writes: >Alright. So, it is possible in theory for gcc to generate code that >only uses -maccumulate-outgoing-args when it needs to realign SP. >And, therefore, we could have a nice option for the kernel: one with >(mostly) good code density and never generates the bizarre code >sequence in the prologue. The best option would be for the Linux people to fix the underlying problem in their kernel sources. If the code no longer requested that certain automatic variables be aligned, then not only would this bizarre code sequence not be emitted, the unnecessary stack alignment would disapear as well. The kernel would then be free to choose to use whatever code generation options it felt was appropriate. Ross Ridge
Re: No .got section in ELF
On 11/23/2009 05:58 PM, yunfeng zhang wrote: next: pop %ebx //<< A. ... movl new_offset(%ebx), %eax //<< B. load global variable foo to eax. ... .global foo //<< C. OK!, to ld, offsetof(C - A) is const... Your premise is wrong right there. C-A is *not* a constant. That's why we used a load from memory. If it had been a constant then B would have been: leal f...@gotoff(%ebx), %eax r~
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
Ross Ridge wrote: > Andrew Haley writes: >> Alright. So, it is possible in theory for gcc to generate code that >> only uses -maccumulate-outgoing-args when it needs to realign SP. >> And, therefore, we could have a nice option for the kernel: one with >> (mostly) good code density and never generates the bizarre code >> sequence in the prologue. > > The best option would be for the Linux people to fix the underlying > problem in their kernel sources. If the code no longer requested > that certain automatic variables be aligned, then not only would this > bizarre code sequence not be emitted, the unnecessary stack alignment > would disapear as well. The kernel would then be free to choose to use > whatever code generation options it felt was appropriate. Well, yeah. But, for my sins, I tend to assume that the Linux kernel people have some kind of reason for the things they do. Working with them over the years has helped us improve gcc, even though at times things get to be a little ill-tempered. Andrew.
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
H. Peter Anvin wrote: > On 11/24/2009 07:46 AM, Andrew Haley wrote: >>> Yes, a lot. The difference is that -maccumulate-outgoing-args allocates >>> space for arguments of the callee with most arguments in the prologue, using >>> subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc. >>> and the stack pointer doesn't usually change within the function (except for >>> alloca/VLAs). >>> With -mno-accumulate-outgoing-args args are pushed using push instructions >>> and stack pointer is constantly changing. >> Alright. So, it is possible in theory for gcc to generate code that >> only uses -maccumulate-outgoing-args when it needs to realign SP. >> And, therefore, we could have a nice option for the kernel: one with >> (mostly) good code density and never generates the bizarre code >> sequence in the prologue. > > If we're changing gcc anyway, then let's add the option of intercepting > the function at the point where the machine state is well-defined by > ABI, which is before the function stack frame is set up. Hmm. On the x86 I suppose we could just inject a naked call instruction, but not all aeches allow us to call anything before we've saved the return address. Or are you talking x86 only? Andrew.
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
On Tue, 2009-11-24 at 17:12 +, Andrew Haley wrote: > H. Peter Anvin wrote: > > If we're changing gcc anyway, then let's add the option of intercepting > > the function at the point where the machine state is well-defined by > > ABI, which is before the function stack frame is set up. > > Hmm. On the x86 I suppose we could just inject a naked call instruction, > but not all aeches allow us to call anything before we've saved the return > address. Or are you talking x86 only? Earlier in the GCC BUG thread we talked about this. Adding a __fentry__ call at the beginning of the function. This could be done for other archs as well, but yes, the return address must be stored. For x86 it is the easiest because it automatically stores the return address on the stack (Andi already has a working patch I believe). For other archs, Linus showed some examples: http://lkml.org/lkml/2009/11/19/349 -- Steve
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
"Kaveh R. Ghazi" writes: > Agreed. I guess my remaining questions are for AIX and mipsisa64-elf. > > Can someone please confirm that mipsisa64-elf is a cross-compile-only target > and therefore not relevant for host-based MPC portability testing? Yes, that's right. I'm sure it's technically possible to compile GCC with a mipsisa64-elf compiler, but it would be hard, and it isn't a well-defined operation. I don't think you could do it with the usual libgloss runtime environment; you'd need to use a "real" OS. Richard
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
On 11/24/2009 09:12 AM, Andrew Haley wrote: >> >> If we're changing gcc anyway, then let's add the option of intercepting >> the function at the point where the machine state is well-defined by >> ABI, which is before the function stack frame is set up. > > Hmm. On the x86 I suppose we could just inject a naked call instruction, > but not all aeches allow us to call anything before we've saved the return > address. Or are you talking x86 only? > For x86, we should use a naked call. For architectures where that is not possible, we should use a minimal sequence such that the ABI state at the invocation point is 100% derivable. On MIPS, for example, we could use a sequence such as: mov at, ra jal __fentry__ It would be up to __fentry__ to save the value in at and to restore it back into ra before resuming, meaning that __fentry__ has a nonstandard calling convention. -hpa
Re: copyright assignment
Hi Paolo, Just saw your email. Do you mind to send the forms to Yuanjie (huangyuan...@ict.ac.cn) and Liang (pengli...@ict.ac.cn) so that they could add their GSoC'09 developments to the mainline with the help of Joern, please?! I send an offline email to David and Sebastian but if you already know where are the forms and how to use them, that would be great and can save us time! Thanks a lot in advance!!! Grigori >On 11/22/2009 10:48 AM, John Nowak wrote: > >>Hello. I would like to get the necessary forms for copyright assignment >>to GCC for future work on GNAT. I was told this is the way to kick off >>the process. > > >I sent them offlist. > >Paolo
exact role[s] of the plugin directory?
Hello All,
http://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins mention a plugin
directory which can be queried with
gcc-trunk -print-file-name=plugin
Notice that we are calling that plugin, not plugin-header! In my opinion, this
is significant.
on my system, after installation of gcc-trunk, I'm getting
/usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/plugin
and currently that directory contains only the include/ file (see PLUGIN_HEADERS in gcc/Makefile.in) needed to compile
plugins. I call that directory $plugin here.
So my feeling is that today, the plugin directory is exclusively for the header
files needed for building plugins.
If this is really the case, we could rename it, and query it with
gcc-trunk -print-file-name=plugin-headers
and then it should return a directory containing *.h files needed to compile
plugins.
However, I see possible other roles of that plugin/ directory, which justify putting an include/ inside, as we are doing
now!
First, we could define a directory for plugin shared objects. An obvious
candidate could be:
$plugin/libexec
[I mean
/usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/plugin/libexec on
my system]
and we could decide to put plugin.so files there. I find that attractive, because for commonly used plugins, we could
install them there, and hack our cc1 (I really mean gcc/plugin.c) so that
-fplugin=NAME
means really -fplugin=$plugin/libexec/NAME.so ; the major interest of such a feature is for users: they would type a
much shorter gcc invocation when using system-installed plugins (and we could even have several directories for them,
for instance one under /usr & another under /usr/local). Of course the -fplugin=/full/path/to/plugin/name.so option
should still work.
It seems that people have mixed feelings on that idea. I might have perhaps proposed some patch (which did not interest
anyone, and was buggy) a few months ago. I could try to make a new patch for that. Apparently, the major issue is how to
get the gcc prefix (ie -B in gcc program argument parlance) from inside a plugin.
Some plugins might need or be happy with some "system" or "configuration" files (this is definitely the case for MELT;
it needs several files to work.). We could adopt the convention that a plugin foo.so can access $plugin/foo/ and put its
files there. We then need a simple (and documented!) way to retrieve the $plugin from inside the source code of a
plugin.c [maybe it is thru update_path() or some other function]. I would be very happy with a
plugin_subsystem_directory() function in gcc-plugin.h which would retrieve that $plugin/
These discussions are also related to the *.spec file, which I don't understand well (in particular, how to access its
information from inside a plugin?).
Of course remains the issue if all those small improvements fits into the
current stage3 of trunk.
I would appreciate hearing about other peaple opinions on that matter. I am sure to not be alone interested in that. And
it is in fact related to packaging in Linux distributions (because it is related to defining & implementing conventions
relevant in such distributions).
So what do you think the `gcc-trunk -print-file-name=plugin` directory (with
backquotes for shell) should be used for?
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} ***
gcc-4.4-20091124 is now available
Snapshot gcc-4.4-20091124 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091124/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 154520 You'll find: gcc-4.4-20091124.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20091124.tar.bz2 C front end and core compiler gcc-ada-4.4-20091124.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20091124.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20091124.tar.bz2 C++ front end and runtime gcc-java-4.4-20091124.tar.bz2 Java front end and runtime gcc-objc-4.4-20091124.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20091124.tar.bz2The GCC testsuite Diffs from 4.4-20091117 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: On strategies for function call instrumentation
Hi Derrick,
As Yuri pointed out we needed some similar instrumentation
for our function cloning work. It may not be exactly
what you need but could be useful.
By the way, it seems that you are interested to use GCC as a research
platform. In this case, sorry for a small advertisement, but I would
like to draw your attention to the GROW'10 workshop which
brings together GCC people using this compiler for research
purposes. The deadline just passed but you may still be interested
to look at the past ones or participate in the future ones. It is
co-located with the HiPEAC conference and the HiPEAC network
of universities is using GCC as a common research platforms.
We have been developing Interactive Compilation Interface to simplify
the use of GCC for researchers and make research plugins more portable
during compiler evolution. It is a collaborative effort and after GSoC'09
we are trying to move some of the functionality to the mainline.
You are warmly welcome to participate in those activities or you can
follow recent discussions at this mailing list:
http://groups.google.com/group/ctuning-discussions
Hope it will be of any use,
Grigori
>* From: Derrick Coetzee
>* To: gcc at gcc dot gnu dot org
>* Date: Mon, 23 Nov 2009 19:44:10 -0800
>* Subject: On strategies for function call instrumentation
>
> Hi, I'm Derrick Coetzee and I'm a grad student working with Daniel
> Wilkerson et al on the Hard Object project at UC Berkeley (see
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-97.html). To
> minimize implementation effort, we'd like to use gcc as the compiler
> for our platform. The main trick is, to implement our custom stack
> management, we need to inject a custom instruction before each
> function call begins pushing its arguments, and insert a different
> instruction right after each function call. We considered a couple
> different ways to do this:
>
> 1. We have a C/C++ source-to-source translation framework. We could
> translate each function call "f(a,b,c)" to something like "({ _asm {
>... }; typeof(f(a,b,c)) result = f(a,b,c); _asm { ... }; result; })"
> 2. We could modify the code generation of gcc in a private fork.
>
> Our main concern is that we need to be sure the instructions will be
> executed at the right time, right before it starts pushing arguments
> for the function and right after it returns, even in complex contexts
> like nested function calls (f(g(a,b),c)). We're not sure how much gcc
> will reorder these type of sequences, or what optimizations we might
> be neglecting to consider. We're also not sure if we might be
> overlooking superior approaches to the problem. Any advice is
> appreciated.
>
> --
> Derrick Coetzee
> University of California, Berkeley
Problems compiling Mozilla with GCC 4.5
I've recently come across a couple of issues trying to compile Firefox trunk with 4.5 (I have a very simple plugin that I need to run on mozilla-central). I've posted two bugs here http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42139 and here http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42171 I''m not particularly concerned about the first, which can be bypassed by disabling optimization on the problem file, but the second, a link error, is a show stopper. Can anyone think of a way to sidestep the problem? I'm not even sure I've addressed the bug to the right place, but it would seem that if the same version of ld chokes during a 4.5 compile, but does fine with an earlier version of gcc, then it's really not a binutils issue. I'm a bit out of my element here though so any suggestions would be welcome. Ehren
