アカウント名:
パスワード:
その結果定数メモリへの書き込みが発生するのがバグ
組み込みやってるとconst領域はROMに確保されるのが当たり前だったのでconst付シンボルの中身を書き換えてるソース見て何だこりゃ？って思ったっけ。(そのソースをそのまま組み込み機に移植したら動かなくなったのを思い出した)
#それを相性問題で片づけたのはうちの上司#(Windowsプログラマ部隊より立場弱くて、更に「実績のあるソースだからそのまま使え」の通達付きだった)
組み込みで使われがちなbusyboxもこのバグを踏んでいたというのがなんとも
>const領域はROMに確保されるのが当たり前それをリンカに指定するまでが組み込みプログラマの責任セクションて知ってる?(方言でセグメントと言うかもしれん)それにしてもすごい会社だなそこ
ところで、定数が定数であることはだれの責任なんでしょう？
当時とった解決策(既設ソースは変更不可のため)。RAMが無駄に余裕があったので、全セクションをROMに配置したのち起動時にROM領域を全部RAMにコピーしてジャンプする疑似ブートローダーのバイナリ作ってビルド済みライブラリとしてROMイメージにくっつけた。
#要はPC(Windows)と同じくconstも初期値付き変数も、全部RAM上ならいいんでしょ。となった。#後にGPIOの空き端子にジャンパピンが追加され、新旧2種類のROMイメージから起動できるようになった。#当然最初の要求仕様にはない追加仕様で泣きつかれた結果である
>PC(Windows)と同じくMMUがREADONLYにしているんだよw
>Nの社風なんだろうか？
これはぜってーH社じゃない、F社なんかあり得んだろと思って読んでたらほーらやっぱり
それが、できるならまだ恵まれてる。大昔担当した官公庁向けシステムで同様のパターンの時はそれすらRAM不足で不可でした。(後述のT社とは別件)結局、当該ソースにバグ回避用ラッパー(バグ条件に合致したら制御を乗っ取る)や、それでも回避できない部分は、(現場担当者に断って)闇パッチで対応したり。
#当該システムは設置された施設ごと
その会社の調達のルートではNANDなROMが高いとか。
しまった、間違えた。
×NAND○NOR
ははは、俺が参加したNのプロジェクトもRAMが空いててROMの一部をRAMに移動してた。
最近、破綻するプロジェクトのニュースをよく見るので、IT奴隷ばっかりが増えてプログラマーがいなくなったのかと嘆いていましたが、ここのコメントを見る限りプログラマーが健在だと安心しました。というか、皆さん現役ですよね。2000年ごろの話してませんよね。(X68000とかは明らかに90年代だけど)
(X68000とかは明らかに90年代だけど)
80年代やぞ
年取るとね、昔語りばかりするようになるんですよ。あと10年程度ならつい最近とか思っちゃうの。年取るってほんと怖いんだよ。
自分の中じゃあんときのまんまだもんねいまだにテイラー・スウィフトとか聞いて萌え萌えしてるかんなー意図して September [youtube.com] とか避けてる
自分が萌え萌えしたのは、読込みはROMから、そのアドレスに書込むとRAMに書き込むというコメントかな。Z80のR/W端子を思い出して、ああ昔はいろいろできたなぁ。って懐かしくなった。(今もできるだろうが、モジュール化・ワンチップ化されている今では、コストばかりかかって非現実)
本当に組み込みの方?
今回の話は、コンパイラでどの変数をどのセクションに割り当てるかという段階の話でリンカ云々以前の段階です。そして、固定データを格納するセクションに割り当てられていれば、多くの組み込みではROMに割り当てられるというだけです。
>本当に組み込みの方?
おっおぅ、ExcelVBAにシリアルI/OやTCP/IP実装したりする変態的な組み込みの方だぞ。(こうゆう変態的要求仕様を出して来るのはNだけだとは思いたい)セクション切るのはリンカオプションだったが、この辺は開発環境によるのかな(当時使ってたHEWではリンカオプションだった)
const外すのも、#pragma section切るのもNに却下された。今にして思えば、stdio.hあたりをプロジェクト内部にもってそこでセクション切ってゴニョゴニョしたらブートローダーを2段に噛ますようなアクロバットはしなくて済んだかも。
>それをリンカに指定するまでが組み込みプログラマの責任
あまり良くわかっていなくて申し訳ないのですが…。以下のようなものかなと思うのですが、
const int *v = (void *) 0xFFFFE0000;(int *)v = 1;
リンカがどう関係するのでしょうか？
ポインタ経由すればconst付きで宣言した変数の書換だってできますからね。まあROMに書き込見たいときとか値を固定したいときはdefine使えと。
> ポインタ経由すればconst付きで宣言した変数の書換だってできますからね。
それ処理系依存GCC とかだと最適化のオプション次第ですけど普通に使ってれば SegFault です。
処理系依存ではない。書き換えは未定義動作。「any attempt to modify a const object during its lifetime (3.8) results in undefined behavior.」
未定義動作は処理系がどのように実装しても構わないのだから、処理系依存で間違ってないと思うが。
同じ処理系でも、ROMイメージを作るために使う人もいるし、領域保護機能を備えたOS上のアプリをコンパイルする人もいるし、ROデータセクションに割り付けたか .textかでも違うだろうし、処理系が同じだからといっておなじ挙動にするには無理があるので、未定義動作にするしかない。
処理系が実装しなくてもいいので未定義なのです。普通実装しちゃうんだけど。
constからdefineに戻れと・・・。それは流石に方向性間違ってませんか・・・。
define undef defineで値を変更できるので定数化にもなりませんし
シンボル参照点では不変の定数だよ。一貫性がないだけで(オイ
boot時は、読み出しはROMでも書き出しはRAMに書かれ,ROMをdisableするとその後はRAMから読み出すようになるっていうのはあったような。まぁ、そういうエリアをconst修飾するってことは少ないでしょうけど、ROMのアクセスは遅かったのでROなセクションでもRAMに展開する意義はあった。
X68000がそんな感じだった覚えがあります速度というよりはベクターテーブルを書き換え可能にするためだったかな※ベクターテーブルも含めた先頭から64kbの領域にIOCS(BIOS)をROMとしてマップしてた
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
キャストでconstを外すのがバグではなく (スコア:1)
その結果定数メモリへの書き込みが発生するのがバグ
Re:キャストでconstを外すのがバグではなく (スコア:1)
組み込みやってるとconst領域はROMに確保されるのが当たり前だったのでconst付シンボルの中身を書き換えてるソース見て何だこりゃ？って思ったっけ。
(そのソースをそのまま組み込み機に移植したら動かなくなったのを思い出した)
#それを相性問題で片づけたのはうちの上司
#(Windowsプログラマ部隊より立場弱くて、更に「実績のあるソースだからそのまま使え」の通達付きだった)
Re: (スコア:0)
組み込みで使われがちなbusyboxもこのバグを踏んでいたというのがなんとも
Re: (スコア:0)
>const領域はROMに確保されるのが当たり前
それをリンカに指定するまでが組み込みプログラマの責任
セクションて知ってる?
(方言でセグメントと言うかもしれん)
それにしてもすごい会社だなそこ
Re: (スコア:0)
ところで、定数が定数であることはだれの責任なんでしょう？
当時とった解決策(既設ソースは変更不可のため)。
RAMが無駄に余裕があったので、全セクションをROMに配置したのち
起動時にROM領域を全部RAMにコピーしてジャンプする疑似ブートローダーのバイナリ作って
ビルド済みライブラリとしてROMイメージにくっつけた。
#要はPC(Windows)と同じくconstも初期値付き変数も、全部RAM上ならいいんでしょ。となった。
#後にGPIOの空き端子にジャンパピンが追加され、新旧2種類のROMイメージから起動できるようになった。
#当然最初の要求仕様にはない追加仕様で泣きつかれた結果である
Re: (スコア:0)
>PC(Windows)と同じく
MMUがREADONLYにしているんだよw
Re: (スコア:0)
>Nの社風なんだろうか？
これはぜってーH社じゃない、F社なんかあり得んだろと思って読んでたら
ほーらやっぱり
Re: (スコア:0)
ところで、定数が定数であることはだれの責任なんでしょう？
当時とった解決策(既設ソースは変更不可のため)。
RAMが無駄に余裕があったので、全セクションをROMに配置したのち
起動時にROM領域を全部RAMにコピーしてジャンプする疑似ブートローダーのバイナリ作って
ビルド済みライブラリとしてROMイメージにくっつけた。
それが、できるならまだ恵まれてる。大昔担当した官公庁向けシステムで同様のパターンの時はそれすらRAM不足で不可でした。(後述のT社とは別件)
結局、当該ソースにバグ回避用ラッパー(バグ条件に合致したら制御を乗っ取る)や、それでも回避できない部分は、(現場担当者に断って)闇パッチで対応したり。
#当該システムは設置された施設ごと
Re: (スコア:0)
その会社の調達のルートではNANDなROMが高いとか。
しまった、間違えた。
×NAND
○NOR
Re: (スコア:0)
ははは、俺が参加したNのプロジェクトもRAMが空いててROMの一部をRAMに移動してた。
Re: (スコア:0)
最近、破綻するプロジェクトのニュースをよく見るので、IT奴隷ばっかりが増えてプログラマーがいなくなったのかと嘆いていましたが、ここのコメントを見る限りプログラマーが健在だと安心しました。
というか、皆さん現役ですよね。2000年ごろの話してませんよね。
(X68000とかは明らかに90年代だけど)
Re: (スコア:0)
(X68000とかは明らかに90年代だけど)
80年代やぞ
Re: (スコア:0)
年取るとね、昔語りばかりするようになるんですよ。
あと10年程度ならつい最近とか思っちゃうの。
年取るってほんと怖いんだよ。
Re: (スコア:0)
自分の中じゃあんときのまんまだもんね
いまだにテイラー・スウィフトとか聞いて萌え萌えしてるかんなー
意図して September [youtube.com] とか避けてる
Re: (スコア:0)
自分が萌え萌えしたのは、読込みはROMから、そのアドレスに書込むとRAMに書き込むというコメントかな。
Z80のR/W端子を思い出して、ああ昔はいろいろできたなぁ。って懐かしくなった。
(今もできるだろうが、モジュール化・ワンチップ化されている今では、コストばかりかかって非現実)
Re: (スコア:0)
本当に組み込みの方?
今回の話は、コンパイラでどの変数をどのセクションに割り当てるかという段階の話でリンカ云々以前の段階です。
そして、固定データを格納するセクションに割り当てられていれば、多くの組み込みではROMに割り当てられるというだけです。
Re: (スコア:0)
>本当に組み込みの方?
おっおぅ、ExcelVBAにシリアルI/OやTCP/IP実装したりする変態的な組み込みの方だぞ。
(こうゆう変態的要求仕様を出して来るのはNだけだとは思いたい)
セクション切るのはリンカオプションだったが、この辺は開発環境によるのかな(当時使ってたHEWではリンカオプションだった)
const外すのも、#pragma section切るのもNに却下された。
今にして思えば、stdio.hあたりをプロジェクト内部にもって
そこでセクション切ってゴニョゴニョしたらブートローダーを2段に噛ますようなアクロバットはしなくて済んだかも。
Re: (スコア:0)
>それをリンカに指定するまでが組み込みプログラマの責任
あまり良くわかっていなくて申し訳ないのですが…。
以下のようなものかなと思うのですが、
const int *v = (void *) 0xFFFFE0000;
(int *)v = 1;
リンカがどう関係するのでしょうか？
Re: (スコア:0)
ポインタ経由すればconst付きで宣言した変数の書換だってできますからね。
まあROMに書き込見たいときとか値を固定したいときはdefine使えと。
Re: (スコア:0)
> ポインタ経由すればconst付きで宣言した変数の書換だってできますからね。
それ処理系依存
GCC とかだと最適化のオプション次第ですけど普通に使ってれば SegFault です。
Re: (スコア:0)
処理系依存ではない。書き換えは未定義動作。「any attempt to modify a const object during its lifetime (3.8) results in undefined behavior.」
Re: (スコア:0)
未定義動作は処理系がどのように実装しても構わないのだから、処理系依存で間違ってないと思うが。
Re: (スコア:0)
同じ処理系でも、ROMイメージを作るために使う人もいるし、領域保護機能を備えたOS上のアプリをコンパイルする人もいるし、ROデータセクションに割り付けたか .textかでも違うだろうし、処理系が同じだからといっておなじ挙動にするには無理があるので、未定義動作にするしかない。
Re: (スコア:0)
処理系が実装しなくてもいいので未定義なのです。
普通実装しちゃうんだけど。
Re: (スコア:0)
constからdefineに戻れと・・・。それは流石に方向性間違ってませんか・・・。
Re: (スコア:0)
define undef defineで値を変更できるので定数化にもなりませんし
Re: (スコア:0)
シンボル参照点では不変の定数だよ。一貫性がないだけで(オイ
Re: (スコア:0)
boot時は、読み出しはROMでも書き出しはRAMに書かれ,ROMをdisableするとその後はRAMから読み出すようになるっていうのはあったような。
まぁ、そういうエリアをconst修飾するってことは少ないでしょうけど、ROMのアクセスは遅かったのでROなセクションでもRAMに展開する意義はあった。
Re: (スコア:0)
X68000がそんな感じだった覚えがあります
速度というよりはベクターテーブルを書き換え可能にするためだったかな
※ベクターテーブルも含めた先頭から64kbの領域にIOCS(BIOS)をROMとしてマップしてた