search for: special_lit_sym

...If so, how can I fix it? It's somewhere between a bug and a quality-of-implementation issue. ARM often uses literal pools in the middle of code when it needs to materialize a large constant (or variable address more likely for R_ARM_ABS32). This results in a sequence roughly like: ldr r0, special_lit_sym [...] b past_literals special_lit_sym: .word variable_desired past_literals: [...instructions...] In general, deciding whether to disassemble a given location as code or data is a very hard problem (think of all the evil tricks you could play with dual-purpose), so the ARM ELF ABI...

I'm attempting to detect encoding bugs by comparing disassembly when using GCC's 'as' versus LLVM's integrated assembler. Generally this has gone very well, but one thing that adds a lot of noise is that .word marked as a R_ARM_ABS32 is disassembled as an instruction and not data. Please see the attached 'dump.diff' which was generated by diffing the "objdump -d

...; It's somewhere between a bug and a quality-of-implementation issue. > ARM often uses literal pools in the middle of code when it needs to > materialize a large constant (or variable address more likely for > R_ARM_ABS32). This results in a sequence roughly like: > > ldr r0, special_lit_sym > [...] > b past_literals > special_lit_sym: > .word variable_desired > past_literals: > [...instructions...] > > In general, deciding whether to disassemble a given location as code > or data is a very hard problem (think of all the evil tricks you could &gt...