Mail Archives: djgpp-workers/2001/04/27/15:15:12
> Are you sure? Here's what I see in the assembly of a file whose name
> was passed to GCC as an absolute file name:
>
> .file "command.c"
> gcc2_compiled.:
> ___gnu_compiled_c:
> .stabs "d:/usr/djgpp/gnu/less-340/",100,0,0,Ltext0
> .stabs "d:/usr/djgpp/gnu/less-340/command.c",100,0,0,Ltext0
>
> and here's what I see for a file whose name was simply command.c:
>
> .file "command.c"
> gcc2_compiled.:
> ___gnu_compiled_c:
> .stabs "d:/usr/djgpp/gnu/less-340/",100,0,0,Ltext0
> .stabs "command.c",100,0,0,Ltext0
>
> To me, this looks like the first entry is the leading directory, while
> the second is supposed to be the basename.
Close - first is the current dir, second is the path passed.
With cwd=E:/Tmp, containing foo.c, I tried
gcc -S foo.c
gcc -S ../tmp/foo.c
gcc -S /tmp/foo.c
gcc -S e:/tmp/foo.c
gcc -S e:\tmp/foo.c
gcc -S e:\tmp\foo.c
In each case, the first entry was "e:/Tmp/", and the second the path
exactly as passed (with backslashes preserved).
objdump -g shows as filenames for the above:
E:/Tmp/foo.c
E:/Tmp/../tmp/foo.c
/tmp/foo.c
e:/tmp/foo.c
e:\tmp/foo.c
e:\tmp\foo.c
So I cannot reproduce the bug (either with my local cvs binutils, or Mark's
2.11 package)
In any case, using the basename would be wrong, as that would break debug
info for files compiled in a subdir (gcc -c foo/bar.c would produce a
reference to $CWD/bar.c instead of $CWD/foo/bar.c).
- Raw text -