[Bug ld/3998] Weird path problem
--- Additional Comments From nickc at redhat dot com 2007-02-16 09:07 --- Not really a bug, more of a problem with cross environments -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=3998 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4045] objdump -m avr -D prefixes memory addresses with "0x0x" in comments
--- Additional Comments From nickc at redhat dot com 2007-02-16 09:47 --- Created an attachment (id=1558) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1558&action=view) Second revision of the patch -- http://sourceware.org/bugzilla/show_bug.cgi?id=4045 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4045] objdump -m avr -D prefixes memory addresses with "0x0x" in comments
--- Additional Comments From nickc at redhat dot com 2007-02-16 09:47 --- Hi Timo, Ok, please try the third version of this patch. Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=4045 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4045] objdump -m avr -D prefixes memory addresses with "0x0x" in comments
--- Additional Comments From timo dot lindfors at iki dot fi 2007-02-16
10:17 ---
All three cases seem to work now, thanks!
The only minor issue (just ignore it if you don't have extra time) I see is that
the addresses are prefixed with one extra space so that addresses and other
immediate values are not aligned in comments:
12c: 8d 33 cpi r24, 0x3D ; 61
12e: e0 f3 brcs.-8 ; 0x128
130: 18 ba out 0x18, r1; 24
132: 19 be out 0x39, r1; 57
134: 1b ba out 0x1b, r1; 27
136: d4 cf rjmp.-88; 0xe0
where "; 0x128" would be preferred.
Btw, on x86 symbol names are not in comments ("call 18 "), do you
think that the output should be somehow harmonized to be similar on all
architectures?
--
http://sourceware.org/bugzilla/show_bug.cgi?id=4045
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4045] objdump -m avr -D prefixes memory addresses with "0x0x" in comments
--- Additional Comments From nickc at redhat dot com 2007-02-16 10:21
---
Hi Timo,
> The only minor issue (just ignore it if you don't have extra time) I see is
> that
> the addresses are prefixed with one extra space so that addresses and other
> immediate values are not aligned in comments:
>
> 12c: 8d 33 cpi r24, 0x3D ; 61
> 12e: e0 f3 brcs.-8 ; 0x128
Yes, I was aware of this, but I was hoping that it might be regarded as a
feature - making addresses stand out.
> Btw, on x86 symbol names are not in comments ("call 18 "), do you
> think that the output should be somehow harmonized to be similar on all
> architectures?
Yes - this whole body of code needs to be cleaned up and possibly rewritten, but
that will have to wait for when someone has lots of free time. :-)
Cheers
Nick
--
What|Removed |Added
Status|WAITING |RESOLVED
Resolution||FIXED
http://sourceware.org/bugzilla/show_bug.cgi?id=4045
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: GOT error in gas
Hi Mikulas, I see but gas should at least write error and not generate incorrect code. In which case please could you create a bugzilla entry for this so that we can track this problem properly. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: GOT error in gas
Hi
Hi Mikulas,
__asm__ (".global number; number = 0x12345678");
extern void number;
These two declarations are not compatible. The latter declares number as
a data symbol, but the former defines it is an absolute symbol.
I thought that .types do not care for linking,
Andreas is not talking about .types. He is talking about the sections to
which the symbol belongs. Writing "extern void number" declares "number" as
a symbol that will live in the .data section(1). The address of "number" is
not known until the linker has performed a final link (for static code) or
the loader has initialised the executable (for PIC code).
Writing "__asm__(".global number; number=0x12345678")" however declares
"number" as a symbol with an absolute *address*. The symbol does not have a
value, or rather its value is whatever happens to be in the memory location
0x12345678. This symbol does not live in a section, and its address does not
change during linking or loading.
I know --- but in the example I posted I am just taking its address (which
should be 0x12345678), I am not taking value of that variable (that should
segfault on access to 0x12345678). But taking address shouldn't segfault.
I looked at gas code --- fixing it to stop evaluating constant symbols for
@GOT expressions seems to be hard or impossible because expression
evaluation function doesn't know that there is "@GOT" following.
--- but there is another issue --- @GOT is completely ignored if
expression is constant.
Note that
movl [EMAIL PROTECTED], %eax
shouldn't put 123 to eax but an offset in GOT where 123 is stored. Gas
should either write error or make symbol with absolute value 123 and
output relocation against it.
movl [EMAIL PROTECTED], %eax
will correctly output internal symbol name ("L0\001") as relocation, so
movl [EMAIL PROTECTED], %eax could do just the same trick, setting "L0\001" to
absolute value --- static or dynamic linker will handle it correctly.
Hence the two declarations are inconsistent and you get undefined behaviour.
How otherwise should external C variables be placed at absolute locations?
You could adapt the mechanism that you already have. You say that everything
works if the __asm__ statement is in a separate compilation unit, so just
split out all of your absolute C variables into one (or more) separate files
and have a header file containing "extern void..." declarations for them.
I see but gas should at least write error and not generate incorrect code.
Mikulas
Alternatively you could provide the addresses for these symbols via a linker
script, rather than trying to define them in C. For example:
% cat addr.t
number = ABSOLUTE (0x12345678);
% cat test.c
#include
extern void number;
int main (void) { return printf ("%p\n", & number); }
% gcc test.c -Wl,addr.t -fPIC
% ./a.out
0x12345678
Cheers
Nick
(1) Or some similar section such as .common or .sdata.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4041] Objcopy doesn't remove empty program header
--- Additional Comments From hjl at lucon dot org 2007-02-16 23:28 --- It is informational, nothing more. -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://sourceware.org/bugzilla/show_bug.cgi?id=4041 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
binutils-2.15.92.0.2 -M script truncates file names
I had some problems building VirtualBox on a RedHat 3 ES machine, The "ar" command failed to find an input file -- the message shows a truncated name compared to what is in the script fed in via -M. Looking at the source code it appears that the grammar file that specifies the allowable characters in file names in -M script files is far too restrictive. In my case, I was running in an AFS file system and there was an @ in the path name -- that is not allowd by the grammar. The grammar needs to be fixed to not be so restrictive on what is allowed in file names. Joe Buehler ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
