Re: Question concerning shared libraries in non-standard locations

[Paul Hilfinger]

> > 2. Remember to include the appropriate -W,l-R option or whatever in
> >[each] and every compilation.
> 
> I don't think it's a good idea to compile in rpaths to non-standard
> (user-specific) directories by default.  This can lead to trapdoor
> rpaths and generally makes the binaries less portable (not more).

The security threat you refer to here is a bit obscure to me, but I don't
really think it's entirely germane.  Consider these uses of GCC:

  (a) compiling things for local use
  (b) compiling things to export

When one is compiling for export, one expects to have to take special
measures to insure portability, but is that really the common case?
My suspicion is that (a) is the common case (it certainly is for me),
and given that, the behavior of the default configuration with a
non-standard --prefix---producing executables that won't run without
special measures---seems rather bizarre.  Remember that in case (a), we 
expect the shared libraries to be present (in their non-standard locations) 
at execution time.

I guess that I'm simply suggesting that it might be nice if the sort
of modification suggested by Albert Chin's response to my question
could be installed automatically under control of a configuration
option (e.g.), or as a result of the configuration script's detecting
a non-standard prefix.  (Well, actually, I think his patch has to
modified for recent versions; doesn't 4.x compile them into the source
files?).

Paul Hilfinger

RE: Matching of non-standard instructions

[Roland Persson]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Rask Ingemann Lambertsen
> Sent: Monday, June 26, 2006 19:25
> To: Roland Persson
> Cc: gcc@gcc.gnu.org
> Subject: Re: Matching of non-standard instructions
> 
> 
> In a similiar case, only with 8 and 16 bits, respectively, I'm having
> success with this pattern, which you could use as a starting point:
> 
> (define_insn "*zero_extendqihi_addhi3"
>   [(set (match_operand:HI 0 "nonimmediate_operand" "=q,m")
> (plus:HI (zero_extend:HI (match_operand:QI 1 "general_operand"
> "qmi,qi"))
>  (match_operand:HI 2 "nonimmediate_operand" "0,0")))
>(clobber (reg:CC CC_REG))]
>""
> ...
> )
> 
> (It would have been a help to us to see examples of insn patterns you have
> tried unsuccessfully.)
> 
> 

I've been trying patterns like this one:

(define_insn "*pip_add_di_sesi"
  [(set (match_operand:DI 0 "register_operand" "=r")
(plus:DI (match_operand:DI 1 "register_operand" "r")
 (sign_extend:DI (match_operand:SI "register_operand"
"r"]
...
)


> In addition to the instruction pattern, you may have to adjust the RTX
> cost calculation (TARGET_RTX_COSTS) so that the optimizers know if this
> instruction is cheaper than two individual instructions. This is not
> difficult as such, but can be a lot of work if you want to do this for all
> instruction patterns and get reasonably accurate costs.
> 

I haven't looked at this, so I guess it will be my next step. 

Thanks for the help!

Roland

Re: Why does __float80 depend on -mmmx/-msse?

[Joseph S. Myers]

On Mon, 26 Jun 2006, H. J. Lu wrote:

> I have no strong opinion on the support for __float80. But the current
> behavior seems odd to me. Also, we have incomplete support for
> __float128. There is no runtime support for __float128 at all on
> x86-64.

Feel free to add such support using soft-fp as described at the bottom of 
.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Why does __float80 depend on -mmmx/-msse?

[Jan Hubicka]

> > > On the other hand, as far as I can
> > > see, __float80 is undocumented and unused for the i386.  Why does it
> > > exist?
> > 
> > Jan added it with __float128 also:
> > 2003-10-30  Jan Hubicka  <[EMAIL PROTECTED]>
> > 
> >  (ix86_init_mmx_sse_builtins): Add __float80, __float128.
> > 
> > I think it was added for x86_64 ABI support which defines them
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2003-10/msg02473.html
> 
> Are you saying that the x86_64 ABI calls for __float80 to be defined?
> I can't find any reference to __float80 which is not related to gcc or
> ia64.

__float128 is defined as optional by x86_64 ABI, the main reason was to
stay mostly in sync with IA-64 to make porting of applications in
between both platforms easier.  When __float80 and __float128 was added
to IA-64 port, I enabled them on x86-64 as well.

>From this POV it seems to make sense to support both on x86-64 too, but
I could live with oposite sollution too.

The conditoinal H. J. quoted is definitly supposed to make "__float80"
equivalent of "long double" on 32bit compiler with 80bit long double and
new type otherwise. I don't see how it depends on MMX/SSE, but if
current logic is broken, would be possible to see the testcase?

Honza
> 
> In any case that does not give any explanation for why it should only
> be defined for MMX or SSE.
> 
> I don't object to defining __float80 for i386.  I agree with H.J. that
> if we define it, we should define it unconditionally.  And I also say
> that if we define it, we should document it, or at least find some
> other document which mentions it.
> 
> Ian

why are we not using const?

[Manuel López-Ibáñez]

Dear all,

from comments in the #gcc irc channel, I understood that it is not
advisable for gcc patches to use the const qualifier in function
prototypes. I would like to understand why. Apart from its main
purpose, I believed that the use of 'const' helps the compiler to
optimise the code. Of course, I must be wrong, or the gains must be
very small compared with the reasons for not using 'const', which I
ignore.

Again, I am not proposing using 'const' or changing all the code. I am
just asking the reasons for not using 'const' in order to learn more.

Thanks in advance,

Manuel.
http://gcc.gnu.org/wiki/Wcoercion

Re: gcc port based on MIPS

[kernel coder]

thanks,There is a macro LEGITIMIZE_RELOAD_ADDRESS.Accroding to gcc internals
"It is a C compound statement that attempts to replace x, which is an
address that needs
reloading, with a valid memory address for an operand of mode mode.
win will be a
C statement label elsewhere in the code".

I'm not been able to comprehend this macro.The explaination is saying
that it tries to replace the address with some suitable address.But
when will such a situation occur,any example will  be helpful.And what
is reloading pass.According to gcc internals in this pass
pseudo-registers  are replaced with hard registers and some are
assigned stack slots.Is there anything else which happens in this
phase.Is above mentioned macro also has something to do with pass.

thanks,
shahzad

On 20 Jun 2006 00:40:07 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:

"kernel coder" <[EMAIL PROTECTED]> writes:

> > ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
> > `' for `mode' attribute
> > ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
> > `' for `mode' attribute
>
> Sorry,these errors were just my mistake.I mistakenly comminted out the
> following line in ABC.md file
>
> (define_mode_attr UNITMODE [(SF "SF") (DF "DF")])
>   (V2SF "SF")])
>
> That caused the above error to be generated.Now ABC.md file has passed
> through the compilation process successfully .
>
> But the V2SF error still persistes.

Well, this works for MIPS (though I suppose you might want to check
that), so if you just copy the MIPS files, then this should work for
your target.  So if it doesn't work, then you either didn't just copy
the files, or you didn't update config.gcc correctly.  We can't really
help you with this.

> Would you please tell me that for what the binutils like gas ,ld are
> called.I know that gcc uses internally the gas and ld to produce final
> output.
> But during compilation of gcc ,what role these executables play.

They are used to build libgcc, the gcc support library.

Ian

Re: why are we not using const?

[Manuel López-Ibáñez]

On 27/06/06, Andrew Haley <[EMAIL PROTECTED]> wrote:

Well, const functions are nonstandard, and gcc itself is written in
Standard C so they can't be used.  But As for const args, I can't see
any good reason not to use them, and there are 400 uses in gcc.


I meant const arguments, sorry for the confusion.  What about: 'const'
applied to trees, for example:

void foo(const tree type, const tree expr)

Perhaps there is some drawback there?

Re: why are we not using const?

[Gabriel Dos Reis]

"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:

| Dear all,
| 
| from comments in the #gcc irc channel, I understood that it is not
| advisable for gcc patches to use the const qualifier in function
| prototypes. I would like to understand why. Apart from its main
| purpose, I believed that the use of 'const' helps the compiler to
| optimise the code. 

We we do have numbers that support that claim for real programs, then
we have a bug in the optimizers :-)

-- Gaby

Re: why are we not using const?

[Andrew Pinski]

On Jun 27, 2006, at 6:29 AM, Manuel López-Ibáñez wrote:


On 27/06/06, Andrew Haley <[EMAIL PROTECTED]> wrote:

Well, const functions are nonstandard, and gcc itself is written in
Standard C so they can't be used.  But As for const args, I can't see
any good reason not to use them, and there are 400 uses in gcc.


I meant const arguments, sorry for the confusion.  What about: 'const'
applied to trees, for example:

void foo(const tree type, const tree expr)

Perhaps there is some drawback there?


They are used, just not much.

More in the C front-end than other places:
c-decl.c:push_parm_decl (const struct c_parm *parm)

cfgloop.c:num_loop_branches (const struct loop *loop)
cfgloop.c:loop_latch_edge (const struct loop *loop)

varasm.c:const_hash_1 (const tree exp)
varasm.c:compare_constant (const tree t1, const tree t2)
etc.

-- Pinski

Re: why are we not using const?

[Andrew Pinski]

On Jun 27, 2006, at 7:58 AM, Gabriel Dos Reis wrote:


We we do have numbers that support that claim for real programs, then
we have a bug in the optimizers :-)


Huh?

"Stupid" example where a const argument can change:
tree a;
int f(const tree b)
{
  TREE_CODE(a) = TREE_CODE (b) + 1;
  return TREE_CODE (b);
}

-- Pinski

Re: Matching of non-standard instructions

['Rask Ingemann Lambertsen']

On Tue, Jun 27, 2006 at 11:53:52AM +0200, Roland Persson wrote:

> I've been trying patterns like this one:
> 
> (define_insn "*pip_add_di_sesi"
>   [(set (match_operand:DI 0 "register_operand" "=r")
> (plus:DI (match_operand:DI 1 "register_operand" "r")
>  (sign_extend:DI (match_operand:SI "register_operand"
> "r"]
> ...
> )

My first bet would be to place the sign_extend operand first of the two
operands to plus.

Also, the output from -fdump-rtl-combine will tell you if combine is
rejecting the pattern because the cost is too high.

-- 
Rask Ingemann Lambertsen

Re: why are we not using const?

[Theodore Papadopoulo]

On Tue, 2006-06-27 at 13:51 +0100, Manuel López-Ibáñez wrote:
> from comments in the #gcc irc channel, I understood that it is not
> advisable for gcc patches to use the const qualifier in function
> prototypes. I would like to understand why. Apart from its main
> purpose, I believed that the use of 'const' helps the compiler to
> optimise the code. Of course, I must be wrong, or the gains must be
> very small compared with the reasons for not using 'const', which I
> ignore.

More than optimization, I think const is good for documentation. It
shows at a glance what is supposed to change in the parameters of a
function. Not that it gives you garanties, but at least it reflects the
intent of the programmer.

Theo.

Re: [RFA] Boehm GC support addition for debugging

[Marco Trudel]

I already sent a patch for that to the java-patches list...


Andreas Tobler wrote:

Andrew Pinski wrote:


On Jun 26, 2006, at 10:02 PM, Andrew Pinski wrote:



On Jun 26, 2006, at 9:01 AM, Bryce McKinlay wrote:


Otherwise, this is fine.


No it is not, it broke bootstrap on powerpc-darwin:


Did you look when the function would have been declared.
 From gc.h:

#if defined(GC_PTHREADS) && !defined(GC_SOLARIS_THREADS) \
  && !defined(GC_WIN32_THREADS) && !defined(GC_DARWIN_THREADS)
GC_API void GC_suspend_thread GC_PROTO((pthread_t));
GC_API void GC_resume_thread GC_PROTO((pthread_t));
#endif

So this is not just Darwin but also Windows and maybe solaris too.


Solaris too. :(

I'd wish being a bit more careful with such patches.
Everyone can ask for RFT and I'll happily test on my farm as time permits.

Andreas

P.S, Me being a _spare_ time contributor

Re: why are we not using const?

[Ross Ridge]

Andrew Pinski wrote:
>"Stupid" example where a const argument can change:
>tree a;
>int f(const tree b)
>{
>  TREE_CODE(a) = TREE_CODE (b) + 1;
>  return TREE_CODE (b);
>}

You're not changing the constant argument "b", just what "b" might point
to.  I don't think there are any optimizing opportunities for arguments
declared as const, as opposed to arguments declared as pointing to const.

Ross Ridge

Delayed branch scheduling pass destroys the CFG data?

[Minh D. Nguyen]

Dear all, 

I am trying to embed the control flow graph information into the assembly code 
generated in the final pass of gcc. 

While doing that, I found a very strange situation which the control flow 
graph does not comply with the gcc internal document. In the internal 
document, it is stated that "A CODE_LABEL cannot appear in the instruction 
stream of a basic block" (p155). But in the RTL of a basic block before the 
final pass, there is a CODE_LABEL (171) as following:
start basic block 3 -
The rtx in bb: 
(code_label/v 27 93 28 27 "" [0 uses])
(note 28 93 30 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 30 28 171 (set (reg:SI 2 r2 [orig:162 n_lsm.307 ] [162]) 
(plus:SI (reg:SI 2 r2 [orig:162 n_lsm.307 ] [162])
(reg:SI 1 r1 [orig:160 ivtmp.313 ] [160]))) 39 {*addsi3_compact} 
(nil)
(nil))
(code_label 171 30 31 50 "" [1 uses])
(insn 31 171 33 (set (reg:SI 1 r1 [orig:160 ivtmp.313 ] [160])
(plus:SI (reg:SI 1 r1 [orig:160 ivtmp.313 ] [160])
(const_int 1 [0x1]))) 39 {*addsi3_compact} (nil)
(nil))
(insn 33 31 172 (set (reg:SI 147 t)
(eq:SI (reg:SI 1 r1 [orig:160 ivtmp.313 ] [160])
(reg:SI 5 r5 [orig:165 s.2 ] [165]))) 1 {cmpeqsi_t} 
(insn_list:REG_DEP_TRUE 31 (nil))
(nil))
(insn 172 33 170 (sequence [
(jump_insn 34 33 30 (set (pc)
(if_then_else (eq (reg:SI 147 t)
(const_int 0 [0x0]))
(label_ref:SI 171)
(pc))) 208 {branch_false} (insn_list:REG_DEP_TRUE 33 
(nil))
(expr_list:REG_BR_PRED (const_int 12 [0xc])
(expr_list:REG_DEAD (reg:SI 147 t)
(expr_list:REG_BR_PROB (const_int 9000 [0x2328])
(nil)
(insn/s 30 34 170 (set (reg:SI 2 r2 [orig:162 n_lsm.307 ] [162])
(plus:SI (reg:SI 2 r2 [orig:162 n_lsm.307 ] [162])
(reg:SI 1 r1 [orig:160 ivtmp.313 ] [160]))) 39 
{*addsi3_compact} (nil)
(nil))
]) -1 (nil)
(nil))

end basic block 3 -

You can note that the CODE_LABEL 171 does appear in the basic block. 

Therefore the assemble code generated for this basic block does not comply 
with the definition of a basic block where the basic block should be a linear 
sequence of instructions:

01d8 <_main_sh_bb3>:
  n = n+i;
 1d8:   32 1c   add r1,r2
 1da:   71 01   add #1,r1
 1dc:   31 50   cmp/eq  r5,r1
 1de:   8f fc   bf.s1da <_main_sh_bb3+0x2>
 1e0:   32 1c   add r1,r2
 1e2:   32 18   sub r1,r2

The basic block should be from the address 1da (add #1, r1) to the address 1de 
(bf.s 1da), instead of being from the address 1d8 -> 1e2 as being stored in 
the control flow graph structure. Now if I build the control flow graph from 
the internal data of GCC, I will get a different/wrong result from the result 
I get from the assembly code. 

I though the problem is that the delayed branch scheduling pass changes the 
some instructions for the delayed branch, but it does not change the control 
flow graph data. 

Could you please confirm me if I am correct?
--
Minh D. Nguyen
Electronic Design Automation
Dept. of Electrical and Computer Eng.
University of Kaiserslautern
67653 Kaiserslautern, Germany
phone: +49 631 205 2609
fax:   +49 631 205 4782
--

XIP on an ARM processor (R_ARM_GOTOFF32)

[Shaun Jackman]

I'm attempting to build an XIP "Hello, world!" application for the ARM
processor. I'm compiling with -fPIC -msingle-pic-base with the default
-mpic-register=r10. The layout of the memory map is such that the
.text and .rodata are in flash memory, and the .got, .data and so
forth are loaded into RAM. r10 is loaded with the address of the .got.

I'm having trouble with string constants. The address of a string
constant is being resolved using a R_ARM_GOTOFF32 relocation. For
example...

 d6:4803ldr r0, [pc, #12]   (e4 <.text+0xe4>)
 d8:4450add r0, sl
...
 e4:ffdc    undefined
e4: R_ARM_GOTOFF32  .LC0

The address to the string constant is being specified as a negative
offset from the GOT. However, in this memory layout the GOT does not
immediately follow the .text section, so a negative offset from the
GOT expecting to find the .text section does not make any sense. A PC
relative relocation (R_ARM_PC24), on the other hand, should work. The
address of the string constant would be specified as a positive offset
from the program counter, rather than a negative offset from the GOT.
Is there a compiler option to force this behaviour?

Please cc me in your reply. Thanks,
Shaun

Re: Delayed branch scheduling pass destroys the CFG data?

[Steven Bosscher]

On 6/27/06, Minh D. Nguyen <[EMAIL PROTECTED]> wrote:

I though the problem is that the delayed branch scheduling pass changes the
some instructions for the delayed branch, but it does not change the control
flow graph data.


It does not change the control flow graph.  It destroys it. It doesn't
even really know that there is a CFG and it makes no attempt to keep
it up-to-date. It would take a rewrite of both reorg itself and of the
whole CFG support infrastructure in GCC to make it possible to have a
CFG after reorg.  The current CFG infrastructure cannot handle the
SEQUENCE pseudo-insns used to represent delay slots.

Gr.
Steven

Re: [uClinux-dev] XIP on an ARM processor (R_ARM_GOTOFF32)

[Shaun Jackman]

On 6/27/06, Erwin Authried <[EMAIL PROTECTED]> wrote:

Hi,

which compiler/binutil version did you use? Could you post the source
that you used?
One other thing (although that doesn't seem to have to do with your
problem): It is important that you use -fpic (not -fPIC) so that the
correct multilib library is used. For the same reason, -fpic must be
specified in CFLAGS as well as in LDFLAGS if you use a Makefile.

Regards,
Erwin


Hello Erwin,

The source is simply...

int main() { puts("Hello, world!"); return 0; }

I'm using binutils 2.17 and gcc 4.1.1.

The issue-raising difference is that I attempted to place .rodata
after the .text semgent in flash, rather than with the .data segment
in RAM. This should work, except that GCC is creating GOT-relative
references to the symbols in .rodata rather than PC-relative
references. The GOT-relative reference does not work if the .rodata
symbol is with the .text segment instead of with the .data segment.

Cheers,
Shaun

Re: XIP on an ARM processor (R_ARM_GOTOFF32)

[Shaun Jackman]

On 6/27/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:

I'm attempting to build an XIP "Hello, world!" application for the ARM
processor. I'm compiling with -fPIC -msingle-pic-base with the default
-mpic-register=r10. The layout of the memory map is such that the
.text and .rodata are in flash memory, and the .got, .data and so
forth are loaded into RAM. r10 is loaded with the address of the .got.


A workaround is to place the .rodata section after the .got with the
.data section rather than with the .text data. This work-around loses
the advantage of keeping the read-only data in flash, instead of
copying it to RAM.

Cheers,
Shaun

Re: why are we not using const?

[Daniel Berlin]

Manuel López-Ibáñez wrote:
> Dear all,
> 
> from comments in the #gcc irc channel, I understood that it is not
> advisable for gcc patches to use the const qualifier in function
> prototypes. I would like to understand why. Apart from its main
> purpose, I believed that the use of 'const' helps the compiler to
> optimise the code.


It generally doesn't, unless you apply const to the underlying type, and
not just the pointer.

IE you say you have a pointer to a constant piece of memory, not a
constant pointer to a piece of memory.

Otherwise, we generally *already* know it doesn't change, we don't need
your help :)

The only places it helps therefore are in globals, and if you enjoy
passing the address of pointers to functions.

This is the way things are in C, anyway.
In C++, with nice things like const methods, it's a different story.

--Dan

Re: why are we not using const?

[Manuel López-Ibáñez]

On 27/06/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:

Manuel López-Ibáñez wrote:
> Apart from its main
> purpose, I believed that the use of 'const' helps the compiler to
> optimise the code.


It generally doesn't, unless you apply const to the underlying type, and
not just the pointer.

IE you say you have a pointer to a constant piece of memory, not a
constant pointer to a piece of memory.



But... tree is a pointer to "union tree_node" , isn't it? perhaps it
is that "const tree" is not the same as " const union tree_node * " ?

(btw, thanks for taking the time to clarify my doubts...)

make proto fails

[Andreas Jaeger]

make proto on gcc trunk fails on Linux/x86_64 with:

/abuild/builds/gcc/./prev-gcc/xgcc -B/abuild/builds/gcc/./prev-gcc/ 
-B/opt/gcc/4.2-devel/x86_64-suse-linux-gnu/bin/ -c -DUNPROTOIZE   -g -O2 
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
-Wold-style-definition -Wmissing-format-attribute -Werror -fno-common   
-DHAVE_CONFIG_H -I. -I. -I/cvs/gcc-svn/trunk/gcc -I/cvs/gcc-svn/trunk/gcc/. 
-I/cvs/gcc-svn/trunk/gcc/../include -I/cvs/gcc-svn/trunk/gcc/../libcpp/include  
-I/cvs/gcc-svn/trunk/gcc/../libdecnumber -I../libdecnumber\
  -DSTANDARD_STARTFILE_PREFIX=\"../../../\" 
-DSTANDARD_EXEC_PREFIX=\"/opt/gcc/4.2-devel/lib/gcc/\" 
-DSTANDARD_LIBEXEC_PREFIX=\"/opt/gcc/4.2-devel/libexec/gcc/\" 
-DDEFAULT_TARGET_VERSION=\"4.2.0\" 
-DDEFAULT_TARGET_MACHINE=\"x86_64-suse-linux-gnu\" 
-DSTANDARD_BINDIR_PREFIX=\"/opt/gcc/4.2-devel/bin/\" 
-DTOOLDIR_BASE_PREFIX=\"../../../../\"  `test "X${SHLIB_LINK}" = "X" || test 
"yes" != "yes" || echo "-DENABLE_SHARED_LIBGCC"` `test "X${SHLIB_MULTILIB}" = 
"X" || echo "-DNO_SHARED_LIBGCC_MULTILIB"` \
  /cvs/gcc-svn/trunk/gcc/protoize.c -o unprotoize.o)
cc1: warnings being treated as errors
/cvs/gcc-svn/trunk/gcc/protoize.c: In function ‘edit_fn_definition’:
/cvs/gcc-svn/trunk/gcc/protoize.c:3506: warning: argument ‘clean_text_p’ might 
be clobbered by ‘longjmp’ or ‘vfork’
make: *** [unprotoize.o] Error 1

I don't know what broke this since I haven't bootstrapped gcc the last
three weeks.Any ideas?

The trivial workaround is to add to gcc/Makefile.in something like:

# Fix for argument ‘clean_text_p’ might be clobbered by ‘longjmp’ or ‘vfork’
unprotoize.o-warn = -Wno-error

If I should submit this as patch, please tell me,

Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgpk5Vo0QBTvD.pgp
Description: PGP signature

Re: make proto fails

[Andreas Schwab]

Andreas Jaeger <[EMAIL PROTECTED]> writes:

> /cvs/gcc-svn/trunk/gcc/protoize.c: In function ‘edit_fn_definition’:
> /cvs/gcc-svn/trunk/gcc/protoize.c:3506: warning: argument ‘clean_text_p’ 
> might be clobbered by ‘longjmp’ or ‘vfork’

That's probably the same bug as PR21059.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: why are we not using const?

[Manuel López-Ibáñez]

On 27/06/06, Andrew Haley <[EMAIL PROTECTED]> wrote:

OK, now you're getting the idea, you need to think about the
difference between

   const union tree_node *
   union tree_node *const
   const union tree_node *const



My fault then, I was erroneously assuming that if "tree" is equal to
"union tree_node*" then "const tree" is equal to "const union
tree_node*". I learnt something new today! Thanks to everyone that
answered.

Cheers,

Manuel.

Re: why are we not using const?

[Tristan Wibberley]

Manuel López-Ibáñez wrote:

On 27/06/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:

Manuel López-Ibáñez wrote:
> Apart from its main
> purpose, I believed that the use of 'const' helps the compiler to
> optimise the code.


It generally doesn't, unless you apply const to the underlying type, and
not just the pointer.

IE you say you have a pointer to a constant piece of memory, not a
constant pointer to a piece of memory.



But... tree is a pointer to "union tree_node" , isn't it? perhaps it
is that "const tree" is not the same as " const union tree_node * " ?

(btw, thanks for taking the time to clarify my doubts...)



typedef union tree_node *tree;
void f(const tree a);

is equivalent to

void f(union tree_node * const a);

ie, it says the pointer is const so there's little point in using it.

typedef union tree_node const *const_tree;
void f(const_tree a);

*would* be meaningful, however.

--
Tristan Wibberley

dwarf2 initial_return_save vs gdb

[DJ Delorie]

I'm looking at the H8/300 frame debugging info, and it seems to me
that gdb needs to have at least *some* information about where the
return address is in order to unwind the stack using dwarf2 call frame
information, perhaps because H8/300 saves the RA on the stack, not in
a register.  However, we only set up the RA column if we're using
dwarf2 for EH.  Why?

$ grep -C 1 '^ .*if *(.*DWARF2_UNWIND_INFO' *
dwarf2out.c-#ifdef DWARF2_UNWIND_INFO
dwarf2out.c:  if (DWARF2_UNWIND_INFO)
dwarf2out.c-initial_return_save (INCOMING_RETURN_ADDR_RTX);

With my local dwarf2 support patches, commenting out the if() above is
the difference between backtraces working, and not working.

Can we call initial_return_save for non-EH unwind too?

Re: [uClinux-dev] Re: XIP on an ARM processor (R_ARM_GOTOFF32)

[David McCullough]

Jivin Shaun Jackman lays it down ...
> On 6/27/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> >I'm attempting to build an XIP "Hello, world!" application for the ARM
> >processor. I'm compiling with -fPIC -msingle-pic-base with the default
> >-mpic-register=r10. The layout of the memory map is such that the
> >.text and .rodata are in flash memory, and the .got, .data and so
> >forth are loaded into RAM. r10 is loaded with the address of the .got.
> 
> A workaround is to place the .rodata section after the .got with the
> .data section rather than with the .text data. This work-around loses
> the advantage of keeping the read-only data in flash, instead of
> copying it to RAM.

Are you using the ld-elf2flt/elf2flt.ld combo ?

It lays things out in a known way and has a '-move-rodata' option which
will put the rodata in with the .text if it contains no relocation info
needed at runtime.

Something like this on the link line:

-gcc  -Wl,-move-rodata 

The uClinux-dist has this as the default for !MMU systems that can do
XIP,

Cheers,
Davidm


-- 
David McCullough,  [EMAIL PROTECTED],   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

Re: [uClinux-dev] Re: XIP on an ARM processor (R_ARM_GOTOFF32)

[Shaun Jackman]

On 6/27/06, David McCullough <[EMAIL PROTECTED]> wrote:

Are you using the ld-elf2flt/elf2flt.ld combo ?

It lays things out in a known way and has a '-move-rodata' option which
will put the rodata in with the .text if it contains no relocation info
needed at runtime.

Something like this on the link line:

-gcc  -Wl,-move-rodata 

The uClinux-dist has this as the default for !MMU systems that can do
XIP,

Cheers,
Davidm


I'm not using ld-elf2flt, but I am using elf2flt.ld.

arm-elf-gcc -mthumb -fPIC -msingle-pic-base -Wl,-q -Telf2flt.ld hello.c -o hello
arm-elf-elf2flt -adp hello hello -o hello.bflt

The ld script that puts .rodata in .text fails, due to GCC referencing
symbols in .rodata with a GOTOFF32 relocation. So, I used the other
linker script instead, which put .rodata in .data after the .got. This
got me as far as an XIP "Hello, world!" working, which is thrilling!

Unfortunately, a more complex application, busybox, which uses bsearch
and thus a callback function, fails because GCC loads the address for
the callback function using a GOTOFF32 relocation. In the XIP case
where .text and .data are separated and .got does not immediately
follow .text, a GOTOFF32 relocation to a symbol in the .text segment
is super broken.

   bc84:4b05ldr r3, [pc, #20]   (bc9c <.text+0xbc9c>)
   bc86:b081sub sp, #4
   bc88:4453add r3, sl
   bc8a:9300str r3, [sp, #0]
...
   bc9c:2461movsr4, #97
bc9c: R_ARM_GOTOFF32applet_name_compare

Loading the address of the callback function with either a PC relative
relocation or a GOT (not GOTOFF) relocation would work. Can I prevent
GCC from using GOTOFF32 relocations to symbols located in the .text
segment?

Can someone on the list verify with their toolchain that the address
of a static function is loaded using a GOTOFF32 relocation? The
following test should suffice. It's interesting to note that if the
callback function is not static, GCC will use a GOT32 relocation
instead, which will work.

I'm using binutils 2.17 and gcc 4.1.1.

Cheers,
Shaun

$ cat f.c
void g(void (*h)(void)) {}
static void f(void) { g(f); }
$ arm-elf-gcc -mthumb -fPIC -msingle-pic-base -c f.c
$ arm-elf-objdump -rS f.o | tail -3
 24:   lslsr0, r0, #0
   24: R_ARM_GOTOFF32  f
   ...

Re: [uClinux-dev] Re: XIP on an ARM processor (R_ARM_GOTOFF32)

[David McCullough]

Jivin Shaun Jackman lays it down ...
> On 6/27/06, David McCullough <[EMAIL PROTECTED]> 
> wrote:
> >Are you using the ld-elf2flt/elf2flt.ld combo ?
> >
> >It lays things out in a known way and has a '-move-rodata' option which
> >will put the rodata in with the .text if it contains no relocation info
> >needed at runtime.
> >
> >Something like this on the link line:
> >
> >-gcc  -Wl,-move-rodata 
> >
> >The uClinux-dist has this as the default for !MMU systems that can do
> >XIP,
> >
> >Cheers,
> >Davidm
> 
> I'm not using ld-elf2flt, but I am using elf2flt.ld.
> 
> arm-elf-gcc -mthumb -fPIC -msingle-pic-base -Wl,-q -Telf2flt.ld hello.c -o 
> hello
> arm-elf-elf2flt -adp hello hello -o hello.bflt


AFAIK,  you need to drop the -FPIC in favour of -fpic everywhere.


> The ld script that puts .rodata in .text fails, due to GCC referencing
> symbols in .rodata with a GOTOFF32 relocation. So, I used the other
> linker script instead, which put .rodata in .data after the .got. This
> got me as far as an XIP "Hello, world!" working, which is thrilling!
> 
> Unfortunately, a more complex application, busybox, which uses bsearch
> and thus a callback function, fails because GCC loads the address for
> the callback function using a GOTOFF32 relocation. In the XIP case
> where .text and .data are separated and .got does not immediately
> follow .text, a GOTOFF32 relocation to a symbol in the .text segment
> is super broken.
> 
>bc84:  4b05ldr r3, [pc, #20]   (bc9c <.text+0xbc9c>)
>bc86:  b081sub sp, #4
>bc88:  4453add r3, sl
>bc8a:  9300str r3, [sp, #0]
> ...
>bc9c:  2461movsr4, #97
>   bc9c: R_ARM_GOTOFF32applet_name_compare
> 
> Loading the address of the callback function with either a PC relative
> relocation or a GOT (not GOTOFF) relocation would work. Can I prevent
> GCC from using GOTOFF32 relocations to symbols located in the .text
> segment?
> 
> Can someone on the list verify with their toolchain that the address
> of a static function is loaded using a GOTOFF32 relocation? The
> following test should suffice. It's interesting to note that if the
> callback function is not static, GCC will use a GOT32 relocation
> instead, which will work.
> 
> I'm using binutils 2.17 and gcc 4.1.1.


You could try some experiments using the older toolchain to see how it
puts binaries together etc.  AFAIK,  thumb and most archs are supported
by it, it provides at least a working reference for fixing a new
toolchain at least,

Cheers,
Davidm

> $ cat f.c
> void g(void (*h)(void)) {}
> static void f(void) { g(f); }
> $ arm-elf-gcc -mthumb -fPIC -msingle-pic-base -c f.c
> $ arm-elf-objdump -rS f.o | tail -3
>  24:   lslsr0, r0, #0
>24: R_ARM_GOTOFF32  f
>...
> ___
> uClinux-dev mailing list
> [EMAIL PROTECTED]
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by [EMAIL PROTECTED]

-- 
David McCullough,  [EMAIL PROTECTED],   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

Re: Question concerning shared libraries in non-standard locations

[Albert Chin]

On Tue, Jun 27, 2006 at 03:48:30AM -0400, Paul Hilfinger wrote:
> 
> I guess that I'm simply suggesting that it might be nice if the sort
> of modification suggested by Albert Chin's response to my question
> could be installed automatically under control of a configuration
> option (e.g.), or as a result of the configuration script's detecting
> a non-standard prefix.  (Well, actually, I think his patch has to
> modified for recent versions; doesn't 4.x compile them into the source
> files?).

I think newer GCC releases (dunno when it started) do not install a
specs file. However, there is a "gcc -dumpspecs" option to print the
specs file so you can save it to the default location GCC would read
it from if the specs file existed.

However, the solution I posted will only work on some platforms. It
won't work on HP-UX/IA, Tru64, nor AIX. Why? Because, on these
systems, the runtime path option (+b, -rpath, -blibpath) is not
additive (i.e. you cannot use these options more than once on the
command-line).

-- 
albert chin ([EMAIL PROTECTED])

Re: make proto fails

[Ian Lance Taylor]

Andreas Jaeger <[EMAIL PROTECTED]> writes:

> make proto on gcc trunk fails on Linux/x86_64 with:

Do you actually need protoize and unprotoize?  I think it would be
nice to deprecate them.  Prototypes have been available for at least
15 years now.

> The trivial workaround is to add to gcc/Makefile.in something like:
> 
> # Fix for argument ‘clean_text_p’ might be clobbered by ‘longjmp’ or ‘vfork’
> unprotoize.o-warn = -Wno-error
> 
> If I should submit this as patch, please tell me,

Looks good to me, not that I can approve it.

Ian

Re: make proto fails

[Andreas Jaeger]

Ian Lance Taylor <[EMAIL PROTECTED]> writes:

> Andreas Jaeger <[EMAIL PROTECTED]> writes:
>
>> make proto on gcc trunk fails on Linux/x86_64 with:
>
> Do you actually need protoize and unprotoize?  I think it would be
> nice to deprecate them.  Prototypes have been available for at least
> 15 years now.

I just build it with my scripts so that somebody builds it at
least;-).  I personally don't need it and removing it wouldn't cause
me any problems.

Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgpl0FsbYKUbM.pgp
Description: PGP signature