Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-1453093 ] relocation error (peephole)
|
From: SourceForge.net <no...@so...> - 2006-03-29 18:41:57
|
Bugs item #1453093, was opened at 2006-03-18 13:40 Message generated for change (Comment added) made by stsp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1453093&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: msc51(8051) target Group: fixed Status: Open Resolution: Fixed Priority: 5 Submitted By: Stas Sergeev (stsp) Assigned to: Maarten Brock (maartenbrock) Summary: relocation error (peephole) Initial Comment: Hi. The following program (attached) cannot be compiled with the sdcc code from CVS: --- static idata unsigned char f[1]; static unsigned char tst; unsigned char main() { idata unsigned char *ptr = f; while (ptr < f) tst = *ptr++; return tst; } --- $ sdcc ptrbug.c ?ASxxxx-Error-<r> in line 137 of ptrbug.asm <r> relocation error removing ptrbug.rel ---------------------------------------------------------------------- >Comment By: Stas Sergeev (stsp) Date: 2006-03-29 22:41 Message: Logged In: YES user_id=501371 > The expression in the asm-file says: substract a > relocatable address from a constant. That's not possible > while a Well, the point was that, eg. gas allows the things like "movw $5-var, %si" I was assuming that this is a similar thing, except for the '$' being '#' in asx8051. Is this wrong? > A "offset" operator would be great. It thought '#' is enough to make it clear that we want an offset. At least gas seem to understand that with '$', but I am probably misunderstanding the meaning of '#' in asx8051 then. ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2006-03-29 21:58 Message: Logged In: YES user_id=1160854 The reason for the error message is correct. The expression in the asm-file says: substract a relocatable address from a constant. That's not possible while a constant offset is. "while (ptr < (f + 1))" for example works because of that. A "offset" operator would be great. Never the less the optimations should be placed in genCmpXX as Frieder said. ---------------------------------------------------------------------- Comment By: Stas Sergeev (stsp) Date: 2006-03-29 21:40 Message: Logged In: YES user_id=501371 > The lastest snapshot from maarten solves the problem by an > extra check! Yes, but the *old* asm (which is now attached) still doesn't compile, while you said it should. C test-case now compiles, yes, but the optimization was reduced, and overall I can't help feeling that the root of the problem is not addressed. Now, if it will appear to be the assembler bug after all, I think the Maarten's patch will only reduce the optimization for no good at all. :) Well, I may be completely wrong, just want to be sure... ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2006-03-29 21:16 Message: Logged In: YES user_id=1160854 The lastest snapshot from maarten solves the problem by an extra check! ---------------------------------------------------------------------- Comment By: Stas Sergeev (stsp) Date: 2006-03-29 21:06 Message: Logged In: YES user_id=501371 > But I think if all > 132.x rules are changed something like #(0x100 - %2) it > should work. If so, this was a peephole bug after all. But I tried "#(0x100 - _f)" and I tried "(0x100 - #_f)" and some other less sensible combinations, and neither works - the same error all the time. So I keep speculating - its an assembler bug! :) Now, because of the recent patch-work, I am attaching another test-case - an asm file produced by an unpatched sdcc. I think it should compile. --- $ asx8051 ptrbug.asm ?ASxxxx-Error-<r> in line 137 of ptrbug.asm <r> relocation error removing --- ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2006-03-29 19:17 Message: Logged In: YES user_id=888171 Hmmm, I have committed my fix, but now I start wondering if it isn't just all about parentheses. Unfortunately I have no time untill the weekend to try this out. But I think if all 132.x rules are changed something like #(0x100 - %2) it should work. If so, this was a peephole bug after all. But for now the problem is fixed in SDCC 2.5.5 #1232. I'll keep the report open though. ---------------------------------------------------------------------- Comment By: Stas Sergeev (stsp) Date: 2006-03-28 23:39 Message: Logged In: YES user_id=501371 > It should > work too, that's right - but it causes the bug... So is this an assembler bug after all, not codegen/peephole? ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2006-03-28 22:08 Message: Logged In: YES user_id=888171 I'm sorry. I already wrote a fix like b) but I must have forgotten to commit it. I'll test it again this evening and commit. ---------------------------------------------------------------------- Comment By: Stas Sergeev (stsp) Date: 2006-03-28 22:08 Message: Logged In: YES user_id=501371 > causes the relocation error "mov a,#0x100 - _f" Yes, but why is this a problem? From my (rather ignorant in that area) point of view, #(_f + 20) is not too much different from #(0x100 - _f). Since the offset of _f is constant, why the '-' sign makes it invalid? ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2006-03-28 22:07 Message: Logged In: YES user_id=1160854 The replaced lines should use %1 and %2 in the sequence like the original ones. At peepholes d / e / f "%1" and "%2" are changed. It should work too, that's right - but it causes the bug... ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2006-03-28 21:26 Message: Logged In: YES user_id=589052 > Could you please clarify/confirm that its a peephole's > fault? I am quite ignorant about that asm semantic, but > I suspect that maybe an assembler is really guilty here? The problem with peephole 132.e was that it was applied to a symbol (resulting in a negative sign before a symbol, which causes the relocation error "mov a,#0x100 - _f") > and perhaps it would be better to leave this bug > open for now? If it is closed, then it is likely > to never be properly addressed. :( You're right - reopened. There are probably three approaches to address it (in the order of my preference) : a) modifying genCMP that it includes the tricks of 132.a-e, b) introduce an additional Peephole condition checking for non_symbols, c) remove 132.a-d (most likely an overkill as SDCC probably doesn't generate code which would match the peephole AND is using a symbol). ---------------------------------------------------------------------- Comment By: Stas Sergeev (stsp) Date: 2006-03-28 20:57 Message: Logged In: YES user_id=501371 > fixed with SDCC version #1230 by disabling peephole 132.e Could you please clarify/confirm that its a peephole's fault? I am quite ignorant about that asm semantic, but I suspect that maybe an assembler is really guilty here? > Note: peepholes 132.a-d are still lurking there. Exactly - thats what I did locally too, but thats the problem, and perhaps it would be better to leave this bug open for now? If it is closed, then it is likely to never be properly addressed. :( > Ideally the > optimizations of rules 132.x should be done in genCmpXX But are you sure that the assembler should not be fixed instead? ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2006-03-28 10:37 Message: Logged In: YES user_id=589052 fixed with SDCC version #1230 by disabling peephole 132.e Note: peepholes 132.a-d are still lurking there. Ideally the optimizations of rules 132.x should be done in genCmpXX ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1453093&group_id=599 |