Re: cselib_record_set breaks due to auto_inc_dec

[Paulo J. Matos]

On 22/12/12 10:13, Alexandre Oliva wrote:

On Dec 20, 2012, "Paulo Matos"  wrote:


This doesn't look sensible to me (but I might be overlooking a reason why we 
want to do so) in the context of cselib_record_sets, however, I think 
cselib_record_sets should instead have the patch applied:
- for_each_inc_dec (&insn, cselib_record_autoinc_cb, &data);
+ for_each_inc_dec (&body, cselib_record_autoinc_cb, &data);


Yeah, that makes sense.  Walking over REG_NOTES was surely unexpected to
me.



Thanks for your comment, I will prepare a patch after this holiday period.

Cheers,

Paulo Matos

Re: libtsan invalid use of ld-linux internals

[Dmitry Vyukov]

On Mon, Dec 17, 2012 at 11:58 AM, Jakub Jelinek  wrote:
> Hi!
>
> I've noticed libtsan can't be installed via rpm, due to invalid use of
> dynamic linker's internals:
>
> #ifdef __i386__
> # define INTERNAL_FUNCTION __attribute__((regparm(3), stdcall))
> #else
> # define INTERNAL_FUNCTION
> #endif
> extern "C" void _dl_get_tls_static_info(size_t*, size_t*)
> __attribute__((weak)) INTERNAL_FUNCTION;
>
> static int InitTlsSize() {
>   typedef void (*get_tls_func)(size_t*, size_t*) INTERNAL_FUNCTION;
>   get_tls_func get_tls = &_dl_get_tls_static_info;
>   if (get_tls == 0) {
> void *get_tls_static_info_ptr = dlsym(RTLD_NEXT, 
> "_dl_get_tls_static_info");
> CHECK_EQ(sizeof(get_tls), sizeof(get_tls_static_info_ptr));
> internal_memcpy(&get_tls, &get_tls_static_info_ptr,
> sizeof(get_tls_static_info_ptr));
>   }
>   CHECK_NE(get_tls, 0);
>   size_t tls_size = 0;
>   size_t tls_align = 0;
>   get_tls(&tls_size, &tls_align);
>   return tls_size;
> }
>
> The
> get_tls_func get_tls = &_dl_get_tls_static_info;
> is what precludes libtsan installation, then libtsan.so refers to
> _dl_get_tls_static_info@@GLIBC_PRIVATE
> symbol and at least our rpm dependency stuff reject that, because nothing
> outside of glibc should ever refer to symbols marked as GLIBC_PRIVATE.
> Those are exported solely because they are used by other libraries that are
> part of glibc (in this case libc.so.6).
> If you need to get at the info it returns, please talk to
> libc-al...@sourceware.org for help.  The first line certainly must go, the
> second alternative (dlsym) will not prevent installation, but may break
> anytime, glibc doesn't guarantee anything about the ABI of the symbols, it
> can be removed any time, can change parameters/return values without
> warning.
>
> Jakub


Hi,

I've removed static reference to _dl_get_tls_static_info() for now:
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_platform_linux.cc?r1=171033&r2=171032&pathrev=171033

and sent the email to libc-alpha@
http://sourceware.org/ml/libc-alpha/2012-12/msg00404.html

Thanks!

Internal Compiler Error

[tanle]

Could you explain for you about "Internal Compiler Error"?
I am building the Linux kernel for microbalze (Atlys Board), there are 
some errors as:

fs/ext2/super.c: In function 'ext2_fill_super':
fs/ext2/super.c:1144:1: internal compiler error: in reload, at 
reload1.c:1059

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [fs/ext2/super.o] Error 1
make[1]: *** [fs/ext2] Error 2
make: *** [fs] Error 2
I use gcc version 4.6.1

Best Regards
TanLe

How do disable generation of LDRD in ARM

[Roger Cruz]

I am compiling this piece of code from an open source project that I wish not 
to have to change.  The problem is that when compiled for ARM, it generates an 
LDRD instruction, which when executed, causes a bus error since the address in 
ptr is not doubleword aligned.  I know I can change the code but I prefer to 
leave it intact as there may be many more instances of this and I don't wish to 
maintain the code.  I found the compiler option -mfix-cortex-m3-ldrd but the 
code still being generated with the LDRD instruction.  Any suggestions on how 
to tell the compiler to avoid LDRD instructions?


248    static DWORD64 dwarf2_get_u8(const unsigned char* ptr)
249    {
250        return *(const UINT64*)ptr;
251    }


(gdb) x/5i $pc
=> 0x4325ffd4 :    ldrd    r2, [r3]
gdb) p ptr
$6 = (const unsigned char *) 0x435a2fa5 ""
(gdb) p $r3
$7 = 0x435a2fa5



Happy Holidays,
Roger R. Cruz