[Bug translator/11074] loc2c/vta: synthetic address range warning/error during -p4 for dwarf const_value

[Bug translator/11074] loc2c/vta: synthetic address range warning/error during -p4 for dwarf const_value

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11074

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #6 from Frank Ch. Eigler <fche at redhat dot com> ---
no recent sightings

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/11074] loc2c/vta: synthetic address range warning/error during -p4 for dwarf const_value

[roland at gnu dot org]

------- Additional Comments From roland at gnu dot org  2009-12-09 22:53 -------
The sign issue for non-address (i.e. really integer) constants is really a
separate question worthy of its own PR.  I have at least three ideas about that
one, but it's not this one.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11074

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/11074] loc2c/vta: synthetic address range warning/error during -p4 for dwarf const_value

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-12-09 21:48 -------
(In reply to comment #3)
> OTOH, we still need to emit sufficient casting goo to make real constants
> pass into intptr_t's without complaint.

Yes, I don't have a real testcase for it yet though. Using data4 for real values
seems uncommon. The dwarf spec even warns about it:

  If one of the DW_FORM_data<n> forms is used to represent a signed or unsigned
integer, it can be hard for a consumer to discover the context necessary to
determine which interpretation is intended. Producers are therefore strongly
encouraged to use DW_FORM_sdata or DW_FORM_udata for signed and unsigned
integers respectively, rather than DW_FORM_data<n>.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11074

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/11074] loc2c/vta: synthetic address range warning/error during -p4 for dwarf const_value

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-12-09 21:09 -------
(In reply to comment #2)
> Which at least explains why we are outputting a constant value instead of a
> (relocatable) address in this case.

OTOH, we still need to emit sufficient casting goo to make real constants
pass into intptr_t's without complaint.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11074

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/11074] loc2c/vta: synthetic address range warning/error during -p4 for dwarf const_value

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-12-09 21:02 -------
See also https://bugzilla.redhat.com/show_bug.cgi?id=546017
Summary: DW_AT_const_value not using DW_FORM_addr for address constant
Component: gcc

Which at least explains why we are outputting a constant value instead of a
(relocatable) address in this case.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11074

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/11074] loc2c/vta: synthetic address range warning/error during -p4 for dwarf const_value

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-12-09 18:51 -------
It appears as though the const_value encoded in dwarf is a pointer to global
data in the kernel, and thus subject to relocation even though vmlinux is
ET_EXEC.

(gdb) p/x 3231800064
$1 = 0xc0a15b00

% nm -S vmlinux | sort| grep c0a1
...
c0a13a34 00000004 D x86_cpu_to_apicid_early_ptr
c0a13a38 00000004 D x86_bios_cpu_apicid_early_ptr
c0a13a40 00002d80 D contig_page_data
c0a167c0 00000498 d pci_serial_quirks
c0a16c58 00000014 d pcmcia_bus_interface
c0a16c6c 0000000c d cpufreq_cpu_notifier
...

So it's as if we must infer a need for _stp_relocate for
such values for the kernel, but probably only if the 
dwarf type is that of a pointer.  Ugh.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11074

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/11074] loc2c/vta: synthetic address range warning/error during -p4 for dwarf const_value

[mjw at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjw at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11074

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/11074] loc2c/vta: synthetic address range warning/error during -p4 for dwarf const_value

[fche at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|loc2c/vta: synthetic address|loc2c/vta: synthetic address
                   |range warning/error during -|range warning/error during -
                   |p4                          |p4 for dwarf const_value


http://sourceware.org/bugzilla/show_bug.cgi?id=11074

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.