adhanakshirur | 1 Aug 08:16 2012
Picon

Where to get libc.a and libidp.a compiled for m68k?

Hi,
I have installed gcc cross compiler for m68k(motorola 68000) in my FC14
system.
I have cross compiled my code.
But m68k-coff-gcc is unable to find libc.a and libidp.a.
Hence it is not able to produce final executable.
I need some more libraries like libgcc.a and libnlib.a
Where to get those libraries compiled for m68k?
regards,
Anand

--
View this message in context: http://gcc.1065356.n5.nabble.com/Where-to-get-libc-a-and-libidp-a-compiled-for-m68k-tp857168.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Tim Rye | 1 Aug 13:57 2012
Picon

Re: Can be gcc portable to architecture without indexed addressing mode?

Hello,

This question is a followup to a previous question asked in March
2010. I am in a similar situation. The original question was:

> Hello.
>
> I have to start to make some c compiler for my own cpu. This cpu has
> very simple core and has many limitations.
>
> I think that many of those limitations are evitable in source coding.
> But I cannot convince a few of them.
>
> Instructions of this cpu core have no indexed addressing mode like
> 'base' + 'offset'.
>
> This cpu can address memories only according to followings.
>
>   immediate addressing
>   indirect addressing with general registers
>
> I really want to know that gcc is portable on this core in spite of
> the limitation.

I too am porting GCC (working on 4.7.1) to a new architecture which
has no indexed addressing mode. I cannot seem to stop GCC from
generating RTL such as (mem:XX (plus:XX (reg:XX ...) (const_int XX))).
This is clearly invalid for a machine with no indexed addressing mode.

I have tried defining the following macros as I think they need to be
(Continue reading)

Ian Lance Taylor | 1 Aug 15:08 2012
Picon

Re: Can be gcc portable to architecture without indexed addressing mode?

On Wed, Aug 1, 2012 at 4:57 AM, Tim Rye <timjrye <at> gmail.com> wrote:
>
> I too am porting GCC (working on 4.7.1) to a new architecture which
> has no indexed addressing mode. I cannot seem to stop GCC from
> generating RTL such as (mem:XX (plus:XX (reg:XX ...) (const_int XX))).
> This is clearly invalid for a machine with no indexed addressing mode.

You should not be seeing such addresses if your legitimate_address_p
target hook rejects them.

> I have tried defining the following macros as I think they need to be
> defined, but it doesn't seem to work:
>
> #define BASE_REG_CLASS WRITEABLE_REGS
> #define MODE_BASE_REG_REG_CLASS(MODE) NO_REGS
> #define INDEX_REG_CLASS NO_REGS
> #ifdef REG_OK_STRICT
> #define REGNO_OK_FOR_BASE_P(NUM) mytarget_regno_ok_for_base_p(NUM,1)
> #else
> #define REGNO_OK_FOR_BASE_P(NUM) mytarget_regno_ok_for_base_p(NUM,0)
> #endif
> #define REGNO_MODE_OK_FOR_REG_BASE_P(NUM, MODE) 0
> #define REGNO_OK_FOR_INDEX_P(NUM) 0
>
> Are these definitions correct for the situation I describe? And if so,
> what else would I need to define to stop GCC using indexed addressing?
> Or, if they are not correct, could you describe what I need to do
> instead?
>
> My TARGET_LEGITIMATE_ADDRESS_P hook returns false when the code of the
(Continue reading)

Ian Lance Taylor | 1 Aug 15:32 2012
Picon

Re: GCC Plugin Development DECL_SAVED_TREE

On Tue, Jul 31, 2012 at 8:44 AM,  <mario.miller <at> web.de> wrote:
>
> I'm currently developing a Plugin with GCC 4.6.3. I want to traverse function bodies; that is where I get
problems. I use the DECL_SAVED_TREE macro to get the tree of the function body. When I get the
tree-code-name of this tree I usually get "bind_expr" with which I can get all variable declarations in
this function. This works pretty well. But I want to analyse some other expressions of this function, too
(like return_expression, if_statements, etc.). How can I do this? I tried using the DECL_SAVED_TREE
macro twice (like tree t = DECL_SAVED_TREE(DECL_SAVED_TREE(node)) but this returns NULL always. I also
tried the TREE_CHAIN macro (like tree t = DECL_SAVED_TREE(node); t = TREE_CHAIN(t)) but this returns
NULL aswell.
> What am I doing wrong? Hope you can help me.

Once you have a BIND_EXPR, look at BIND_EXPR_BODY.

Ian

Ian Lance Taylor | 1 Aug 15:40 2012
Picon

Re: Building GCC for ARM and Linux/ucLibc

On Tue, Jul 31, 2012 at 7:48 AM, Christophe Lyon <christophe.lyon <at> st.com> wrote:
>
> I have some trouble to build the right cross-GCC for ARM running Linux and
> ucLibc, which I want to support -fstack-protector.
>
> Indeed, if I use arm-uclinuxeabi or arm-unknown-uclinux-uclibcgnueabi as
> --target triplet, GCC's configure says:
> checking __stack_chk_fail in target C library... no
>
> but this function is actually provided by ucLibc. I need this test to
> succeed such that -fstack-protector does not imply -lssp_non_shared -lssp.
>
> Given that configure's test is based upon the $target value, I am wondering
> which triplet I should be using, since this test uses:
>     case "$target" in
>        *-*-linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu)
> [...]
>        *-*-gnu*)
> [...]
>
> I have also looked at config.gcc, and I think the triplet should also match
> arm*-*-uclinux* to get the right configuration.
>
> What triplet should I use?

I don't know.  Perhaps the uClibc developers can suggest something.

I see that the tree supports *-*-linux-uclibc in various cases.  But I
do also see uclinux used.  I'm not sure why this discrepancy arose.
Probably the test for stack_check_fail should match uclinux as well as
(Continue reading)

Paweł Sikora | 1 Aug 15:59 2012
Picon

strange segfaults / valgrind errors / invalid free on string ::_Rep::_S_empty_rep_storage

Hi,

with gcc-4.7.x configured with --enable-symvers=gnu-versioned-namespace i have strange segfaults
with my debug build.
i'm using following switches for compilation:

$ g++ -c -D_GNU_SOURCE -D_GLIBCXX_DEBUG -D_DEBUG -pthread -Wall -Wno-maybe-uninitialized
-Winit-self -Wno-deprecated -Wsign-compare \
      -Wtype-limits -Wempty-body -Wnon-virtual-dtor -Wc++11-compat -Woverloaded-virtual  -Werror -mcld
-fmax-errors=3 -fdwarf2-cfi-asm \
      -fno-debug-types-section -march=x86-64 -O1 -gdwarf-4 -g2 -fno-strict-aliasing -pipe
-fno-schedule-insns -fno-schedule-insns2 -std=gnu++11

valgrind reports invalid free/delete:

==7889== Thread 4:
==7889== Invalid free() / delete / delete[] / realloc()
==7889==    at 0x4A07096: operator delete(void*) (vg_replace_malloc.c:457)
==7889==    by 0x4D88A90: std::__7::basic_string<char, std::__7::char_traits<char>,
std::__7::allocator<char> >::_Rep::_M_destroy(std::__7::allocator<char> const&) (in /remote/pawels/dvm/svn-trunk/build-debug-x86_64-gnu-linux/libsce_mi.so)
==7889==    by 0x4D930DD: std::__7::basic_string<char, std::__7::char_traits<char>,
std::__7::allocator<char> >::_Rep::_M_dispose(std::__7::allocator<char> const&) (in /remote/pawels/dvm/svn-trunk/build-debug-x86_64-gnu-linux/libsce_mi.so)
==7889==    by 0x4D94A51: au::Path::~Path() (in /remote/pawels/dvm/svn-trunk/build-debug-x86_64-gnu-linux/libsce_mi.so)
==7889==    by 0x4D91E42: scemi::CfgReader::readCfg(char const*) (in /remote/pawels/dvm/svn-trunk/build-debug-x86_64-gnu-linux/libsce_mi.so)
==7889==    by 0x4DBF368: SceMiParameters::SceMiParameters(char const*, SceMiEC*) (in /remote/pawels/dvm/svn-trunk/build-debug-x86_64-gnu-linux/libsce_mi.so)
==7889==    by 0x406141: TestBench::Init() (testbench.cpp:251)
==7889==    by 0x4CAC759: sc_core::sc_thread_cor_fn(void*) (sc_process.h:514)
==7889==    by 0x4C98996: sc_core::sc_cor_pthread::invoke_module_method(void*) (sc_cor_pthread.cpp:142)
==7889==    by 0x3D24C0673C: start_thread (in /lib64/libpthread-2.5.so)
==7889==    by 0x3D240D3D1C: clone (in /lib64/libc-2.5.so)
(Continue reading)

Tim Rye | 1 Aug 16:53 2012
Picon

Re: Can be gcc portable to architecture without indexed addressing mode?

Hi Ian,

Thanks for the speedy response.

> You should not be seeing such addresses if your legitimate_address_p
> target hook rejects them.

I'm pretty certain my legitimate_address_p does reject them. It's very
simple, and basically only accepts addresses which are constant or in
registers:

-------------

static bool mytarget_legitimate_address_p(enum machine_mode mode, rtx
x, bool strict) {

  while (GET_CODE(x) == MEM)
    x = XEXP(x,0);

  if (CONSTANT_P(x))
    return true;

  if (GET_CODE(x) == SUBREG && !strict)
    x = SUBREG_REG(x);

  if (GET_CODE(x) == REG) {

    if (!strict)
      return true;

(Continue reading)

Ian Lance Taylor | 1 Aug 17:01 2012
Picon

Re: Can be gcc portable to architecture without indexed addressing mode?

On Wed, Aug 1, 2012 at 7:53 AM, Tim Rye <timjrye <at> gmail.com> wrote:
>
> static bool mytarget_legitimate_address_p(enum machine_mode mode, rtx
> x, bool strict) {
>
>   while (GET_CODE(x) == MEM)
>     x = XEXP(x,0);

That definitely does not look right.  Accepting a MEM here means that
your instructions accept addresses stored in memory.  That is a very
unusual addressing mode.

> mul.c:37:1: internal compiler error: in change_address_1, at emit-rtl.c:1996
>
> The stack trace at this point looks like this:
>
> -------------
>
> (gdb) where
> #0  fancy_abort (file=0xb2c8c8
> "../../gcc-4.7.1-mytarget/gcc/emit-rtl.c", line=1996,
>     function=0xb2ca20 "change_address_1") at
> ../../gcc-4.7.1-mytarget/gcc/diagnostic.c:898
> #1  0x00000000005c4109 in change_address_1 (memref=0x2a95691a08,
> mode=HImode, addr=0x2a956919f0,

> #5  0x00000000005e80c5 in emit_move_insn_1 (x=0x2a9568c420, y=0x2a95691960)
>     at ../../gcc-4.7.1-mytarget/gcc/expr.c:3417

This suggests that your move insn needs special handling during
(Continue reading)

Jonathan Wakely | 1 Aug 20:57 2012
Picon

Re: strange segfaults / valgrind errors / invalid free on string ::_Rep::_S_empty_rep_storage

On 1 August 2012 14:59, Paweł Sikora wrote:
> i have no idea why the string implementation tries to destroy static _S_empty_rep_storage area?

This usually implies some objects were compiled by GCC configured with
--enable-fully-dynamic-string and some objects were compiled by a
different GCC configured without that option.  That option changes the
ABI, so you can't mix objects with an without it.

Could that be the cause?

Paweł Sikora | 1 Aug 22:05 2012
Picon

Re: strange segfaults / valgrind errors / invalid free on string ::_Rep::_S_empty_rep_storage

On Wednesday 01 of August 2012 19:57:25 Jonathan Wakely wrote:
> On 1 August 2012 14:59, Paweł Sikora wrote:
> > i have no idea why the string implementation tries to destroy static _S_empty_rep_storage area?
> 
> This usually implies some objects were compiled by GCC configured with
> --enable-fully-dynamic-string and some objects were compiled by a
> different GCC configured without that option.  That option changes the
> ABI, so you can't mix objects with an without it.
> 
> Could that be the cause?

all used libraries and the main application are built with the same linux toolchain
configured without fully-dynamic-string and with versioned libstdc++ namespace.
these pieces works pretty fine without any gpf/valgrind error in so called "release"
build (without _DEBUG _GLIBCXX_DEBUG).


Gmane