From: Josh Stone <jistone@redhat.com>
To: Mark Wielaard <mark@klomp.org>,
Crestez Dan Leonard <cdleonard@gmail.com>
Cc: systemtap@sourceware.org
Subject: Re: [RFC 00/13] MIPS64 support
Date: Thu, 14 Aug 2014 20:58:00 -0000 [thread overview]
Message-ID: <53ED2307.1070502@redhat.com> (raw)
In-Reply-To: <20140801111556.GC28053@toonder.wildebeest.org>
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
>
next prev parent reply other threads:[~2014-08-14 20:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 20:21 Crestez Dan Leonard
2014-07-31 20:21 ` [RFC 02/13] mips: Define TIF_32BIT if missing Crestez Dan Leonard
2014-07-31 20:21 ` [RFC 01/13] mips: Minimal build support Crestez Dan Leonard
2014-07-31 20:21 ` [RFC 03/13] mips: Read _stp_deref and _stp_store_deref support Crestez Dan Leonard
2014-07-31 20:22 ` [RFC 05/13] mips: Special get_cycles for cavium octeon Crestez Dan Leonard
2014-07-31 20:22 ` [RFC 11/13] mips64: Initial unwind support Crestez Dan Leonard
2014-07-31 20:22 ` [RFC 08/13] mips: Fix fetching params of type long on mips kernel Crestez Dan Leonard
2014-07-31 20:22 ` [RFC 10/13] Create debug_frame_hdr in target byte order Crestez Dan Leonard
2014-07-31 20:22 ` [RFC 06/13] Force sign-extend statement addresses on mips64 -msym32 Crestez Dan Leonard
2014-07-31 20:22 ` [RFC 09/13] mips: dwflpp hack for struct fields being DW_OP_constu instead of DW_OP_plus_uconst Crestez Dan Leonard
2014-07-31 20:22 ` [RFC 04/13] mips: runtime and tapset code from cisco Crestez Dan Leonard
2014-07-31 20:22 ` [RFC 07/13] loc2c: Add Dwarf pointer to location_context Crestez Dan Leonard
2014-07-31 20:23 ` [RFC 12/13] translator: Hack to interpret mips64 FDEs as 32bit for unwind Crestez Dan Leonard
2014-07-31 20:23 ` [RFC 13/13] runtime: " Crestez Dan Leonard
2014-08-01 11:16 ` [RFC 00/13] MIPS64 support Mark Wielaard
2014-08-01 12:02 ` Crestez Dan Leonard
2014-08-14 20:58 ` Josh Stone [this message]
2014-08-15 1:27 ` Victor Kamensky
2014-09-01 13:47 ` Crestez Dan Leonard
2014-09-02 18:05 ` Josh Stone
2014-09-02 19:10 ` Crestez Dan Leonard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53ED2307.1070502@redhat.com \
--to=jistone@redhat.com \
--cc=cdleonard@gmail.com \
--cc=mark@klomp.org \
--cc=systemtap@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).