https://sourceware.org/bugzilla/show_bug.cgi?id=30206
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nickc at redhat dot com
--- Comment #1 from Nick Clifton <nickc at redhat dot com> ---
Hi Ilya,
(In reply to Ilya Leoshkevich from comment #0)
> .byte 0x90
> 3: 90 nop
> Note that nop does not get a line number.
Except that it is not a NOP instruction. Instead it is a piece of data
whose value happens to be the same as that of a NOP instruction.
> Using .insn instead of .byte helps, but I would like to understand whether
> this is intentional?
Yes, I think so. If you want to insert arbitrary binary values as if
they were instructions then using .insn is the right way to go. Using
.byte (or .short or .long, or any of the other similar pseudo-ops) really
implies that you are inserting data values.
That said, there is nothing that says that data in an executable section
should not have DWARF line information associated with it. (In fact there
is an argument that any data, in any loadable section, should be allowed
to have line information associated with it, but that is a separate issue).
But .. if we did change the behaviour of the assembler to generate this
extra line information, I am pretty sure that we would upset a lot of
people. At least if we did so by default. We could I suppose, add a
command line option to control the behaviour, eg: -gdwarf-line-info-for-data ?
But I also wonder if it would actually be used by anyone.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
