pending/1083: dwarf2 expression code needs a better way to get at the compilation unit address size

[Daniel Jacobowitz <drow at mvista dot com>]

>Number:         1083
>Category:       pending
>Synopsis:       dwarf2 expression code needs a better way to get at the compilation unit address size
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   unknown
>Arrival-Date:   Fri Feb 21 14:58:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 From Jim:
 
 > Also, shouldn't we be using the address size from the compilation unit
 > header, instead of TARGET_ADDR_BIT?  (I have this strong impression
 > we've discussed this before, but I've not been able to find it in the
 > ML archives to see what we decided.)  On a 16-bit machine in 32-bit
 > ELF, it's not clear to me what the compilation unit header's address
 > size will be: if the architecture has separate code and data address
 > spaces, and we treat them as 64k subranges of a unified 32-bit address
 > space for linking, as is often done, it seems to me the compilation
 > unit header's address size could be 32 bits, since that's what you
 > need to store a symbol's value.
 >
 > Since there's no easy way at the moment to get that compilation unit
 > header address size (it's thrown away after we're done reading Dwarf 2
 > info, and the baton needs to be small), this could be a PR.
 
 
 
 We can look at this if it comes up that a target needs this, IMVHO.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: