From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Luis Machado <lgustavo@codesourcery.com>
Cc: Pedro Alves <palves@redhat.com>, Tom Tromey <tromey@redhat.com>,
Stan Shebs <stanshebs@earthlink.net>,
GDB Patches <gdb-patches@sourceware.org>,
Ulrich Weigand <uweigand@de.ibm.com>
Subject: Re: [PATCH, testsuite] Don't run SREC, IHEX and TEKHEX tests for MIPS N64.
Date: Wed, 03 Jul 2013 20:35:00 -0000 [thread overview]
Message-ID: <alpine.DEB.1.10.1307032122270.20590@tp.orcam.me.uk> (raw)
In-Reply-To: <51D47A05.9020404@codesourcery.com>
On Wed, 3 Jul 2013, Luis Machado wrote:
> > if [istarget "alpha*-*-*"] then {
> > # SREC etc cannot handle 64-bit addresses. Force the test
> > # program into the low 31 bits of the address space.
> > lappend options "additional_flags=-Wl,-taso"
> > }
> >
> > (For MIPS N64, if you wanted, I guess you could do similarly
> > to Alpha, and rebuild with:
> >
> > lappend options "ldflags=-Wl,-Tdata=0x600000"
> >
> > to force use of low addresses.)
[...]
>
> As for MIPS, attempting to force the use of low addresses, just like alpha,
> seems to do more than what the tools expect at the moment, and i get a SIGSEGV
> in the dynamic loader.
Hmm, while (unlike Alpha's -taso option) there is no way to force an
entire n64 MIPS process into the 31-bit address space, the dynamic
executable itself should work just fine mapped low. However the default
linker script relies on the start address of the text (0x120000000, unless
overridden) rather than data segment to get things right and moving the
linker's output address pointer backwards in the middle of the binary
being linker may yield strange results. Can you try (or have you tried)
-Ttext=... instead?
Maciej
next prev parent reply other threads:[~2013-07-03 20:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-01 16:24 Luis Machado
2013-07-02 14:37 ` Yao Qi
2013-07-02 14:45 ` Luis Machado
2013-07-03 0:03 ` Yao Qi
2013-07-02 16:47 ` Tom Tromey
2013-07-02 16:51 ` Luis Machado
2013-07-02 17:19 ` Stan Shebs
2013-07-02 18:10 ` Tom Tromey
2013-07-02 18:50 ` Luis Machado
2013-07-02 20:55 ` Tom Tromey
2013-07-03 15:05 ` Pedro Alves
2013-07-03 19:23 ` Luis Machado
2013-07-03 19:26 ` Pedro Alves
2013-07-03 20:19 ` Luis Machado
2013-07-04 8:11 ` Pedro Alves
2013-07-06 2:41 ` Luis Machado
2013-07-03 20:35 ` Maciej W. Rozycki [this message]
2013-07-03 20:54 ` Luis Machado
2013-07-03 21:08 ` Maciej W. Rozycki
2013-07-04 11:48 ` Luis Machado
2013-07-04 12:13 ` Maciej W. Rozycki
2013-07-04 12:21 ` Luis Machado
2013-07-04 13:22 ` Ulrich Weigand
2013-07-04 13:24 ` Luis Machado
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=alpine.DEB.1.10.1307032122270.20590@tp.orcam.me.uk \
--to=macro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=lgustavo@codesourcery.com \
--cc=palves@redhat.com \
--cc=stanshebs@earthlink.net \
--cc=tromey@redhat.com \
--cc=uweigand@de.ibm.com \
/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