Menu
▾
▴
#176 Negative relocations (bin)
Writing code like
mov ax, word [ bx - label ]
or just
dw (- label)
does not work. It generates the error "beroset-p-637-invalid effective address" (presumably because e->value in the relevant check is -1 instead of 1). I believe supporting negative relocations in the bin output format would be useful.
Right now, the front end doesn't support any relocations with a multiplier other than 1. In this case, it would require the front end to be able to generate a multiplier and for the backends which could accept it (including, of course, bin) to be able to receive it -- and for those that can't to reject it correctly.
I'm crawling through the NASM source right now and conceiving a hack which would allow bin to use a multiplier of -1 (i.e. just a negative offset) but I'm not very used to the source. Will tell if I get a working patch, though support for multipliers other than 1 and -1 as you suggested would probably be the better solution.
Attaching a patch for such a hack. Very primitive though, and not all other output formats correctly handle unknown out_type values as I thought. (Thus my comment next to the enum's definition of OUT_ADDRESSNEG is wrong, and using this with non-bin output formats silently creates a wrong binary.) Support of the negative relocations wasn't added to db yet. The way the "negative relocation" status is passed down to the output format is somewhat crude...
OTOH, simple test cases with instructions accessing memory passed with this, so it shows that it *can* be done with some effort. (It also shows how it should *not* be done.)
Crude hack for negative relocations (bin output, mem-accessing instructions only)
Also, it's normal that the warning "negative relocation handled in parser" is displayed multiple times. That's probably one time per pass because the instruction will be parsed each pass.
The hack for outbin.c, forgot that
Any implementation of this which hard-codes things as "negative" is just wrong. It's a special case of "multiplier * symbol" and should be treated as such (in this case, the multiplier is -1).
Agreed, but I probably won't be able to get it done correctly and with a nice interface anyway.
I'll try to take a look on weekend but no promises ;)
One thing I think we need in general is a way to tell the front end what a particular back end supports -- we have too many cases like this which make the front end/back end interface hard to evolve. I'm thinking some kind of feature bits or even a bitmask of the output types a specific backend supports. Trying to issue a different type would give an error.
Negative relocations are not supported in any of the object file formats I have seen. You probably need a self-relative relocation.
See feature request # 196
https://sourceforge.net/p/nasm/feature-requests/196/
Negative relocations are not possible in any of the object file format I have seen.
You probably need a self-relative relocation. See feature request 196
https://sourceforge.net/p/nasm/feature-requests/196/
Yes. And?
Besides, as you likely know, the bin output format of NASM isn't exactly an object format. It is more akin to a linker's output format.
I do not. I now and then find cases where relocations with multipliers other than one would be useful, even beyond what can be covered by the specific case of self-relative relocations.
Last edit: C. Masloch 2013-07-26