のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,905人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレGCCについて part10

    gcc覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter
    302 = :

    消すなら --disable-multilib ではなくて --disable-sjlj-exceptions だろjk

    あと、もし binutils を一緒にビルドしようとして、
    gcc のフォルダ内に binutils/{なんやらかんやら} へのリンクを張ってるなら、
    両者に共通のライブラリが、バージョン違って失敗するかも

    303 = :

    消したけどダメ。。
    ターゲット・ホスト・ビルドのx86_64-w64を消さないとどうしても
    「はぁ?x64?」みたいな事言われるので消して、それでもintlで文句言われて
    config.hに<linintl.h>書き加えてビルド進めるとlibgccで

    Assembler messages:
    Error: invalid instruction suffix for `push'

    アセンブラ関連のエラーだと思うんだけど、ターゲットをx86_64-w64にすると怒
    られ、libintlで怒られ…gccサイトのQ&A見ても「我々は悪くない、文句言われる
    テメーが悪い」みたいな事書いてあるし。。。。

    もうネルソン!

    305 = :

    なんだかよく分からなかったけど強引に潰したエラー、3件

    1.↓って言われる
    i386/cygming.h:358:2: error: #error For 64-bit windows and 32-bit based multilib version of gcc just SJLJ exceptions are supported.
    i386/mingw32.h:101:2: error: #error DW2 unwind is not available for 64-bit.
    i386/cygming.h:358:2: error: #error For 64-bit windows and 32-bit based multilib version of gcc just SJLJ exceptions are supported.
    i386/mingw32.h:101:2: error: #error DW2 unwind is not available for 64-bit.
    i386/cygming.h:358:2: error: #error For 64-bit windows and 32-bit based multilib version of gcc just SJLJ exceptions are supported.
    i386/mingw32.h:101:2: error: #error DW2 unwind is not available for 64-bit.
    コメントアウト

    2.
    intl_printが不明
    config.hに<libintl.h>を書き足す

    3.
    libstdc++-v3/include/bits/basic_string.hでエラー

    call googleで外人さんのパッチをクローン
    +++ ./libstdc++-v3/config/os/mingw32-w64/os_defines.h
    +#include <_mingw_mac.h>
    +#if !defined (__MINGW64_VERSION_MAJOR) || (__MINGW64_VERSION_MAJOR < 3)
     #define _GLIBCXX_HAVE_BROKEN_VSWPRINTF 1
    +#endif

    3は、なんだか公式のmingw32使えみたいな事言ってた気がするけど1.2が分からんち
    特に2番、なんでヘッダを要求されるのか。公式になんか書いても怖い人しかいないよう
    な雰囲気なので聞けない。。。

    グダグダ書いたけど結局は>>302のbinutils云々がヒントになってビルド出来た、ありがとね

    307 = :

    馬鹿には無理

    308 = :

    ネタじゃないので聞いてください。
    一番最初のgccはどのようにコンパイルされたのですか?

    309 = :

    別のコンパイラを使う。UNIXのccとか。

    歴史の話じゃなくて実用的な意味でどうするかといえば、
    オフィシャルでバイナリのgccが配布されているのでそれを使う。

    310 = :

    最初のGCCはCで書かれていたわけでは無いらしい

    311 = :

    ネタじゃないので聞いてください。
    一番最初のccはどのようにコンパイルされたのですか?

    312 = :

    最初のコンパイラは機械語で書いた

    314 = :

    gccをどうやってコンパイルするかを勉強してると
    そのあたりまで平然と遡らされるよな

    316 = :

    >>311
    > 一番最初のccはどのようにコンパイルされたのですか?
    当時一般的に使われていた, Unix 上の PCC 互換コンパイラでコンパイルされたんだが,
    なんか問題あるの?

    317 = :

    >>316
    どこまで遡れるか大会だろ空気嫁よ

    318 = :

    ネタじゃないので聞いてください。
    一番最初のアセンブラはどのようにアセンブルされたのですか?

    319 = :

    ネタじゃないならアセンブラスレで訊きましょう

    320 = :

    2chは優秀な技術者が議論する場所

    321 = :

    >>318
    ハンドアセンブル

    322 = :

    multilib有効にしてGCCビルドしたら、ライブラリビルドでldちゃんが
    32ライブラリに64libを合体させてしまいまする
    export -m32 -L/lib32 とかにしても言う事を聞いてくれませぬ
    ググっても、バカには無理みたいな風潮
    TDMとか、どうやってmultilibなGCCビルドしてるんだろ?

    324 = :

    gcc -vは?

    どうでもいいことだが、なぜそんな化石を使うのか聞いてみたい

    325 = :

    gccで、以下のような情報を得るためのコマンドラインオプション、あるいは
    ツール・手段はありませんでしょうか?

    知りたいのは、どういう過程でライブラリがリンクされているかです。
    例えば、main.cでprintf()が使われている時、
    (1) main.o には未解決のシンボル'printf'がある
    (2) 未解決シンボル'printf'を解決するため、libc.a 内の lib_a-printf.o をリンクした
    (3) さらに lib_a-printf.o には未解決のシンボル'vfprintf'がある
    (4) 未解決シンボル'vfprintf'を解決するため、libc.a 内の lib_a-vfprintf.o をリンクした
    (5) さらに lib_a-vfprintf.o には未解決のシンボル・・・・
      :
    のような情報が得たいのです。

    目的は、組み込み用でコードサイズ小さくしたい場合に、想定外のライブラリがリンク
    されているような場合、何が起点になっているかを調べるためです。
    (例えば、標準入出力は使ってないのに標準入出力関係のライブラリがごっそりリンクさ
    れてしまう場合に、sprintf()→vfprintf()→・・・と、sprintf()を使っているのが原因
    であることを知りたい)

    -Wl,--verbose は試してみましたが、ダメでした。

    328 = :

    >>325
    スマートリンクを使った方がてっとりばやいんじゃね?

    329 = :

    >>328
    レス、ありがとうございます。

    スマートリンクもコードサイズ削減に効果が無くはありませんが、(newlibは結構細かく
    ソースが分けてあるので)効果は小さいと思われます。

    例えば、newlibの場合newlib内で使用する静的変数を(マルチスレッド対応等が容易なよ
    うに)_reent構造体にまとめてありますが、これをリンクするような関数を一つでも使用
    してしまうと_reent構造体に関連する関数が多数リンクされ、コードサイズが肥大します。
    これは(実行時に呼ばれることは無くても)未定義シンボル解決には必要であり、
    -Wl,--gc-sectionsでは防止できません。
    コードサイズの肥大の起因となるライブラリ関数が(質問に記述のように)特定でき、これ
    がごく少数なら、この関数を使用しないようにプログラムを書き換えてしまえ、という
    わけです。

    331 = :

    使ってる*.oをnmして未定義シンボルをリストして、
    シンボルがどの*.aで定義されてるかnmして調べて、
    *.aをar xして*.oにしてnmして、
    以下収束するまで繰り返し。

    多分機械的に出来るんじゃないか?
    Cの場合、使われる*.aは引数で与える必要があって、
    最初から全リストが分かってるわけだし。

    332 = :

    >>330
    誤解を招く文章ですいません、ld(binutils)を含めてgccと書いていました。
    -why_live(https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html)
    はまさに欲しているものでしたが、使用しているld(GNU ld version2.15 arm-elf/cygwin
    のクロス環境)には実装されていないようでした。
    * ld.info(manがなかったので)
    * arm-elf-ld --help
    *http://sourceware.org/binutils/docs-2.15/ld/Options.html#Options
    で、why/live/chain/refferenceなどのキーワードで探してみましたが、同等のものは
    見つけられませんでした。

    >>331
    はい、その方法(それを行うツールの作成)は最後の手段として考えています・・・

    336 = :

    gcc -S -g で出力されるアセンブルコード中の.locの情報を
    該当するCソースに置換するフィルタはどこかで公開してませんか?

    337 = :

    as --help
    -a[sub-option...] turn on listings
    Sub-options [default hls]:
    c omit false conditionals
    d omit debugging directives
    g include general info
    h include high-level source
    l include assembly
    m include macro expansions
    n omit forms processing
    s include symbols
    =FILE list to FILE (must be last sub-option)

    gcc -c -O2 hoge.c -Wa,-ahls=hoge.lst

    338 = :

    >>337
    ありがとう。それに-gつけたら出来ました。

    341 = :

    ではお言葉に甘えて。
    カバレッジを調べるためgcovすると自分のソース以外の
    iostream.gcovとかも大量にできてしまいます。

    これを指定のディレクトリ以外は生成しないようにできないものでしょうか?
    今のところ-pをつけてファイルを生成し必要のないフォルダのものをrmで消してます。

    343 = :

    >>342
    使い方が間違っているのか期待した結果になりませんでした。
    srcディレクトリに.h / .ccがあるので -o src と指定しましたがiostream.gcovは生成されました。
    objディレクトリに .o があるので -o obj と指定すると
      obj/test.gcno:cannot open graph file
    といったエラーが表示されます。そこでobjにtest.gcnoをmvすると処理は通りますが
    相変わらずiostream.gcovは生成されます。

    ただlcovすると.gcovは消えるので気にしなければ済む問題かもしれません。

    344 = :

       

    345 = :

    プリプロセッサの話ってここで大丈夫?スレチだったら流して

    gccの-EオプションでCライクな言語のプリプロセスかけてるんだけど、そのマクロの記述で
    #define get_pi(data) (6'(data)<<3)って感じの記述してて、
    これの ' の部分が文字データ記述の開始として扱われてdataが置き換わらないんだけど、対策ないですかね?

    346 = :

    SystemVerilogかね?
    #define s '
    #define get_pi(data) (6 s (data)<<3)
    空白が入るけど動くよ。警告も出るけど。
    規格上問題ないか、どのGCCバージョンでも動くかは分からん。

    347 = :

    >>346
    返信ありがとう御座います!
    早速試したら出来ました。けどなぜ動くのかわからない…
    因みに使ってるのNSLという言語です。ハードウェア記述言語なのは一緒ですかね

    348 = :

    >>347
    dataが置換された後に再走査されてsが置換されるから動く。
    だから#define s ' が動けば、問題なく動く。

    349 = :

    >>348
    プリプロセッサってプロトタイプ宣言みたいに上から順に~ってわけではないのか。一緒だと思ってました


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / gcc一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について