This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [MIPS] fix CRT_CALL_STATIC_FUNCTION macro
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Petar Jovanovic <petar dot jovanovic at rt-rk dot com>
- Cc: 'Matthew Fortune' <Matthew dot Fortune at imgtec dot com>, gcc-patches at gcc dot gnu dot org, 'Petar Jovanovic' <Petar dot Jovanovic at imgtec dot com>
- Date: Fri, 6 Feb 2015 10:33:18 +0000 (GMT)
- Subject: RE: [MIPS] fix CRT_CALL_STATIC_FUNCTION macro
- Authentication-results: sourceware.org; auth=none
- References: <001501d035e2$72edea20$58c9be60$ at rt-rk dot com> <6D39441BF12EF246A7ABCE6654B0235320FAF4B7 at LEMAIL01 dot le dot imgtec dot org> <alpine dot LFD dot 2 dot 11 dot 1501260301170 dot 28301 at eddie dot linux-mips dot org> <003d01d04177$982bdef0$c8839cd0$ at rt-rk dot com>
On Thu, 5 Feb 2015, Petar Jovanovic wrote:
> > > This is a follow-up to a change [1] in glibc. It fixes the issue [2]
> > > when jal can not reach a target in different region.
> > Is it not a problem that can be solved with rearranging the order of
> sections in output?
>
> Is not this more clean solution to it? Otherwise we need to make sure that
> __do_global_ctors_aux and call to it from _init () are in the same region.
I think you're right, JAL is not a PC-relative jump, so whether the
target is in range or not will depend solely on the load address of the
executable rather than the distance between a jump and its target.
I also think it's best to include such observations right away along a
patch submission so that reviewers do not have to wonder if the problem
has been well understood and alternatives considered in cases like here
where you clearly cause performance loss and code size growth.
I have no further comments on your change; while I cannot approve it v2
looks reasonable to me. Thanks for your submission.
Maciej