Re: Wiki slowness
On Fri, Apr 13, 2012 at 4:04 AM, Richard Guenther wrote: > Heh - that's what I do for years, too ;) I suppose sth crashes on the server > side when you save the page, so the communication is broken mid-way. I haven't looked at this in ages, but for GDB we had a problem with mail notifications being synchronous. The more people were signed up to be notified about changes to the wiki, the slower saves finished. Woe unto you if some of them had down mail servers. -- Thanks, Daniel
Re: [ARM] EABI and the default to short enums
Sorry for being late to the party. On Wed, Feb 15, 2012 at 9:55 AM, Ian Lance Taylor wrote: > Ouch, I did not know that the EABI left this open. That seems like a > bug, because it prevents code from being interoperable. This is > precisely the kind of thing an ABI should address. Does anybody know > why they did this? It's a matter of platform variants. There are a sufficient number of ARM use cases where the extra bytes matter (or else, there are a sufficient number of ARM vendors / customers who feel that it matters). But there's also cases like Linux where the advantages of int-sized enums outweigh the space cost. So the platform ABI supplement is supposed to decide. I believe that the Linux variant has other deviations from base than just this. The one I remember in particular is TLS models but there may be others. Please check the full range of differences before you decide which would be a better base for RTEMS. -- Thanks, Daniel
Re: ARM Linux EABI: unwinding through a segfault handler
On Mon, Aug 29, 2011 at 11:18 AM, Ken Werner wrote: > On 08/25/2011 02:26 PM, Andrew Haley wrote: >> >> Throwing an exception through a segfault handler doesn't always work >> on ARM: the attached example fails on current gcc trunk. >> >> panda-9:~ $ g++ segv.cc -fnon-call-exceptions -g >> panda-9:~ $ ./a.out >> terminate called after throwing an instance of 'FoobarException*' >> Aborted >> >> The bug is that _Unwind_GetIPInfo doesn't correctly set ip_before_insn. >> Instead, it always sets it to zero; it should be set to 1 if this >> is a frame created by a signal handler: >> >> >> #define _Unwind_GetIPInfo(context, ip_before_insn) \ >> (*ip_before_insn = 0, _Unwind_GetGR (context, 15)& ~(_Unwind_Word)1) >> >> >> Fixing this on ARM is hard because signal frames aren't specially >> marked as they are on systems that use DWARF unwinder data. I have >> a patch that works on systems where the signal restorer is exactly >> >> mov r7, $SYS_rt_sigreturn >> swi 0x0 >> >> It works as a proof of concept, but it's fugly. >> >> So, suggestions welcome. Is there a nice way to detect a signal frame? > > Libunwind also reads the IP to detect signal frames on ARM Linux: > http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=blob;f=src/arm/Gis_signal_frame.c;hb=HEAD > > I'd also be interested if there are better approaches to detect them. :) There aren't better ways - this is pretty much the standard for on-stack signal frames :-) I thought we used a handler in GLIBC that was properly annotated, nowadays, but I might be mistaken. -- Thanks, Daniel
Re: gcc-4.3-20110515 is now available
On Sun, May 15, 2011 at 07:50:34PM -, gccad...@gcc.gnu.org wrote: > Snapshot gcc-4.3-20110515 is now available on > ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110515/ > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. If we're building 4.7 snapshots, do we still need 4.3? -- Daniel Jacobowitz
Re: RFC: Add zlib source to src CVS resposity
On Mon, Nov 01, 2010 at 05:13:44PM +, Nick Clifton wrote: > At the moment I feel that the pros outweigh the cons. What do other > people think ? I was asked not to include expat in GDB, which was a similar situation. I don't remember if this was an FSF issue; I know that the FSF, in general, dislikes duplicated source code in packages, but I don't know if they care when the duplicated bits are non-GNU. There were definitely GDB developers that disliked bundling expat, so perhaps you can find the reasons in the archives. -- Daniel Jacobowitz CodeSourcery
Re: rationale for eliding modifications to string constants
On Tue, Sep 14, 2010 at 11:50:11PM +0530, Uday P. Khedker wrote: > The point is: in your program is is only a pointer. When you pass s > as a parameter to printf, the compiler assumes that only s is being > used so the (effective) assignment > >*s = 'H' > > is deleted as dead code when optimization is enabled. No, this is incorrect. The issue must be specific to modification of read-only data. -- Daniel Jacobowitz CodeSourcery
Re: -Wdouble-promotion & noise
On Tue, Sep 14, 2010 at 04:30:09PM +0200, tbp wrote:
> Hello,
> I could really use -Wdouble-promotion but, atm, it appears quite impractical,
> $ cat double.cc
> #include
> void foo(...);
> int main() {
> float f = 1;
> foo(f);
> printf("%f", f);
> }
> $ /usr/local/gcc-4.6-20100913/bin/g++ -Wdouble-promotion double.cc
> double.cc: In function 'int main()':
> double.cc:5:7: warning: implicit conversion from 'float' to 'double'
> when passing argument to function [-Wdouble-promotion]
> double.cc:6:16: warning: implicit conversion from 'float' to 'double'
> when passing argument to function [-Wdouble-promotion]
>
> ... and the interesting bits are lost in the noise. I can't think of a
> workaround.
> So i have to ask: Is that how it's meant to be, or simply a temporary
> shortcoming? Have i missed an obvious kludge?
My two cents, but that looks exactly right to me. Passing the float
to printf is going to convert it to a double and it will be printed as
a double, so you're unexpectedly adding double-precision operations to
the program.
Does printf("%f", (double) f) suppress the warning? That's an
explicit conversion instead of an implicit one.
--
Daniel Jacobowitz
CodeSourcery
Re: Fw: Debugging plugins with gdb
On Wed, Aug 11, 2010 at 03:52:17PM -0700, Jeff Saremi wrote: > > Trying to use "break execute_x" command in > > "add-symbol-file myplugin.so" but neither of them work. The > > first one complains that "function not defined" Did it ask you if you want to make the breakpoint pending? If it did, say yes. If it didn't, try a newer version of GDB. -- Daniel Jacobowitz CodeSourcery
Re: patch: honor volatile bitfield types
On Wed, Jun 23, 2010 at 11:34:04AM -0400, DJ Delorie wrote: > > > Can we similarly promise or say something for accesses of the > > containing struct as a whole? > > I hadn't considered those cases (when would you want to copy a > *peripheral* ?) Should be the same as before, I would think. Not the peripheral, just one register. e.g. you might read a control register into a struct of the same (32-bit) type, and then read multiple fields from the copied struct. -- Daniel Jacobowitz CodeSourcery
Re: Scheduling x86 dispatch windows
On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote: > > On the other hand, I'm not going to argue that it's a lot of work. Missing "not" ! > When you say "put assertions in the assembler output" I understood it > to mean "in the assembly source code output by the compiler", not "the > output produced by the assembler". Yes. > Does this qualify as a form of what you are suggesting? Because this > is exactly what is being proposed: > > .balign 8 # start window > insn op, op # 67 67 XX YY ZZ - padded with 2 prefixes to make 8 > insn2 op, op# AA BB CC > .padalign 8 # window boundary > insn4 op > . . . No, this is quite different. These are directives that tell the assembler to make changes. I'm talking about assertions, not directives. Something like this: mov r0, r1 @ [length 2] add ip, lr, ip @ [length 4] mov r0, r1 @ [length 4] <-- assembler error 'insn has length 2' GCC can output length information, but it is never exact, and it is not in a form recognized by the assembler. On x86, I have no idea how this would work. -- Daniel Jacobowitz CodeSourcery
Re: Scheduling x86 dispatch windows
On Thu, Jun 10, 2010 at 02:03:03PM -0600, Jeff Law wrote: > That adds quite a bit of complication to the compiler though -- > getting the instruction lengths right (and thus proper packing & > alignment) can be extremely difficult. I did some experiments with > this on a target with *fixed* instruction lengths a while back and > even though the port tried hard to get lengths right, it would > routinely miss something. Ultimately I decided that it forcing the > compiler to know instruction lengths with a very high degree of > accuracy wasn't a sane thing to do. FWIW, my opinion (and I think Jakub has expressed a similar opinion and/or tool in the past) is that there is a sane way to do this: put assertions in the assembler output and have the assembler validate them. On the other hand, I'm not going to argue that it's a lot of work. -- Daniel Jacobowitz CodeSourcery
Re: role of "register" C keyword?
On Thu, May 06, 2010 at 01:22:27PM -0700, Ian Lance Taylor wrote: > Basile Starynkevitch writes: > > > Long time ago (probably in the GCC 2.95 & 3.2 time frame) I would > > imagine that the "register" keyword indeed affected register > > allocation, in the sense that variables declared with register where > > indeed & preferentially put in a machine register. > > I don't think the "register" keyword ever affected register allocation > in gcc. For that you have to go back to compilers of the 1970s. I think it does, without optimization. There's some unique GDB tests that use this. It causes them to be live between statements in a machine register instead of always stored in stack slots. This might not be current information though. -- Daniel Jacobowitz CodeSourcery
Re: Code assistance with GCC
On Wed, Apr 21, 2010 at 01:12:37PM +0200, Basile Starynkevitch wrote: > However, I am not sure to understand why Tomohiro needs to hack the > GCC parser itself. I was thinking that he might instead write a > plugin which works at the Generic/TREE (or even perhaps Gimple) > level. That doesn't make sense. If you're doing code completion, then by definition, what you have now does not parse. If it doesn't parse, you can't build IL from it. A parser is pretty much all you need for code completion, not any of the rest of the compiler (e.g. Eclipse has just a parser and a syntax tree). -- Daniel Jacobowitz CodeSourcery
Re: Release novops attribute for external use?
On Mon, Apr 12, 2010 at 07:47:31PM +0100, Dave Korn wrote: > On 12/04/2010 19:04, Andrew Haley wrote: > > > I was thinking about non-memory-mapped I/O, a la x86 I/O ports. > > I've always thought that was a bad misnomer. Isn't it just an alternative > memory-mapped address space pretty much like main memory (regardless that the > mapped devices may have some fairly non-standard characteristics)? Certainly > from the compiler's point of view it's got to count as "memory"; it's > somewhere values come from and go to and are "externally visible". Then you can think about it as "does not alias any non-device memory", or any number of variants on that. -- Daniel Jacobowitz CodeSourcery
Re: Unexpected output constraints
On Fri, Apr 02, 2010 at 12:27:33AM +0100, Bernd Schmidt wrote: > That doesn't work either, a matching constraint has to be an input. i386 uses this, so I figure it's OK. > Also, legitimize_tls_address is calling it with the same reg for both > operands, which is going to lead to tears if they're both outputs. Hrm. Yeah, those really should be two pseudos. I'll fix that. -- Daniel Jacobowitz CodeSourcery
Re: Unexpected output constraints
On Fri, Apr 02, 2010 at 12:06:28AM +0100, Bernd Schmidt wrote: > On 04/01/2010 10:54 PM, Daniel Jacobowitz wrote: > > I'm debugging a Thumb-2 glibc build failure on trunk for > > arm-none-linux-gnueabi. I believe it's from Richard Earnshaw's > > 2010-02-01 patch for TLS patterns, which includes this: > > > > (define_insn "tls_load_dot_plus_four" > > [(set (match_operand:SI 0 "register_operand" "=l,r") > > (mem:SI (unspec:SI [(match_operand:SI 1 "register_operand" "+l,r") > > (const_int 4) > > (match_operand 2 "" "")] > >UNSPEC_PIC_BASE)))] > > > > It's that "+" on the second operand. It should just be "&", and I > > think that will fix the failure (I'll test it shortly). > > That can't be right, "&" only makes sense for outputs. Yeah, suitable juggling in match_scratch was what I really needed: (define_insn "tls_load_dot_plus_four" [(set (match_operand:SI 0 "register_operand" "=l,r") (mem:SI (unspec:SI [(match_operand:SI 1 "register_operand" "l,r") (const_int 4) (match_operand 2 "" "")] UNSPEC_PIC_BASE))) (clobber (match_scratch:SI 3 "=&1,&1"))] > > It seems to me that the problem is marking a register in the RHS of a > > set as an output constraint. > > Yes. There was a similar bug for tls_load_dot_plus_eight recently. In > this case it seems that operand 1 is in fact both read and written by > the pattern, so the pattern should be something like > > [(set (match_operand:SI 0 "register_operand" "=l,r") > (mem:SI (unspec:SI [(match_dup 1) > (const_int 4) > (match_operand 2 "" "")] >UNSPEC_PIC_BASE))) >(clobber (match_operand:SI 1 "register_operand" "+&l,&r"))] Is there a reason to prefer one of these forms over the other? match_scratch / match_dup always make me ask that question :-) -- Daniel Jacobowitz CodeSourcery
Unexpected output constraints
I'm debugging a Thumb-2 glibc build failure on trunk for
arm-none-linux-gnueabi. I believe it's from Richard Earnshaw's
2010-02-01 patch for TLS patterns, which includes this:
(define_insn "tls_load_dot_plus_four"
[(set (match_operand:SI 0 "register_operand" "=l,r")
(mem:SI (unspec:SI [(match_operand:SI 1 "register_operand" "+l,r")
(const_int 4)
(match_operand 2 "" "")]
UNSPEC_PIC_BASE)))]
It's that "+" on the second operand. It should just be "&", and I
think that will fix the failure (I'll test it shortly). But I'm
looking at what reload does before the failure.
The failing insn is 104, in this sequence:
(insn 103 79 175 2 delta/in7c.i:50 (set (reg/f:SI 217)
(const:SI (unspec:SI [
(symbol_ref:SI ("*.LANCHOR0") [flags 0x1a2])
(const_int 3 [0x3])
(const (unspec:SI [
(const_int 3 [0x3])
] 21))
(const_int 4 [0x4])
] 20))) 658 {*thumb2_movsi_insn} (nil))
...
(insn 104 102 107 11 delta/in7c.i:50 (set (reg:SI 203)
(mem:SI (unspec:SI [
(reg/f:SI 217)
(const_int 4 [0x4])
(const_int 3 [0x3])
] 4) [0 S4 A32])) 659 {tls_load_dot_plus_four} (nil))
For #104, reg_equiv_constant[217] is set to the (const) from #103.
And because r217 is marked as in-out from tls_load_dot_plus_four,
the reload is RELOAD_READ_WRITE. If the operand is an output, then
it can't be correct to replace it with a constant. We ICE
trying to emit (set (const) (reg)).
It seems to me that the problem is marking a register in the RHS of a
set as an output constraint. The reg becomes function_invariant_p and
chaos ensues.
Is this right? If so, is there somewhere that should assert if an
operand's constraint is marked as an output, but not somewhere that
the RTL allows modification of the operand?
--
Daniel Jacobowitz
CodeSourcery
Re: Use the wctype builtins functions
On Thu, Mar 11, 2010 at 10:46:42AM +0100, Paolo Bonzini wrote:
> On 03/05/2010 05:03 PM, Joseph S. Myers wrote:
> >I don't know if there's an existing free software implementation of UAX#14
> >(Unicode Line Breaking Algorithm) suitable for use in GCC; that would be
> >the very heavyweight approach.
>
> Yes. You can get it from gnulib like gdb does, or you can link
> libunistring (http://savannah.gnu.org/projects/libunistring).
> libunistring only supports UTF-{8,16,32} encodings though.
I don't think GDB actually does today. But here's a prototype:
http://sourceware.org/ml/gdb-patches/2006-10/msg0.html
--
Daniel Jacobowitz
CodeSourcery
Re: [RFH] A simple way to figure out the number of bits used by a long double
On Fri, Feb 26, 2010 at 06:09:37PM +0100, Paolo Carlini wrote:
> On 02/26/2010 05:36 PM, Andreas Schwab wrote:
> > See libiberty/floatformat.c.
> >
> Ok, thanks. Actually, it looks like there is *no* padding in the middle
> for the Intel x87 format I truly care about:
>
> const struct floatformat floatformat_i387_ext =
> {
> floatformat_little, 80, 0, 1, 15, 0x3fff, 0x7fff, 16, 64,
>
> I read it as meaning 0 sign, 1-15 exponent, 16-79 mantissa.
>
> But really we don't want to deal with all those special cases for other
> formats, for now at least. Too bad.
Despite all that exchange, I don't think you ever answered Andreas's
question - at least not in a way that I could understand. A size of
what? The size of the *type* on x86 is 16; the size of the *data
bits* is 10. But what cares about the size of the data bits rather
than e.g. the size of the mantissa?
--
Daniel Jacobowitz
CodeSourcery
Re: Gprof can account for less than 1/3 of execution time?!?!
On Mon, Feb 22, 2010 at 05:09:53PM -0600, Jon Turner wrote: > Doh! Thanks, Nathan. I think you put your finger on it. > I was well aware of the overhead that gprof can introduce, > but did not recognize that this overhead was not being > counted by gprof. gprof generally does not have any support for shared libraries. It will ignore profiling samples that lie outside the executable. And in this case, that includes _mcount (which is in libc.so.6). That's probably why. -- Daniel Jacobowitz CodeSourcery
Re: insn length attribute and code size optimization
On Wed, Feb 10, 2010 at 09:55:25AM -0600, Quentin Neill wrote: > GAS knows this information for each insn. That's not the problem. GCC knows the lengths by the time it's a whole instruction. The problem is figuring out what instruction (plus (reg) (reg)) will expand to - before you even know what the registers are. -- Daniel Jacobowitz CodeSourcery
Re: insn length attribute and code size optimization
On Wed, Feb 03, 2010 at 06:23:19AM -0800, Ian Lance Taylor wrote: > fanqifei writes: > > > According to the internal manual, insn length attribute can be used to > > to calculate the length of emitted code chunks when verifying branch > > distances. > > Can it be used in code size optimization? > > I suppose it could, but it isn't. Instead of asking the backend for > the length of instructions, the compiler asks the backend for the cost > of instructions. The backend is free to determine that cost however > it likes. When using -Os, using the size of the instruction is a good > measure of cost. It seems to me that there's a hard ordering problem here: we can't determine insn lengths, using the current framework, until very late. We need at least (A) whole instructions, not just RTL expressions; (B) register allocation to select alternatives; (C) branch shortening to determine branch alternatives. I'm curious if anyone thinks there's a generic solution to this (that doesn't involve a complete instruction selection rewrite :-). -- Daniel Jacobowitz CodeSourcery
Re: Obsoleting IRIX < 6.5, Solaris 7, and Tru64 UNIX < V5.1
On Sat, Jan 30, 2010 at 07:28:01AM -0800, Ian Lance Taylor wrote: > However, it would not surprise me to discover that there are embedded > systems out there still using o32, with assembly functions which > expect the o32 calling convention. I would be cautious about removing > support for o32 entirely. I don't think anyone's suggested that. o32 is the default ABI for 32-bit MIPS GNU/Linux targets which are still in wide use. -- Daniel Jacobowitz CodeSourcery
Re: [ARM] Neon / Ocaml question
On Mon, Jan 11, 2010 at 12:28:38PM +, Julian Brown wrote: > Another thing which might bite you is that recent OCaml versions don't > like hyphens in filenames: replacing them with underscores works OK > though (i.e. neon_schedgen.ml). Fortunately it's just a warning; you can also ignore it. -- Daniel Jacobowitz CodeSourcery
Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]
On Tue, Jan 05, 2010 at 05:01:24PM -0800, Roland McGrath wrote: > > why not make this more explicit by adding an option --ld which is > > directly understood by the gcc driver? > > Feel free to send some gcc patches. I see no point in this. > We have -Wl. I deal with a lot of host systems where shell scripts aren't a viable option for ld. Why make everyone write the wrapper script? Makes sense to me to have gcc decide. -- Daniel Jacobowitz CodeSourcery
Re: How to implement pattens with more that 30 alternatives
On Tue, Dec 22, 2009 at 04:24:01PM +, Martin Guy wrote: > I wouldn't bother implementaing that if the VFP/Cirrus conflict is the > only thing that needs that. > GCC's has never been able to generate working code for Cirrus > MaverickCrunch for over a dozen separate reasons, from incorrect use > of the way the Maverick sets the condition codes to hardware bugs in > the 64-bit instructions (or in the way GCC uses them). > > I eventually cooked up over a dozen patches to make 4.[23] generate > reliable crunch floating point code but if you enable the 64-bit insns > it still fails the openssl testsuite. Interesting, I knew you had a lot of Cirrus patches but I didn't realize the state of the checked-in code was so bad. Is what's there useful or actively harmful? -- Daniel Jacobowitz CodeSourcery
Re: How to implement pattens with more that 30 alternatives
On Tue, Dec 22, 2009 at 02:12:48PM +, Richard Earnshaw wrote: > There is. Look at attribute "enabled". > > I've not worked out how to use that properly yet, but it is used in the > m68k back-end. Interesting. This seems to replace needing either (A) a bunch of similar patterns with different insn predicates, or (B) a bunch of new constraints that expand to "not available unless such and such ISA is enabled". That's a nice improvement, although we're back to the number of alternatives getting quite high. This does still leave us with weird operand predicates. For instance, in a patch I'm working on for ARM cmpdi patterns, I ended up needing "cmpdi_lhs_operand" and "cmpdi_rhs_operand" predicates because Cirrus and VFP targets accept different constants. Automatically generating that would be a bit excessive though. -- Daniel Jacobowitz CodeSourcery
Re: How to implement pattens with more that 30 alternatives
On Tue, Dec 22, 2009 at 12:09:55PM +, Paul Brook wrote: > i.e. the following will work as expected: > > (define_insn "*my_movsi" > (set (match_operand:SI "..." "=a,b") > (match_operand:SI "..." "ab,ab"))) > > However the following will not. Once gcc has picked a particular insn > (_a or _b), it will tend to stick with it and not try other patterns. This is my understanding too - but it's a real nuisance. Suppose you have two optional ISA extensions that have their own move instructions. For the sake of conversation I'll call them Alice and Bob... no, I'll call them TARGET_MAVERICK and TARGET_NEON. Now you need a minimum of three copies of the mov pattern that are mostly the same. It'd be nice if there was a way to compose instruction patterns :-( -- Daniel Jacobowitz CodeSourcery
Re: New RTL instruction for my port
On Tue, Dec 15, 2009 at 10:08:02AM -0500, Jean Christophe Beyler wrote:
> You are correct. So I should be changing things in the adjust_cost
> function instead.
>
> I was also wondering, these instructions modify an internal register
> that has been set as a fixed register. However, the compiler optimizes
> them out when the accumulator is not retrieved for a calculation. How
> can I tell the compiler that it should not remove these instructions.
>
> Here is an example code:
>
> uint64_t foo (uint64_t x, uint64_t y)
> {
> uint64_t z;
>
> __builtin_newins (x,y); /* Modifies the accumulator */
>
> z = __builtin_retrieve_accum (); /* Retrieve the accumulator */
>
> return z;
> }
>
> If I remove the instruction "z = ...;", then the compiler will
> optimize out my first builtin call.
I suppose you could use EPILOGUE_USES to say that changes to the
accumulator should not be discarded. You could also use
unspec_volatile instead of unspec, but that may further inhibit
optimization.
--
Daniel Jacobowitz
CodeSourcery
Re: New RTL instruction for my port
On Mon, Dec 14, 2009 at 05:52:50PM -0500, Jean Christophe Beyler wrote: > I thought of that but then how do I add the cost ? I also have another > problem: there is a second instruction that would have the exact same > signature if I use an unspec. > > Is there a solution for that and how do I handle the cost then ? >- Just say that an unspec has a higher cost? Are you really talking about rtx_costs? It sounds to me more like you want to change your scheduler. -- Daniel Jacobowitz CodeSourcery
Re: New RTL instruction for my port
On Mon, Dec 14, 2009 at 04:46:59PM -0500, Jean Christophe Beyler wrote: > My current solution: > > - Define a new rtl in rtl.def Just use an unspec or unspec_volatile. You don't need a new RTL operation. > - Add the new rtl in the MD file and the generated assembly instruction > > However, the solution seems to work, except in O0, where I get this error: This means whatever is calling gen_newrtl to create the insn is not checking operand predicates first. That's probably code you wrote too. -- Daniel Jacobowitz CodeSourcery
Re: detailed comparison of generated code size for GCC and other compilers
On Mon, Dec 14, 2009 at 06:17:45PM +0100, Andi Kleen wrote: > I personally feel that test cases that get optimized away are not > very interesting. Actually, I think they're very interesting - especially if they are valid code, and one compiler optimizes them away, but the other doesn't. You may have heard of a commercial testsuite built on this principle :-) -- Daniel Jacobowitz CodeSourcery
Re: TLS support on ARM
On Thu, Dec 03, 2009 at 05:09:38PM +, Thomas Klein wrote: > This might be the initial plan. > But is this true? It is true because a typical implementation of this function has no need to clobber registers. For instance, glibc's calls a kernel helper this way: 0x00015810 <__aeabi_read_tp+0>: mvn r0, #61440 ; 0xf000 0x00015814 <__aeabi_read_tp+4>: sub pc, r0, #31 The kernel helper reads from a fixed location or a hardware register, both of which are a single instruction. No temporary registers are required. > A "bl __aeabi_read_tp" call does not exchanging the mode. > So the program simply crashes. The linker is responsibe for converting bl to blx, or for inserting mode changing stubs. It is also responsible for long calls. Unless you're using a really old linker, I can't see why you would have any problems. Do you have a concrete problem? > Is the implementation still incomplete? No. It's been finished for two years or more. -- Daniel Jacobowitz CodeSourcery
Re: TLS support on ARM
On Thu, Dec 03, 2009 at 02:28:36PM +, Thomas Klein wrote: > Dose anyone know the reason why they are not clobbered? So that they don't have to be saved. This function is supposed to be very fast. If you want to use a slow implementation, write an assembly wrapper which saves additional registers. > The next point is that the __builtin_thread_pointer() call isn't > ARM/Thumb interwork save. > To use the "hard" Coprocessor fetch instruction the calling function > must run in ARM mode. True (or Thumb-2, I think). > To use "soft" implementation caller and __aeabi_read_tp() must run in > the same mode. I don't believe that this is true. In what way is it not safe? -- Daniel Jacobowitz CodeSourcery
Re: WTF?
On Wed, Nov 25, 2009 at 08:31:27PM +0100, Richard Guenther wrote: > And patch doesn't have an option to ignore whitespace changes. Sure it does. -l (for loose, or --ignore-whitespace). QUILT_PATCH_OPTS for quilt. -- Daniel Jacobowitz CodeSourcery
Re: (C++) mangling vector types
On Thu, Nov 12, 2009 at 08:10:13AM -0800, Richard Henderson wrote: > On 11/12/2009 07:24 AM, Jason Merrill wrote: > >1) Leave the current mangling as is > >2) Leave the current mangling as is for the most common vector size on a > >target (SSE, Altivec) and use the new mangling for other vector sizes. > >3) Switch to the new mangling > > I vote for 2. Does anyone know of another relevant compiler? What does it do? For instance, if someone can hand me a test case, I could check how ARM's compilers mangle it (or don't). -- Daniel Jacobowitz CodeSourcery
Re: -use-linker-plugin passed to ld
On Mon, Oct 26, 2009 at 06:10:06PM -0400, Hans-Peter Nilsson wrote: > On Fri, 23 Oct 2009, Ian Lance Taylor wrote: > > Steven Bosscher writes: > > > I was just wondering why this is not a -f* flag, e.g. -fuse-linker-plugin? > > Any opinions on the best user interface for this? > > The color that spells -fuse-linker-plugin seems better, in line > with other options. How it's implemented, especially regarding > having to ignore it in middle-end is unimportant wrt. spelling, > IMVHO. I agree with H-P. -- Daniel Jacobowitz CodeSourcery
Re: LTO and the inlining of functions only called once.
On Wed, Oct 14, 2009 at 04:33:35PM +0200, Jan Hubicka wrote: > > Deciding on smaller functions: > > Considering inline candidate phcall_.clone.3. > > Inlining failed: --param max-inline-insns-auto limit reached > Yes, I would be interested. It seems that for osme reason the other > functions are not considered to be called once, perhaps a visibility > issue. We also should say what limit was reached on inlining hlprog. Maybe because of whatever did that cloning? -- Daniel Jacobowitz CodeSourcery
Re: LTO and the inlining of functions only called once.
On Tue, Oct 13, 2009 at 10:41:39AM +0100, Paul Brook wrote: > My guess is anyone inspecting the code and optimizer decisions at this level > is also going to want to strongarm the result they want when the compiler > makes the "wrong" decision. i.e. detailed unroller diagnostics are only of > limited use without (say) #pragma unroll. Not too limited, I'd say. I've seen a lot of developers willing to mutilate their critical loops to accomodate the compiler. -- Daniel Jacobowitz CodeSourcery
Re: Issues of the latest trunk with LTO merges
On Mon, Oct 12, 2009 at 08:09:48AM -0700, Bingfeng Mei wrote: > Richard, > Doesn't REGISTER_TARGET_PRAGMAS need to call c_register_pragma, etc, if we > want to specify target-specific pragma? It becomes part of libbackend.a, > which is linked to lto1. One solution I see is to put them into a separate > file so the linker won't produce undefined references when they are not > actually used by lto1. Yes. Take a look at config/arm/arm-c.c, which does not go into libbackend.a. -- Daniel Jacobowitz CodeSourcery
Re: LTO and the inlining of functions only called once.
On Sat, Oct 10, 2009 at 02:31:25PM +0200, Jan Hubicka wrote: > My solution would be probably to pass -fdump-ipa-inline parameter to lto > compilation and read the log. It lists the inlining decisions and if > something is not inlined, you get dump of reason why. GCC's dumps are really aimed at compiler developers. I think we would benefit from more "what is the compiler doing to my code" options (producing "note:"); things like which functions were inlined, which loops unrolled. We do already have this for vectorization. -- Daniel Jacobowitz CodeSourcery
Re: LTO and LTO Plugin Reviewers
On Wed, Oct 07, 2009 at 04:29:29PM +0200, Basile STARYNKEVITCH wrote: > I suppose LTO plugins means plugin dlopen-ed in lto-plugin/lto-symtab.c It sounds to me like this confusion comes from "LTO plugins". Isn't it just "LTO plugin"? That is, a specific plugin? -- Daniel Jacobowitz CodeSourcery
Re: Headsup: Rogue or hacked account spamming via RT? re: [gnu.org #263454]
On Wed, Sep 30, 2009 at 06:48:02PM -0400, Dave Korn via RT wrote: > > Hello GNU webmasters, > > I hope this is the right place to report what appears to be a problem at > rt.gnu.org, I couldn't find an explicit contact address for it. > > We just got two posts on the GCC mailing list with the subject line > "[gnu.org #263454] Take home $204,000.00 this month": > > http://gcc.gnu.org/ml/gcc/2009-09/msg00650.html > http://gcc.gnu.org/ml/gcc/2009-09/msg00651.html > > and according to the headers (visible by the "raw text" links at the above > URLs) these appear to have genuinely originated at rt.gnu.org via the web > interface: Isn't this more likely the RT admins closing spam reports? -- Daniel Jacobowitz CodeSourcery
Re: armv4t
On Mon, Sep 21, 2009 at 11:54:17AM -0600, Kevin Handy wrote: > What version of GCC will build for a cross --target=armv4t-linux-eabi, > which I believe is the right code for an ixp425 processor? The host > compiler is gcc-4.3.3 on a Linux-debian-test system. I have also tried > unsuccessfully tried the armv5t target, with similar results. Don't try to put it in the triplet. Try using --with-cpu instead, and a normal armv4t-linux-gnueabi triplet. I'm pretty sure Xscale implements ARM v5TE though, so none of thse hoops should be necessary. > I need to find out where to look for a functional version of the gcc > cross compiler for this cpu. If you can't build GCC for your target, I suggest you either use a help list for that purpose (gcc-help or the crosstool or buildroot lists), or find a pre-compiled ARM Linux toolchain. -- Daniel Jacobowitz CodeSourcery
Re: c-c++-common testsuite
On Thu, Aug 06, 2009 at 05:38:01PM -0700, Janis Johnson wrote: > I've been thinking about that lately, it would be useful for several > kinds of functionality. We'd want effective targets for the language > for using different options and for providing different error/warning > checks for each language. I haven't looked into how to handle it with > DejaGnu, maybe something like gcc.shared and a [symbolic] link to it > called g++.shared; do links work with Subversion? It should be easy with DejaGNU; does changing $tests in e.g. g++.dg/dg.exp successfully pick up files from another directory? -- Daniel Jacobowitz CodeSourcery
Re: libiberty should be a shared library when cc1 has plugin enabled.
On Thu, Jul 09, 2009 at 03:45:52PM +0200, Basile STARYNKEVITCH wrote: > Daniel Jacobowitz wrote: > >On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote: > >>In simpler words, *.so have to be compiled with -fPIC, and libiberty > >>is not compiled with -fPIC. > > > >We build a PIC libiberty already. > > > > Thanks! > > Where and how is it built? I cannot find any *iberty*.so in my build tree! It's an archive, not a shared library. It's probably in libiberty/pic/ but there's configury involved. -- Daniel Jacobowitz CodeSourcery
Re: libiberty should be a shared library when cc1 has plugin enabled.
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote: > In simpler words, *.so have to be compiled with -fPIC, and libiberty > is not compiled with -fPIC. We build a PIC libiberty already. While Ralf's point about static data is valid, the functions likely to be in libiberty on any platform supporting plugins should not suffer from this problem. If you're concerned about it, then build a subset. I've considered a separation of libiberty into replacements and utilities, anyway. -- Daniel Jacobowitz CodeSourcery
Re: libiberty should be a shared library when cc1 has plugin enabled.
On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote: > But it seems to me that a plugin can call a libliberty function only if that > function is already referenced (e.g. called) from cc1. This is not the case > of all libiberty functions. So... link libiberty into your plugin and get make_temp_file that way. -- Daniel Jacobowitz CodeSourcery
Re: avoiding gdb cc1plus PACK_EXPANSION_PATTERN(result) gives 'No symbol "__extension__"', error msg
On Wed, Jul 08, 2009 at 03:14:20PM -0700, Richard Henderson wrote: > On 07/08/2009 03:11 PM, Larry Evans wrote: > >It would be much easier if gdb understood __extension__. Is there a way? > > In this case, no. It's protecting a statement expression, which gdb > will never be able to parse. > > A better project for helping debug gcc would be to convert all macros > that use statement expressions into proper inline functions. Which > would then be emitted as out-of-line functions by gcc's > -fkeep-inlines flag, which would yield something that's callable from > within gdb. FWIW, as a GDB maintainer I completely agree with Richard. We could teach GDB to ignore __extension__, which is used in some other places (like "long long"). You can even do this from the command line using "macro define": (gdb) macro define __extension__ (gdb) p __extension__ 1 $1 = 1 That's all that's necessary; it's used to suppress warnings. Statement expressions, on the other hand, are right out. I can't see any practical way to teach GDB about that. -- Daniel Jacobowitz CodeSourcery
Re: VTA guality assessment: better than -O0 ;-)
On Sat, Jun 13, 2009 at 10:08:39PM +0200, Jakub Jelinek wrote: > I really think we need to do (limited) -fvar-tracking even for -O0, it is > really bad that most arguments have wrong locations through the prologue, > while at -O1 or above they often have correct location. > We should just do the tracking inside of the prologue or for register > variables, those that are stored into memory during the prologue and live in > memory shouldn't be tracked outside of the prologue at -O0. I completely agree, this would make GDB more useful. -- Daniel Jacobowitz CodeSourcery
Re: i370 port
On Sat, Jun 06, 2009 at 01:39:07AM +1000, Paul Edwards wrote: >> I understand current GCC supports various source and target character >> sets a lot better out of the box, so it may be EBCDIC isn't even an >> issue any more. > > It looks that way from what I've seen of 3.4.6 so far. However, I > won't know for sure until it's on the host and self-generating. Why are you migrating to 3.4.6 now, instead of to a current version? If you want to include this in mainline some day, then eventually it has to be caught up - and 3.4.6 is older than it may appear from the release date, since it branched off of mainline five years ago. A lot has changed since then. -- Daniel Jacobowitz CodeSourcery
Re: naked zero_extracts longer than a word.
On Mon, May 11, 2009 at 12:25:50PM -0700, Ian Lance Taylor wrote: > I feel reasonably confident that there will never be a processor which > supports a bitfield instruction which operates on multiple hard register > simultaneously. I don't think that is a case we need to worry about. > > (I will now wait for somebody to post an example of such a processor.) I can't quite do that, but here's a likely scenario: registers which GCC views as separate but are really combined. For instance, if ARM NEON supported bitfield insert/extract (which it unsurprisingly does not), we'd have a problem: the 'qN' registers are two 'dN' registers concatenated, and GCC only knows about them once. -- Daniel Jacobowitz CodeSourcery
Re: Interest in integer auto-upcasting pass for normalization and optimization?
On Sat, May 09, 2009 at 10:07:38PM +0200, Albert Cohen wrote: > I wonder if some of this is already implemented somewhere, or if someone > played with it in the past, or is interesting in contributing. This sounds a bit similar to Nathan Froyd's recent work: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01860.html -- Daniel Jacobowitz CodeSourcery
Re: gcc-gdb compatibilty
On Sat, Apr 25, 2009 at 10:35:07AM -0700, Ian Lance Taylor wrote: > Yes, while there are of course occasional bugs and mismatches, in > general all versions of gcc and gdb are compatible. That said, gdb 5.3 > is old; it was released over five years ago. It will ignore some of the > newer types of debugging information emitted by gcc. The current gdb > release is 6.8, and is considerably enhanced over 5.3. You should > consider upgrading if possible. Newer GDB almost always works with older GCC. Older GDB often does not work with newer GCC; I suspect 5.3 will crash and/or be useless with most GCC 4.x binaries. For instance, in that time we added location list support. -- Daniel Jacobowitz CodeSourcery
Re: Diagnostic Messaging Suggestion
On Fri, Apr 17, 2009 at 11:58:48AM -0600, Tom Tromey wrote: > Chris> Clang just prints the include stack information when anything > Chris> in the include stack differs between two consecutive > Chris> diagnostics. > > We could easily do that too. FWIW, I think this would be quite useful. -- Daniel Jacobowitz CodeSourcery
Re: GCC + libJIT instead of LLVM
On Wed, Apr 01, 2009 at 06:54:55PM +0200, Manuel López-Ibáñez wrote: > 2009/4/1 Kirill Kononenko : > > > > This is what Chris Lattner wrote a couple of years ago. Now I see an > > exactly contradiction: > > > > Please, could you pinpoint side-by-side the two sentences that > contradict each other and later give links to (or quote) the context? > I am having troubling identifying the contradiction. Please, could you not do it on this list? A discussion about the differences between LLVM and libjit is wildly off-topic for GCC development. -- Daniel Jacobowitz CodeSourcery
Re: Fwd: Mips, -fpie and TLS management
On Tue, Mar 17, 2009 at 04:21:18PM +0100, Joel Porquet wrote: > Problem is how can you find the symbol referenced by the relocation > when the symbol index is null?? > Then, should we consider that a null symbol index means that the > module relocation is the DSO itself? Yes, that's what I said. This is how the uClibc and GLIBC dynamic loaders work and I believe it's described in Ulrich's paper. -- Daniel Jacobowitz CodeSourcery
Re: Fwd: Mips, -fpie and TLS management
On Tue, Mar 17, 2009 at 04:03:45PM +0100, Joel Porquet wrote: > 2009/3/17 Daniel Jacobowitz : > > On Tue, Mar 17, 2009 at 10:26:05AM +0100, Joel Porquet wrote: > >> I don't understand how the runtime loader could know that! As far as I > >> know, the tls model is not embedded in reloc information. > > > > Sure it is. I suggest you go back to Ulrich Drepper's TLS paper > > for more information about the relocations. > > The only information is whether the module uses a static model. So we > are able to distinguish *-dynamic from *-exec models. Nevertheless, I > still don't see how the runtime loader can distinguish local-dynamic > and global-dynamic: when it goes through the relocations, it only sees > *DTPMOD32 which is common for both models. It's based on the symbol referenced by the relocation. -- Daniel Jacobowitz CodeSourcery
Re: Fwd: Mips, -fpie and TLS management
On Tue, Mar 17, 2009 at 10:26:05AM +0100, Joel Porquet wrote:
> I don't understand how the runtime loader could know that! As far as I
> know, the tls model is not embedded in reloc information.
Sure it is. I suggest you go back to Ulrich Drepper's TLS paper
for more information about the relocations.
> I don't know how to figure this out (actually, that's why I'm writing
> on this ml). I just wrote a small function which uses a tls variable
> and gcc did the rest.
>
> __thread unsigned int *tty;
> void puts(char *str)
> {
> while(*str)
> *tty = *str++;
> }
If you believe there is a bug, and you have a testcase, please report
it in bugzilla. Thanks.
--
Daniel Jacobowitz
CodeSourcery
Re: Fwd: Mips, -fpie and TLS management
On Mon, Mar 16, 2009 at 06:19:01PM +0100, Joel Porquet wrote: > 2009/3/12 Daniel Jacobowitz : > > On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote: > >> > Check what symbol is at, or near, 0x4003 + 22368. It's probably > >> > the GOT plus a constant bias. > >> > >> It seems there is nothing at this address. Here is the program header: > > > > Don't know then. Look at compiler-generated assembly instead of > > disassembly; that often helps. > > Do you mean the object file produced by gcc before linkage? That will do, but the actual assembly (-S) is more helpful sometimes. > > This is a *module* relocation. In local dynamic the module is always > > the current DSO; it does not need a symbol. > > But what if the DSO access other module's TLS? Then it does not use "Local" Dynamic to do so. > > Finally, I noticed another problem. GCC seems to not make room for the > 4 arguments as specified in the ABI, when calling __get_tls_addr. > For example, here is an extract of the code for calling (we see that > data are stored directly at the top of the stack): > > ... > 5ffe0bfc: 27bdfff0addiu sp,sp,-16 > 5ffe0c00: afbf000csw ra,12(sp) > 5ffe0c04: afbcsw gp,0(sp) That line is bogus. Figure out where it came from; the cprestore offset should not be zero. -- Daniel Jacobowitz CodeSourcery
Re: GCC 4.4.0 Status Report (2009-03-13)
On Fri, Mar 13, 2009 at 06:25:34PM +0100, Richard Guenther wrote: > On Fri, 13 Mar 2009, Dave Korn wrote: > > > >> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther > > >> wrote: > > >>> We have been asked by the SC to not branch for now but wait for > > [...] > > > Can anyone clarify if the SC *really* need us to not branch before the > > license change, as opposed to merely not /release/ until then? > > The topmost sentence should be unambiguous. Yes, the SC asked us not > to branch. But: > (And why, if so?) -- Daniel Jacobowitz CodeSourcery
Re: Fwd: Mips, -fpie and TLS management
On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote: > > Check what symbol is at, or near, 0x4003 + 22368. It's probably > > the GOT plus a constant bias. > > It seems there is nothing at this address. Here is the program header: Don't know then. Look at compiler-generated assembly instead of disassembly; that often helps. > By the way, how did you test the code of TLS for mips? I mean, uclibc > seems the more advanced lib for mips, and although this lib seems to > have the necessary code to manage tls once it is "installed", the ldso > doesn't contain any code for handling TLS (relocation, tls allocation, > etc)... That statement about uclibc strikes me as bizarre. I tested it with glibc, naturally. GLIBC has a much more reliable TLS implementation than uclibc's in-progress one. > >> Last question, is there a difference between DSO and PIE objects other > >> than the INTERP entry in the program header? > > > > Yes. Symbol preemption is allowed for DSOs but not for PIEs or normal > > executables. That explains the different choice of model. > > But this is only a property, isn't it? I was meaning, how can you > differenciate them at loading time, when you "analyse" the elf file. You can't. > As you surely know, ELF_R_SYM() macro performs (val>>8) which gives > the symbol index in order to retrieve the name of the symbol. This > name then allows to look up the symbol. Unfortunately, in the case of > local-dynamic, ELF_R_SYM will return 0 which is not correct (the same > for global-dynamic will return 9): we can see by the way that readelf > is not able to get the symbol name. What do you think about this? This is a *module* relocation. In local dynamic the module is always the current DSO; it does not need a symbol. -- Daniel Jacobowitz CodeSourcery
Re: Fwd: Mips, -fpie and TLS management
On Wed, Mar 11, 2009 at 11:03:10AM +0100, Joel Porquet wrote:
> By default, the chosen tls model is "initial-exec", which causes one
> relocation for "b" (R_MIPS_TLS_TPREL32). If I specify "local-exec",
> the behavior is as expected, I get no relocation at all. But whenever
> I choose a dynamic model ("local-dynamic" or "global-dynamic"), I
> still get a "R_MIPS_TLS_TPREL32" which is not a dynamic relocation.
> Why this?
No particular reason, it's just how GCC behaves. I consider it a
bug, though minor.
> 5ffe0424: 3c034003lui v1,0x4003
> 5ffe0428: 00621821adduv1,v1,v0
> 5ffe042c: 8c625760lw v0,22368(v1)
> The suspicious instruction is "lui v1,0x4003". I don't understand
> where does "0x4003" comes from...
Check what symbol is at, or near, 0x4003 + 22368. It's probably
the GOT plus a constant bias.
> This time, it seems gcc expects "__get_tls_addr" to return the
> DTP+0x8000. Indeed the access to variable "b" is done with "lw
> v0,-32768(v1)" and 32768==0x8000.
Are you sure both of those code sequences are calling __tls_get_addr?
If so, compare the arguments they passed.
> Last question, is there a difference between DSO and PIE objects other
> than the INTERP entry in the program header?
Yes. Symbol preemption is allowed for DSOs but not for PIEs or normal
executables. That explains the different choice of model.
--
Daniel Jacobowitz
CodeSourcery
Re: Split Stacks proposal
On Fri, Feb 27, 2009 at 09:10:10AM +0100, Mathieu Lacage wrote:
> - if you want to use the stack protector and split stacks, it should
> be fairly trivial to extend the data structure which contains the stack
> protector with a new field, no ?
The stack protector is just a word, not a pointer. It's held in a
highly magic location on some platforms, e.g. relative to the thread
base register. There's not a lot of space there. It might be
possible to reserve more in coordination with glibc, for glibc
targets.
> - I understand that you need to copy the function parameters from the
> old stack to the new stack, but, why would you need to invoke the C++
> copy or move constructors for this ? Would a memcpy not be sufficient to
> ensure proper C++ semantics in this case ? An example which shows how a
> memcpy would break might be interesting.
I haven't written C++ in a while, so forgive any obvious gaffes.
class X {
int x, *y;
X() {
y = &x;
}
X(X &obj) {
x = obj.x;
y = &x;
}
}
Memcpy that somewhere else and the internal pointer is invalid.
--
Daniel Jacobowitz
CodeSourcery
Re: ARM : code less efficient with gcc-trunk ?
On Mon, Feb 16, 2009 at 12:19:52PM +0100, Vincent R. wrote:
> 00011000 :
>11000: e92d40f0push{r4, r5, r6, r7, lr}
>11004: e1a04000mov r4, r0
>11008: e1a05001mov r5, r1
>1100c: e1a06002mov r6, r2
>11010: e1a07003mov r7, r3
> 00011000 :
>11000: e92d4010push{r4, lr}
>11004: e1a04000mov r4, r0
>11008: e24dd00csub sp, sp, #12 ; 0xc
>1100c: e58d1008str r1, [sp, #8]
>11010: e58d2004str r2, [sp, #4]
>11014: e58d3000str r3, [sp]
Notice how many more registers used to be pushed? I expect the new
code is faster.
> Maybe my remark is not relevant because I didn't try to do some benchmark
If you find any code that *runs* slower, please report it as a bug in
Bugzilla.
--
Daniel Jacobowitz
CodeSourcery
Re: Does gcc conform to C++ ABI?
On Fri, Feb 13, 2009 at 12:00:38PM -0800, Ian Lance Taylor wrote: > > Another issue for scope encoding. C++ ABI: > > > > --- > > Occasionally entities in local scopes must be mangled too > > (e.g. because inlining or template compilation causes multiple > > translation units to require access to that entity). > > --- > > > > seems to imply that the local symbols may have external > > linkage. Am I wrong? > > You are wrong. When an inline function is expanded into multiple > translation units, and that inline function has a static variable, then > multiple translation units require access to the static variable. That > does not imply that the static variable has external linkage. Does this mean that if you compiled some of those TUs with GCC, and some with icc, they might legitimately access different copies of the static variable? Seems odd. -- Daniel Jacobowitz CodeSourcery
Re: gcc 3.3.6 and multilib
On Mon, Feb 09, 2009 at 03:15:20PM +0300, Sergey Anosov wrote: > [r...@st1 SPECS]# mips-vniins-linux-gcc -print-multi-lib > .; > el;@EL > > But output of > mips-unknown-linux-gcc --print-search-dirs > and > mips-unknown-linux-gcc -mel --print-search-dirs > is the same. Did you try mips-unknown-linux-gcc -EL -print-search-dirs? -- Daniel Jacobowitz CodeSourcery
Re: Constant folding and Constant propagation
On Fri, Feb 06, 2009 at 11:46:58AM -0500, Jean Christophe Beyler wrote: > I finally get this : > > (const_int 51966 [0xcafe]) > (const_int 51966 [0xcafe]) > (const_int 51971 [0xcb03]) > (const_int 51971 [0xcb03]) > > All of these have an outer code of SET. Therefore, I'm not quite > positive of how I'm supposed to implement my rtx_cost function. Since > I don't seem to get a choice between a set 0xcb03 and a (plus 0xcafe > 5), how can I tell the compiler the different costs? They may all have an outer code of SET, but you get the entire inner RTX. Search arm_rtx_costs_1 for "CONST_INT:". -- Daniel Jacobowitz CodeSourcery
Re: ARM compiler generating never-used constant data structures
On Fri, Feb 06, 2009 at 12:30:13AM +1100, Zoltán Kócsi wrote: > Almost the same: > > x86_64: 4.0.2 > AVR:4.0.1 > ARM:4.0.2 > > So, at least the Intel and the ARM are the same yet the Intel version > omits the .rodata, the ARM keeps it. I'll check it with the newer > version next week. However, I tend to use the 4.0.x because at least for > the ARM it generates smaller code from the same source than the newer > versions when optimising with -Os. Still, there's not much help people can give you with old versions. If you have any test cases where 4.0.2 gives smaller code with -Os than a 4.4 snapshot, please, file them in bugzilla. -- Daniel Jacobowitz CodeSourcery
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
On Wed, Feb 04, 2009 at 05:04:10PM -0800, Le-Chun Wu wrote: > >> -fplugin=/path/to/plugin.so;arg1=value;arg2=value;... > >> > > I am not sure if it is GCC's responsibility to understand key-value > (or any other types of) arguments to plugins. I think GCC should > simply take a string (which, of course, can be something like > "arg1=value arg2=value") and pass it (unparsed) to the plugin. It is > plugin's job to parse/process the given arguments (whatever way it > likes). Please let GCC do this, so that argument parsing can be (A) centralized, and (B) standardized. Otherwise the right way to pass arguments will end up different for every plugin. -- Daniel Jacobowitz CodeSourcery
Re: Serious code generation/optimisation bug (I think)
On Tue, Jan 27, 2009 at 06:52:18PM +1100, zol...@bendor.com.au wrote:
> // Debug( tst->value );
>
>if ( ! tst ) {
>ptr->next = (void *) 0;
>break;
>}
This optimization comes up on the list frequently. Do folks think a
corresponding warning would be a win? "warning: ignored NULL check
because pointer has already been dereferenced"?
--
Daniel Jacobowitz
CodeSourcery
Re: marking ppc440 tests as unsupported
On Mon, Jan 12, 2009 at 10:10:18AM -0600, Joel Sherrill wrote: > The unfortunate thing is that I think these > tests are really ensuring that MASK_DLMZB is > used as expected. If this is right, then > shouldn't there be a cpp predefine similar > to __NO_LWSYNC__ for dlmzb? And the tests use > that rather than testing for a specific CPU model? This doesn't answer what you should do now, but I can explain the precedent: the only reason there is a predefine for 405 is so that the atomicity routines in libstdc++ know to avoid lwsync. -- Daniel Jacobowitz CodeSourcery
Re: Fwd: Mips, -fpie and TLS management
On Mon, Nov 24, 2008 at 03:27:55PM +0100, Joel Porquet wrote: > >> And the related reloc symbols are: > >> 5ffe14b0 0026 R_MIPS_TLS_DTPMOD > >> 5ffe14b8 0026 R_MIPS_TLS_DTPMOD > > Still, is R_MIPS_TLS_DTPMOD a correct symbol ? > In the document you wrote about NPTL for mips > (http://www.linux-mips.org/wiki/NPTL), there's no such relocation > symbol: just R_MIPS_TLS_DTPMOD32 and R_MIPS_TLS_DTPMOD64. There's only DTPMOD32 and DTPMOD64 relocations defined in binutils. I'm not sure why it's printing that - maybe it's just truncated? Try -W. > Indeed, the GOT seems to be already filled with the right offset, you > were right. However the values are just a bit weird: > > 5ffe14b0: nop > 5ffe14b4: 8004sdc3$31,-32764(ra) > 5ffe14b8: nop > 5ffe14bc: 8000sdc3$31,-32768(ra) > > We can see that the offsets are prefixed by 8. Why is that? The offsets are biased; that's -32768, the lowest 16-bit signed offset. The bias is used to expand the addressable range of the thread pointer. Glad I could help! -- Daniel Jacobowitz CodeSourcery
Re: Fwd: Mips, -fpie and TLS management
On Fri, Nov 21, 2008 at 06:51:26PM +0100, Joel Porquet wrote:
> Nevertheless, how could i have a coherent compilation concerning the
> TLS management, if my executable needs dynamically libraries ? Aren't
> the exec and dynamic models completely incompatible in the same
> "whole" (eg one executable and shared libraries) ?
No, there's nothing wrong with this. You can even use multiple models
in the same executable for the same symbol. The linker will take care
of everything necessary.
For instance, the executable's TLS block is at a fixed offset from the
DTV pointer.
If you're seeing a bug, then please give a test case that fails at
runtime - there can always be bugs. But there is nothing wrong
with the tests you've posted so far that I can see.
> And the related reloc symbols are:
> 5ffe14b0 0026 R_MIPS_TLS_DTPMOD
> 5ffe14b8 0026 R_MIPS_TLS_DTPMOD
>
> You can see that both the store instruction have not precalculated
> offset but a 0 offset. It means that for accessing the two different
> variables, the only way is to provide two different values for
> R_MIPS_TLS_DTPMOD, which is incoherent.
Your conclusion does not follow from the evidence. __tls_get_addr
takes a pointer to a {module, offset} pair. There's no dynamic
relocation for the offset, but that's OK - the linker has calculated
it at link time. Take a look at the contents of the GOT starting
at 0x5ffe14b0 for four words. The second and fourth words will be
the offsets. This is a global dynamic sequence, since it passes
non-zero offsets to __tls_get_addr.
--
Daniel Jacobowitz
CodeSourcery
Re: Fwd: Mips, -fpie and TLS management
On Fri, Nov 21, 2008 at 11:19:32AM +0100, Joel Porquet wrote: > I agree that wether the code is pic or not and the tls model are quite > independent. > According to the manual, the default policy for TLS is affected by the > pic model though: > > -ftls-model=model > ... > The default without -fpic is "initial-exec"; with -fpic the > default is "global-dynamic". Which is exactly what happens. Using -fpie does not cound as "with -fpic". > > It's a difference between linking an executable versus linking a > > shared library; this is one of the distinctions between -fpie and > > -fpic. > > Yes for the linking stage but for the object compilation, -fpie should > be almost the same. No, it shouldn't. `-fpie' `-fPIE' These options are similar to `-fpic' and `-fPIC', but generated position independent code can be only linked into executables. This is one of the reasons that the generated code can only be used in executables. > It could be but firstly when the global-dynamic model is specified one > should expect to get global-dynamic and not local-dynamic, and anyway > it is not local-dynamic. I don't remember what the deal is with the command line option, but I've run into that before. The answer was, I think, that it is behaving as designed - but not intuitively. As for the model, you're right, it's not local dynamic. It's global dynamic linked into an executable. The linker has performed some optimization on your output file because it can determine the symbol binding at static link time. There's no need for a dynamic relocation to calculate DTPREL when it's a link-time constant. This is all very interesting, but you didn't answer my question: is this causing some problem, or just confusing? These are all intended optimizations. -- Daniel Jacobowitz CodeSourcery
Re: Mips, -fpie and TLS management
On Thu, Nov 20, 2008 at 05:28:16PM +0100, Joel Porquet wrote: > Gcc is using local-exec tls model instead of global-dynamic. The > option -fpie is supposed to act as -fpic though (dixit the manual). > Here is the first problem... Could you explain the problem with this? The choice of local-exec vs global-dynamic does not affect whether code is position independent. It's a difference between linking an executable versus linking a shared library; this is one of the distinctions between -fpie and -fpic. > But then readelf tells me: > > Relocation section '.rel.dyn' at offset 0x3d4 contains 2 entries: > Offset InfoTypeSym.Value Sym. Name > R_MIPS_NONE > 5ffe1460 0026 R_MIPS_TLS_DTPMOD > > The symbol name is missing and most of all, the offset type is missing > too: there should be a R_MIPS_TLS_DTPREL type with the > R_MIPS_TLS_DTPMOD, since for each tls variable in global dynamic > model, tls_get_addr must receive the module index and the offset. Here > is the second problem... That's because this is the local dynamic model. -- Daniel Jacobowitz CodeSourcery
Re: Apple, iPhone SDK NDA and GPLv3
On Fri, Oct 31, 2008 at 01:02:18PM -0400, Jack Howarth wrote: >Can anyone explain if the recent change in Apple dropping their > NDA will have any impact on the GPLv3 issue with Apple and FSF? Please discuss this on some more appropriate forum, not here. -- Daniel Jacobowitz CodeSourcery
Re: A question about DCE
On Wed, Oct 15, 2008 at 11:17:18AM +0200, Revital1 Eres wrote: > > Hello, > > I want to emit the following SPU insn: > emit_insn (gen_iorti3 (r77, tmp, GEN_INT(0))); > > r77 is defined as 'fixed register' which is a register that the register > allocator can not use. (triggers by SPU option -mfixed-range) > r77 is used to pass information to some other routine at run-time (the > next instruction is branch to this routine; the routine does not exist > at the compile time of the function which contains this instruction). > > The problem is that r77 is not used in it's function after this instruction > and thus DCE deletes it. Don't focus on DCE. That's not the problem; the fact that there's no visible dependence is the problem. Can you make the next instruction have a use for r77 explicitly (CALL_INSN_FUNCTION_USAGE)? -- Daniel Jacobowitz CodeSourcery
Re: install path in libgcc Makefile.in
On Sun, Oct 12, 2008 at 03:13:47AM +0800, Zhang Le wrote: > On 00:06 Sat 11 Oct , Daniel Jacobowitz wrote: > > > If this is ok, I will post a little patch. > > > > That sounds fine, but the whole process is trouble. > > Would you explain why it is trouble? Thanks! For instance, libgcc and libstdc++ rely on builtins as soon as they are added to the compiler. If your other compiler is older, they won't even build or will call undefined functions. > The patch is included. If you've tested it, send it to gcc-patches. -- Daniel Jacobowitz CodeSourcery
Re: install path in libgcc Makefile.in
On Sat, Oct 11, 2008 at 03:17:31AM +0800, Zhang Le wrote: > Hi, > > Another problem when cross building the native mips compiler. > I.e. build=x86, host=target=mipsel > I have done some search, but haven't found any related discussion. > > The install path of libgcc contains gcc version. > Currently in libgcc/Makefile.in, gcc version is get like this: > version := $(shell $(CC) -dumpversion) > > This will lead to a problem that I have only experienced when cross building > the native compiler. The problem is that crtbegin.o/crtend.o/etc. will be > installed into old gcc's path, overwrite existing ones. New gcc will have no > crtbegin.o... You are building libgcc at this point. $(CC) is the target compiler; if it is not the same version as the one you've just built in gcc/, then the resulting libgcc or libstdc++ may not work. The first step in cross building a native compiler like this is to build a cross compiler of the right version. > If this is ok, I will post a little patch. That sounds fine, but the whole process is trouble. -- Daniel Jacobowitz CodeSourcery
Re: P.S. to: plungins and licensing
On Mon, Sep 29, 2008 at 03:10:28PM +0100, Joern Rennecke wrote: > To give it a bit more legal bite There are no lawyers on this list (that I'm aware of). If you want to discuss this, please contact the FSF or SC directly instead. It does no good here. -- Daniel Jacobowitz CodeSourcery
Re: C/C++ FEs: Do we really need three char_type_nodes?
On Sat, Sep 20, 2008 at 11:46:48AM -0400, Diego Novillo wrote: > This is not really possible because when lto1 runs, it needs to have a > unique version of char_type_node and the multiple .o files will > potentially have different versions of it. In essence, char_type_node > needs not exist in GIMPLE or we have to standardize it to either > signed_char_type_node or unsigned_char_type_node. > > So, when we go into GIMPLE, all the instances of char_type_node need > to be converted into unsigned_char_type_node or signed_char_type_node. > This way different CUs can have different notions of char signedness > explicitly outlined in the IL. This seems like it would be fraught with pitfalls; maybe it would be easier to have the streamed char_type_node indicate its signedness? - Has the story for debug info been figured out yet? Char is not signed char to GDB. - What about binding to templates or overloaded functions? -- Daniel Jacobowitz CodeSourcery
Re: no symbol in current context problem when debug the program in gdb
On Sat, Sep 20, 2008 at 03:55:00PM +0200, Kai Henningsen wrote: > Isn't this a case of the stuff that the > var-tracking-assignments-branch > (http://gcc.gnu.org/wiki/Var_Tracking_Assignments) tries to fix? No, it was specific to cloned functions. Some cgraph bug, I don't remember the PR. -- Daniel Jacobowitz CodeSourcery
Re: [PATCH] Use lwsync in PowerPC sync_* builtins
On Thu, Sep 04, 2008 at 09:04:30AM -0400, David Edelsohn wrote: > That is unfortunate, but it is a long-term, known problem with PSIM. Someone > maintaining PSIM needs to update it. Also unfortunately, there is no one maintaining PSIM. It's shipped with GDB, but I consider that only a convenience for the implementation of 'target sim'; it's really an independent project. -- Daniel Jacobowitz CodeSourcery
Re: QUERY : ARM inline code in Thumb file?
On Wed, Aug 27, 2008 at 10:31:24PM +0530, Aaron P. D'Souza wrote: > i have a C file that has been compiled for Thumb mode. in it, i am > using ARM inline assembly code. apparently, GCC issues no error > message but forcibly converts the ARM code into Thumb code. It's just being disassembled wrong; try using a newer version of objdump. But if you want to change modes, you're going to need a 'bx pc'. > i think that GCC requires an entire file to be in either Thumb mode > or ARM mode, but i am not sure. is that true? It has to be effectively true. Leave the file in the same mode it was in when the asm was entered. -- Daniel Jacobowitz CodeSourcery
Re: obvious race condition in darwin/netbsd __enable_execute_stack due to caching pagesize/mask
On Wed, Aug 27, 2008 at 02:45:25PM +0100, Dave Korn wrote: > Jay wrote on 27 August 2008 09:55: > > > Yeah that's probably ok. > > Volatile is enough to force the ordering? > > Absolutely; it's a defined part of the standard that all volatile > side-effects must complete in-order. GCC will not move code past a volatile > operation. It's still not sufficient without a memory barrier. -- Daniel Jacobowitz CodeSourcery
Re: Problem reading corefiles on ARM
On Wed, Aug 06, 2008 at 05:42:48PM +0200, Mark Kettenis wrote: > GCC should really not do this. People are almost guaranteed to want > to be able to see a backtrace from abort(3). Yes, it's come up for discussion several times... I don't like the current behavior either. The current behavior was added many years ago for an unspecified application :-( /* Decide if the current function is volatile. Such functions never return, and many memory cycles can be saved by not storing register values that will never be needed again. This optimization was added to speed up context switching in a kernel application. */ IMO that shouldn't be written in C, then... -- Daniel Jacobowitz CodeSourcery
Re: frameworklet to assess the quality of debug information
On Mon, Jul 28, 2008 at 06:39:40PM -0300, Alexandre Oliva wrote: > Here's my first cut at trying to tell how well or how bad we perform > in terms of debug info, that can be dropped into the GCC run-time test > infrastructure and used by means of #include in new tests that add > GUALCHK* annotations (or with separate compilation, if some stuff is > moved into a separate header). FWIW, I think this is a good approach. -- Daniel Jacobowitz CodeSourcery
Re: gcc will become the best optimizing x86 compiler
On Mon, Jul 28, 2008 at 12:56:57PM +0200, Agner Fog wrote: > >2008/7/26 Agner Fog <[EMAIL PROTECTED]>: > >>I have libc version 2.7. Can't find version 2.8 > >It's in Fedora 9, I have no idea why the source isn't directly > >available from the glibc homepage. > > 2.8 is not an official final release yet. That's incorrect; the glibc maintainers just don't care much for tarballs. You can find the tag in CVS from several months ago. -- Daniel Jacobowitz CodeSourcery
Re: RFC: Adding non-PIC executable support to MIPS
On Thu, Jul 24, 2008 at 09:24:48PM +0100, Richard Sandiford wrote: > > - I've dropped support for a non-fixed $gp. This is a handy > > optimization, but it was getting in the way and it was the part of the > > GCC patch Richard had the most comments on. I can resubmit it after > > everything else is merged. > > That's a shame. It was also the bit I liked best ;) What went wrong? > > (My comments were only minor.) Nothing big: but it made up the bulk of our GCC patch, and I was rebasing on top of yours. We had a lot of trouble getting that bit to work, so I took the conservative path and dropped it. Don't worry - I definitely will return to this as soon as the remaining patches are merged; I liked it too. Originally, we were also going to make small data work with non-PIC abicalls. I'd like to discuss that with you at some later date too. We ran into a lot of trouble combining small data with a non-fixed $gp; I believe it was because reload may introduce small data loads very late. I'd have to try it again before I had anything more sensible to say, though. > Sorry for the bugs, and thanks for fixing them. I'll try to have > a look at the patches over the weekend. No problem, and thank you for looking at them - and for your patches; I'm really pretty happy with the combined work. -- Daniel Jacobowitz CodeSourcery
Re: RFC: Adding non-PIC executable support to MIPS
On Thu, Jul 24, 2008 at 12:16:20PM -0400, Daniel Jacobowitz wrote: > I have attached Let's all pretend I attached this glibc patch, instead of the one in my previous message, please. -- Daniel Jacobowitz CodeSourcery 2008-07-24 Mark Shinwell <[EMAIL PROTECTED]> Daniel Jacobowitz <[EMAIL PROTECTED]> Richard Sandiford <[EMAIL PROTECTED]> * sysdeps/mips/dl-lookup.c: New. * sysdeps/mips/do-lookup.h: New. * sysdeps/mips/dl-machine.h (ELF_MACHINE_NO_PLT): Remove definition. (ELF_MACHINE_JMP_SLOT): Alter definition and update comment. (elf_machine_type_class): Likewise. (ELF_MACHINE_PLT_REL): Define. (elf_machine_fixup_plt): New. (elf_machine_plt_value): New. (elf_machine_reloc): Handle jump slot and copy relocations. (elf_machine_lazy_rel): Point relocation place at PLT if required. (RESOLVE_GOTSYM): Take a relocation type argument. (elf_machine_got_rel): Bind lazy stubs directly to their target if !lazy. Skip lazy binding for PLT symbols. (elf_machine_runtime_setup): Fill in .got.plt header. * sysdeps/mips/dl-trampoline.c (IFNEWABI): New macro. (_dl_runtime_pltresolve): New. * sysdeps/mips/bits/linkmap.h: New file. * sysdeps/mips/tls-macros.h: Load $gp as required. Merge 32-bit and 64-bit versions. * sysdeps/unix/sysv/linux/mips/mips32/sysdep.h (SYSCALL_ERROR_LABEL): Delete definition. * sysdeps/unix/sysv/linux/mips/nptl/sysdep-cancel.h (PSEUDO_CPLOAD, PSEUDO_ERRJMP, PSEUDO_SAVEGP, PSEUDO_LOADGP): Define. (PSEUDO): Use them. Move outside __PIC__. (PSEUDO_JMP): New. (CENABLE, CDISABLE): Use it. Index: sysdeps/unix/sysv/linux/mips/mips32/sysdep.h === --- sysdeps/unix/sysv/linux/mips/mips32/sysdep.h (revision 213009) +++ sysdeps/unix/sysv/linux/mips/mips32/sysdep.h (working copy) @@ -35,15 +35,7 @@ # define SYS_ify(syscall_name) __NR_/**/syscall_name #endif -#ifdef __ASSEMBLER__ - -/* We don't want the label for the error handler to be visible in the symbol - table when we define it here. */ -#ifdef __PIC__ -# define SYSCALL_ERROR_LABEL 99b -#endif - -#else /* ! __ASSEMBLER__ */ +#ifndef __ASSEMBLER__ /* Define a macro which expands into the inline wrapper code for a system call. */ Index: sysdeps/unix/sysv/linux/mips/nptl/sysdep-cancel.h === --- sysdeps/unix/sysv/linux/mips/nptl/sysdep-cancel.h (revision 213009) +++ sysdeps/unix/sysv/linux/mips/nptl/sysdep-cancel.h (working copy) @@ -25,28 +25,38 @@ #if !defined NOT_IN_libc || defined IS_IN_libpthread || defined IS_IN_librt -#ifdef __PIC__ +# ifdef __PIC__ +# define PSEUDO_CPLOAD .cpload t9; +# define PSEUDO_ERRJMP la t9, __syscall_error; jr t9; +# define PSEUDO_SAVEGP sw gp, 32(sp); cfi_rel_offset (gp, 32); +# define PSEUDO_LOADGP lw gp, 32(sp); +# else +# define PSEUDO_CPLOAD +# define PSEUDO_ERRJMP j __syscall_error; +# define PSEUDO_SAVEGP +# define PSEUDO_LOADGP +# endif + # undef PSEUDO # define PSEUDO(name, syscall_name, args) \ .align 2; \ L(pseudo_start): \ cfi_startproc; \ - 99: la t9,__syscall_error; \ - jr t9; \ + 99: PSEUDO_ERRJMP \ .type __##syscall_name##_nocancel, @function; \ .globl __##syscall_name##_nocancel; \ __##syscall_name##_nocancel: \ .set noreorder; \ -.cpload t9; \ +PSEUDO_CPLOAD \ li v0, SYS_ify(syscall_name); \ syscall; \ .set reorder; \ -bne a3, zero, SYSCALL_ERROR_LABEL; \ +bne a3, zero, 99b; \ ret; \ .size __##syscall_name##_nocancel,.-__##syscall_name##_nocancel; \ ENTRY (name) \ .set noreorder; \ -.cpload t9; \ +PSEUDO_CPLOAD \ .set reorder; \ SINGLE_THREAD_P(v1); \ bne zero, v1, L(pseudo_cancel); \ @@ -54,17 +64,16 @@ li v0, SYS_ify(syscall_name); \ syscall; \ .set reorder; \ -bne a3, zero, SYSCALL_ERROR_LABEL; \ +bne a3, zero, 99b; \ ret; \ L(pseudo_cancel): \ SAVESTK_##args; \ sw ra, 28(sp); \ cfi_rel_offset (ra, 28); \ -sw gp, 32(sp); \ -cfi_rel_offset (gp, 32); \ +PSEUDO_SAVEGP \ PUSHARGS_##args; /* save syscall args */ \ CENABLE; \ -lw gp, 32(sp); \ +PSEUDO_LOADGP \ sw v0, 44(sp); /* save mask */ \ POPARGS_##args; /* restore syscall args */ \ .set noreorder; \ @@ -75,12 +84,12 @@ sw a3, 40(sp); /* save syscall error
Re: Bootstrap failures on ToT, changes with no ChangeLog entry?
On Thu, Jul 24, 2008 at 06:48:56PM +0200, Andreas Schwab wrote: > $ svn diff -c138078 > svn: Unable to find repository location for '' in revision 138077 > $ svn diff -c138077 > svn: The location for '' for revision 138077 does not exist in the repository > or refers to an unrelated object > > Apparently the repository has some issues with revision 138077. Yes, this has happened before: that's what it looks like in svn when someone deletes and restores trunk. Fortunately it doesn't break much else; and it was restored correctly. r138077 | meissner | 2008-07-23 07:01:39 -0400 (Wed, 23 Jul 2008) | 1 line Changed paths: D /trunk Delete working copy of function-specific to be replaced with a copy of the mainline after it was checked in r138078 | meissner | 2008-07-23 07:06:42 -0400 (Wed, 23 Jul 2008) | 1 line Changed paths: A /trunk (from /trunk:138076) undo 138077 -- Daniel Jacobowitz CodeSourcery
Re: [whopr] Design/implementation alternatives for the driver and WPA
On Thu, Jul 03, 2008 at 09:48:11PM -0700, Ian Lance Taylor wrote: > * The linker does normally copy unrecognized sections with the > SHF_ALLOC bit clear to the output file. It doesn't allocate address > space for them, but it does copy them. I think this follows the ELF > ABI. I don't know of any generic way to direct the linker to not > copy sections to the output file. Didn't someone say on the gABI list recently that they had a bit for this? Ah, H. J. proposed it and Rod Evans from Sun said they already had an SHF_EXCLUDE: http://groups.google.com/group/generic-abi/browse_thread/thread/5cf669951cb2eef1 -- Daniel Jacobowitz CodeSourcery
Re: mklibs on mips broken by gcc-4.3.x
On Fri, Jul 04, 2008 at 02:42:40PM +0100, Chris Steel wrote: > __gnu_local_gp seems to be a mips specific symbol in gcc, which is > apparently used to provide -mno-shared support to gcc. The > implementation of this symbol is in gcc-4.x.x/gcc/config/mips/mips.c > and the only thing which seems to have changed between gcc-4.2.4 and > gcc-4.3.1 is the parameters passed to emit_insn, and the addition of a > LOADGP_RTP option. Having run into this recently, I know what else changed: a configure-time check was added to use -mno-shared by default. Building with gcc 4.2 and -mno-shared will probably show the same problem. > Does anyone have any idea how this has broken, and how to work around > / fix this in gcc or mklibs? You'll have to make mklibs ignore this symbol; the linker defines it. -- Daniel Jacobowitz CodeSourcery
Re: RFC: Adding non-PIC executable support to MIPS
On Wed, Jul 02, 2008 at 08:55:54PM +0100, Richard Sandiford wrote: > The size of the header and first 0x1 stubs would be the same. > I think it would also preserve the resolver interface while removing > the need for the extra-large .plts. The only incompatibility I can > see would be that objdump on older executables would not get the > [EMAIL PROTECTED] symbols right for large indices. > > OTOH, perhaps you could argue that the extra complication of the > two PLT entries doesn't count for much given that the code is > already written. It's just an idea. Your version looks fine to me, it's ABI-preserving, the PLT entries still work for MIPS I and still have the same runtime cost when not resolving. I like it - thanks! I'm not worried about making people upgrade objdump, either. -- Daniel Jacobowitz CodeSourcery
Re: RFC: Adding non-PIC executable support to MIPS
On Tue, Jul 01, 2008 at 09:43:30PM +0100, Richard Sandiford wrote: > I suppose I still support the trade-off between the 5-insn MIPS I stubs > (with extra-long variation for large PLT indices) and the absolute > .got.plt address I used. And I still think it's shame we're treating > STO_MIPS_PLT and STO_MIPS16 as separate; we then only have 1 bit of > st_other unclaimed. I'm undecided about the MIPS I issue, but I completely agree about STO_MIPS16/STO_MIPS_PLT. I wish we'd thought of that too. At least our implementation didn't have STO_MIPS_PIC; so there's one bit left, and assuming we add support for ld -r (likely) we can do it your way. For the final merged versions of these patches, even if they implement "our" version, I hope to draw heavily on your work. It's always high quality and the GOT cleanups in particular look very useful. > TBH, the close relationship between CodeSourcery and MTI > make it difficult for a non-Sourcerer and non-MTI employee > to continue to be a MIPS maintainer. I won't be in-the-know > about this sort of thing. > > I've been thinking about that a lot recently, since I heard about > your implementation. I kind-of guessed it had been agreed with MTI > beforehand (although I hadn't realised MTI themselves had written > the specification). Having thought it over, I think it would be best > if I stand down as a MIPS maintainer and if someone with the appropriate > commercial connections is appointed instead. I'd recommend any > combination of yourself, Adam Nemet and David Daney (subject to > said people being willing, of course). I'm sorry you feel this way. I believe strongly that corporate affiliation is not a useful indicator for maintainership; the system we have set up here relies more on individual knowledge and experience than affiliation. We could have done more to keep everyone informed of our progress; I could write an essay on why we didn't, but I'd rather not. We're talking internally about how to avoid this unfortunate coincidence in the future. Anyway, there's plenty of blame to go around. I think you're doing an excellent job as a GCC maintainer, and so does everyone I spoke to about this at CS. If you no longer have the time or incentive to do it, I won't argue with you about stepping down, but please don't because of this incident. [In any case, I'd decline; I'm trying to shed some of my existing maintenance responsibilities so that I can spend more time on the ones I care most about. Anyone else want to be binutils release manager?] -- Daniel Jacobowitz CodeSourcery
Re: RFC: Adding non-PIC executable support to MIPS
On Mon, Jun 30, 2008 at 01:59:19PM -0700, David VomLehn wrote: > This sounds like really good stuff and, on first reading, it all seems to > make sense to me. My only real concern is documentation of these changes. FWIW, I'll be posting our version of this project shortly, and it includes an ABI supplement. Supplemental to a somewhat hypothetical document, but there you go... -- Daniel Jacobowitz CodeSourcery
Re: trivial error in *.texi files.
On Mon, Jun 30, 2008 at 11:09:28PM +0200, Basile STARYNKEVITCH wrote: >> /usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:146: `Reference on MELT' >> has no Up field (perhaps incorrect sectioning?). You have to add it to the menu manually. Look at any of the other included files for an example; the menu should be before the @include somewhere. -- Daniel Jacobowitz CodeSourcery
Re: gcc-in-cxx: Garbage Collecting STL Containers
On Wed, Jun 25, 2008 at 08:35:41AM -0600, Tom Tromey wrote: > I think most of the needed changes will be in gengtype. If you aren't > familiar with what this does, read gcc/doc/gty.texi. Also - I may regret saying this but - doesn't gengtype have a simplistic C parser in it? How upset is it likely to get on C++ input? -- Daniel Jacobowitz CodeSourcery
Re: CFA expression failure
On Tue, Jun 24, 2008 at 08:40:18PM -0700, H.J. Lu wrote: > I think the problem is in uw_update_context_1. REG_SAVED_EXP > and REG_SAVED_VAL_EXP may use other registers as shown above: > >DW_CFA_expression: r6 (esi) (DW_OP_breg5: -8) > > They should be handle last. I am testing this patch. Does it > make senses? I think that rather than delaying such expressions, you need to evaluate into a temporary context. DW_OP_breg5 means the current frame's %ebp; DW_CFA_expression: r5 describes the location of the previous frame's %ebp. They're different registers. Otherwise this is going to be too order-sensitive. -- Daniel Jacobowitz CodeSourcery
