なんとかなるさね

マイコンをネタにブログを始めてみました


スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

--/--/--   blog-entry-   category: スポンサー広告

go page top

RL78マイコン(RL78/G13)|rl78-elf-gccが生成するアセンブラソースもデバッグ情報を含んでいる 

私のPCのWindowsにはタスクマネージャを常駐させていますが、前のエントリでWindows上のMSYS2環境で
rl78-elf-gccをビルドした時、それなりに時間が掛かっていたので何気に、ふとタスクマネージャを見てみると
g++.exeだけでなくcc1plus.exeとかas.exeとかが起動/終了を繰り返していることに気付きました。その時、
以前にInterface誌の記事で、GCC本体はアセンブラソース(.s)を生成するところまでしか行わずオブジェクト
ファイル(.o)を生成することはGCCが内部的にGASを呼び出してGASが行っている、というのを読んだことが
あったのを思い出したのですが、暫くして、デバッグ情報もアセンブラソース経由で引き渡されているような
気がするけれどもどうなのだろう、ということが気になって来ました。

そこでe2 studioのKPIT GNURL78の設定画面を探すと "一時的な中間ファイルを削除しない (-save-temp)"
という項目があり、試しにチェックマークを付けてビルドしたところアセンブラソースが生成されるように
なり、ソースを見たところデバッグ情報がデータ定義擬似命令(.byteや.4byteなど)で引き渡されていました。
(前のエントリでのrl78-elf-readelf.exeによるダンプ結果も併記しておきます。プログラムは同じものです。)

auto変数a00に関するデバッグ情報

今回の-save-tempオプションで得たアセンブラソース

TestKpitGnuRL78.s

    .section    .debug_info,"",@progbits
.Ldebug_info0:
    途中省略
    .uleb128 0x3
    .string "a00"
    .byte   0x1
    .byte   0x3d
    .4byte  0x22f
    .byte   0x2
    .byte   0x91
    .sleb128 -6
 以後省略


前のエントリでのrl78-elf-readelf.exeによるダンプ結果

debuginfo.dmp

Contents of the .debug_info section:

 途中省略
 <2><14f>: Abbrev Number: 3 (DW_TAG_variable)
    <150>   DW_AT_name        : a00
    <154>   DW_AT_decl_file   : 1  
    <155>   DW_AT_decl_line   : 61  
    <156>   DW_AT_type        : <0x22f>
    <15a>   DW_AT_location    : 2 byte block: 91 7a     (DW_OP_fbreg: -6)
    以後省略


追記 : メモ

今回のKPIT GNURL78 GCCの-save-tempオプションですが、一時的な中間ファイルを削除しない、という
機能になっていますが、CC-RLコンパイラの、アセンブリソースファイルを出力する、というオプションと、
プリプロセス処理したソースを出力する、というオプションが一緒になった機能に相当するものと捉えて良さ
そうです。

なお、以下の画面コピーは、e2 studioのKPIT GNURL78の設定画面(の一部分)とCC-RLの設定画面(の一部分)、
及びCS+(旧CubeSuite+)のCC-RLの設定画面(の一部分)です。(ちなみに、e2 studioのCC-RLの設定画面には
他の部分を探してみても、プリプロセス処理したソースを出力する、というオプションがありませんでした。)





追記 : メモ

以前にInterface誌で読んだものは、本棚を探したところ、以下の連載記事の中にありました。(なお、PDFは
記事の1ページ目だけです。)

2012年5月号(pp.140-145,邑中雅樹氏執筆)
教科書には載っていない! 現場で役立つプログラミングのちょい技
第5回 コンパイラの中では何が起こっているの?
http://www.kumikomi.net/interface/sample/201205/if05_140.pdf
http://www.kumikomi.net/interface/contents/201205.php

そこで読み直してみたところ、GCC本体がアセンブラソースを生成するところまでしか行わないのは、以下の
歴史的な事情が大きな要因の1つである、といったことも書かれていました。

・GCCが誕生した頃(GCCが一般的になる前)は各社OS上に各社独自のコンパイラツールチェインが存在した
・バイナリフォーマットは、今のELF/DWARFのような標準は存在せず、情報が非公開の場合も少なくなかった
・そこでGCCは情報が公開されているアセンブリ言語で出力を行い、後は各社のツールに任せることにした
・今ではELF/DWARFやbinutilsを採用する例が一般的だが、今でもMac OS XやiOSといった身近な例外がある
 (理由はMac OS XやiOSはELF/DWARFでは無くMach-Oという独自のバイナリフォーマットを用いている為)

追記 : メモ

ちなみに、Interface誌2012年5月号は「特集 パソコン上のシミュレータで組み込み向けOSまで動く」でした。
それで思い出したのですが、この特集記事を読んだことがきっかけで、以下のエントリを書いていました。

[160] CubeSuite+ | e2studio + CubeSuite+ Sim / HEW Sim / SM+ / GDB Simの組み合わせ

関連記事

2016/06/30   blog-entry-789   category: RL78 /* 16bit,8bit CISC */

go page top

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。