[RFC 00/13] MIPS64 support

[Josh Stone]

FYI for @redhat.com folks, if you got a bounce message from sourceware
today, I believe it's complaining about this message:
https://sourceware.org/ml/systemtap/2014-q3/msg00114.html

Apparently sourceware was happy to accept that .o attachment, but
redhat.com rejects it as "virus Heuristics.Broken.Executable".

On 08/01/2014 04:15 AM, Mark Wielaard wrote:
> Hi,
> 
> I didn't review any of the patches yet, but noticed this:
> 
> On Thu, Jul 31, 2014 at 11:21:05PM +0300, Crestez Dan Leonard wrote:
>> Inside loc2c the CU address_size is used to determine the max_fetch_size,
>> this becomes incorrect with -msym32. Handling this (patch 8) requires
>> access to the elf header which requires a lot of code churn (patch 7).
>> This could be avoided if elfutils exported a dwarf_die_getdwarf but this
>> would be a new elfutils API.
> 
> I believe Josh Stone also wanted a function like that (although I don't
> remember for what, so maybe I am wrong). I think it would be reasonable
> to have such a new function to get at the Dwarf from either a Dwarf_Die
> or Dwarf_CU (which might be helpful if all you have is an Dwarf_Attribute).
> 
>> Apparently -msym32 also affects the FDE data for unwind support. It's not
>> clear how to detect it cleanly in there. Apparently an "address_size" field
>> can be included in the CIE, but I don't have it. Both eu-readelf and
>> binutils readelf show corrupt FDEs. Patches 12 and 13 are evil hacks.
>> Presumably I could try to interpret initial_address both ways and attempt
>> to lookup the CU?
> 
> Do you have an example ELF/DWARF file that shows this issue?
> 
> Thanks,
> 
> Mark
>