Wrong file name entry in .debug_info section
kamlesh kumar
kamleshbhalui@gmail.com
Mon Aug 6 09:01:00 GMT 2018
Thank you Nick for the inputs and we do understand that the multiple
.file directives confuse the assembler and it takes from the
command-line..
Consider our case hello.s
<https://gist.github.com/kamleshbhalui/ef391b040bcfa514048a2ae680a1eafd>
where used added .file directive in the source and -P is passed for
gcc driver to inhibit the line directives ,in this case we expect
assembler to take the filename from .file directive that was coded in
the asm file by user .
we would like to know your take here or comments ?
Thank you
On Fri, Aug 3, 2018 at 4:10 PM, Nick Clifton <nickc@redhat.com> wrote:
> Hi Kamlesh,
>
> > gcc -g -c -xassembler-with-cpp -P hello.s
> > readelf --debug-dump hello.o | grep DW_AT_name
> >
> > I get following:
> >
> > DW_AT_name :/tmp/cc8P6Tw2.s
> >
> > which is a temporary file generated by compiler now no more exist.>
> > Why gas is putting wrong file name there.
>
> Because that is the name of the input file that is passed to the assembler.
>
> You can work around this in a rather cumbersome fashion by saving the
> compiler's
> output into a temporary file of your own that is named after the input
> file:
>
> gcc -g -S -xassembler-with-cpp -P hello.s > /tmp/hello.s
> gcc -g -o hello.o /tmp/hello.s
> readelf --debug-dump hello.o | grep DW_AT_name
>
> <20> DW_AT_name : (indirect string, offset: 0x0): /tmp/hello.s
>
> And of course you can play games with temporary directories in
> order to get rid of the /tmp/ prefix to the DW_AT_name value.
>
>
> > Even if compiler put *.file="hello.s" * at top of hello.s .
> > why gas is not using that info?
>
> Because there can be multiple .file directives in a single assembler source
> file, so the assembler does not know which one to choose. Nor does it know
> that the input file name is incorrect. The user might very well have
> created
> a file called cc8P6Tw2.s, it is not for the assembler to decide that this
> name
> is invalid.
>
> Cheers
> Nick
>
More information about the Binutils
mailing list