relocation truncated error

[Sreenadh S]

When we tried to build a c program with math library using unknown-elf-gcc tool chain we got the error:

/lib/libm.a(w_fmod_compat.o): In function `__fmod':
/home/hdg/RISCV_prv_1_10/tools/riscv-tools/riscv-gnu-toolchain/riscv-glibc/math/w_fmod_compat.c:26:(.text+0x0): relocation truncated to fit: R_RISCV_HI20 against `.LC0'

we had given the option -mcmodel=medany, we also tried with latest toolchain

toolchain was build with option rv64imafd (no compressed instructions)

Make file and lds file attached

We use crt.S and syscalls.c from riscv-tests/benchmarks program.

Please give a solution

[Jim Wilson]

On Thu, Aug 23, 2018 at 7:05 AM, Sreenadh S <sreena...@gmail.com> wrote:
>>> /lib/libm.a(w_fmod_compat.o): In function `__fmod':
>>>
>>> /home/hdg/RISCV_prv_1_10/tools/riscv-tools/riscv-gnu-toolchain/riscv-glibc/math/w_fmod_compat.c:26:(.text+0x0):
>>> relocation truncated to fit: R_RISCV_HI20 against `.LC0'
>
> we had given the option -mcmodel=medany, we also tried with latest toolchain

You didn't provide enough info to reproduce the problem. You gave us
a Makefile and a linker script but no source files or object files.

However, it looks like the problem is that you didn't compile the
glibc library with -mcmodel=medany. The R_RISCV_HI20 relocation is
used in medlow code, and the R_RISCV_PCREL_HI20 relocation is used in
medany code. Medlow and medany code can be linked together, but if
you do that, you are subject to the restrictions of medlow, which your
linker script is violating. This is why you get the linker error.

You didn't explain what you are trying to do, but it looks odd. You
are using glibc, which should only work with a linux toolchain. But
you are using medany and an embedded linker script, which aren't
needed for linux code. Unless you are building an linux kernel, but
if you are doing that, then you don't link with glibc. I don't think
that compiling glibc with medany is the correct solution here. I
think you should try to explain what exactly you are trying to do, and
then maybe people can tell you the right way to do that. You probably
either need to use an embedded elf toolchain instead of a linux
toolchain, or else you need to stop trying to link with glibc.

Jim

[Sathya Narayanan N]

Hi Jim,

Thanks for your inputs. I faced similar problem for a different code.

My observations are, it has something to do with the size of library or a big chunk of code.

Looks like if the chunk is not fitting in, the truncation is done by the tools.

I have successfully loaded some codes at 80 million location (including FreeRtos).

At the same time, I have not been to run certain codes.

So is your suggestion is to regenerate the glibc with memory model "-mcmodel=medany" ?

regards,

sathya

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAFyWVabp4U4ufVnVxuZjWETWzWBFJTsZkdY-RBLoLPoMinwKrg%40mail.gmail.com.

--

 regards,
Sathya  

 

[Sreenadh S]

I compiled the toolchain with -mcmodel=medany and now it is working....

Thank you...

[Jim Wilson]

On Thu, Aug 23, 2018 at 8:19 PM, Sathya Narayanan N <sath...@gmail.com> wrote:
> My observations are, it has something to do with the size of library or a
> big chunk of code.
> Looks like if the chunk is not fitting in, the truncation is done by the
> tools.

It isn't the size of the code per se, but rather the addresses
involved. If an address is out-of-range for the instruction in use at
link time you get a relocation truncated message. Palmer has a blog
that talks about this.
https://www.sifive.com/blog/2017/08/21/all-aboard-part-2-relocations/

Jim

[Michael Clark]

> On 24/08/2018, at 4:03 PM, Sreenadh S <sreena...@gmail.com> wrote:
>
> I compiled the toolchain with -mcmodel=medany and now it is working....

-mcmodel=medany seems like a reasonable default for the Linux toolchain? I’d be surprised if the Linux distros would build with absolute addressing in this day and age. What is the reason to default to -mcmodel=medlow? Is it historic? or is it purposeful?

Do we add bytes by not being able to use c.lui? Do linker relaxations for HI20 actually handle compressing LUI to c.lui? i.e. does this make any significant difference to compiled binary sizes?

BTW I notice a lot of Makefiles add -mcmodel=medany but of course this doesn’t change how the toolchain libraries are built as we well know.

Folk are generally moving away from absolute addressing to relative addressing. One of the reasons is security. It’s necessary to have PC-Relative addressing for PIE.

PC-Relative addressing and PIE are however distinct issues due to the necessity for a GOT with PIE, but not necessarily a PLT in the case of static PIE, and also the need for a PT_DYNAMIC program header in addition to the usually PT_LOAD headers, for runtime pointer relocations (pointers to functions, pointers to data). This ELF data also should be considered as part of the size of the binary as they are needed for the executable to be loaded.

AUIPC should still be able to be used to access .data section and if a pointer is not stored at compile time then PIE should still be able to use regular PC-Relative accesses to the .data section. It’s only data containing pointers that need to be relocated in the crt startup code. e.g. some asm gets the difference between a link time address of a label and a PC-Relative reference to the same label to get the load time symbol address, subtracts the linked address to calculate the offset and then loop over the dynamic XLEN size relocs adding the offset.

For those who are not aware, these dynamic relocs are not relocations in the object file relocation sense used by the linker, rather they are DT_RELA entires (much like in a shared object) that only apply to the data section and they can be used in static binaries.

I have written a static-pie crt for musl on xnu/mach-o x86_64. It took a day. The musl code to do the ELF PT_DYNAMIC relocations on riscv64 is 284 bytes. I compiled it with -mcmodel=medlow and -mcmodel=medany and the size is the same.

Debian and Ubuntu now both compile GCC with default-pie on x86_64 which allows ASLR for executables in addition to libraries loaded by ld.so which have been ASLR protected for quite some time (the last decade).

Fedora x86_64 hasn’t enabled default-pie, so programs you compile yourself don’t get the extra security but their RPMs all have -fpie -fstackprotector-strong -Wl, -z,relro,-z,now,-z,noexecstack and are linked with -pie (the relro,now gets the dynamic linker to prebind all symbols at load time, rather than lazily and marks the GOT readonly, as writable GOT is a target for hackers as they can redirect functions using ROP gadgets assuming they can break ASLR with some pointer leaks).

The distributions also will (hopefully) be building with -mcmodel=medany on RISC-V.

Of course interpreting PT_LOAD entries in an ELF ROM payload and zeroing .bss is going to be much simpler. I meant to write that today but got distracted due to some technical debt, asymmetry in some build scripts with respect to riscv32 and riscv64 and some memory map differences between QEMU and hardware. Determined to write a tiny ELF ROM loader and packer. Maybe over the remainder of the weekend...

[Jim Wilson]

On Sat, Aug 25, 2018 at 9:08 AM, Michael Clark <michae...@mac.com> wrote:
> -mcmodel=medany seems like a reasonable default for the Linux toolchain? I’d be surprised if the Linux distros would build with absolute addressing in this day and age. What is the reason to default to -mcmodel=medlow? Is it historic? or is it purposeful?

medlow gives better code. You shouldn't use medany unless you need
it. Linux has an MMU, and hence has no need to use medany or PIC by
default for application code. People who want medany or PIC by
default can of course configure a toolchain that way. We don't force
big code models or PIC code on people who don't want them. This is
how most gcc linux ports work.

The user in this case is apparently building a bootloader or kernel or
embedded app to be run at physical addresses, and hence requires
medany. That is why I asked for more info about what he is doing, as
using glibc with a bootloader/kernel/embedded app doesn't make much
sense.

The rest of this doesn't appear to have any relationship to the
original question, so ignored.

Jim

[Michael Clark]

Well it was more to do with the nature of other targets using PC-Relative addressing vs absolute addressing and the reasons why.

I don’t think it’s a matter of forcing anyone to do anything rather a matter of choosing appropriate defaults.

Curious what is _better code_ with medlow. Linux, which was the toolchain in question, in other typical configurations tend to use PC-Relative addressing. This is good to know because I need to override the default for my local builds to use medany i.e. PC-Relative. I’m willing to bear the cost of not using absolute addressing. We should measure it and do some plots. PC-Relative is the future...

The remainder of the email was regarding security and what some of the Linux distros are doing with PIE and PIC, and yes I understand this definitely entails larger code size due to the GOT (and PLTs if not static), so it’s not appropriate in all environments. Perhaps anything network attached i.e. vulnerable to external hacking attempts that exploit software bugs such as buffer overflows or use-after-free, etc, as a ROP vector. Small U Series devices like routers with Ethernet and web interface e.g. OpenWRT, probably want the compiler security flags enabled which necessitates PIC/PIE. They probably have their own compiler bootstrap so it’s not an issue, just awareness of the benefits of position independent code.

[Michael Clark]

Hi Jim,

Oh right. Now I remember. medany is missing some relaxations? that medlow supports. Otherwise the code should be relatively similar, just AUIPC instead of LUI. Is it elimination of redundant AUIPC that can’t happen with medany in GCC?

Michael

> --
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
> To post to this group, send email to sw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/8710510F-B2E9-4FEE-A32C-4C406F14AD2C%40mac.com.

[Jim Wilson]

On Sat, Aug 25, 2018 at 6:47 PM, Michael Clark <michae...@mac.com> wrote:
> Oh right. Now I remember. medany is missing some relaxations? that medlow supports. Otherwise the code should be relatively similar, just AUIPC instead of LUI. Is it elimination of redundant AUIPC that can’t happen with medany in GCC?

auipc does not directly map to any gcc internal abstraction. When you
use medlow, you get lui/addi emitted and optimized, because this
directly maps to gcc internals (same as mips, sparc, etc). When you
use medany, you get lla and no compile time optimization of the
auipc/addi. If you add -mexplicit-relocs what you get is a mess,
because the gcc implementation is trying to pretend that auipc works
the same as lui except it doesn't. I've found several ways that you
can trigger a linker error, and several ways that you can get silently
wrong output from the linker. And you still don't get proper compile
time optimization of the auipc because trying to shoehorn it into the
same internals used for lui/addi doesn't work. I just started looking
at medany support last week, and I'm still cataloging problems and
still trying to fix out how to fix this. A proper fix may require a
redesign of the gcc internals support for auipc/addi, which could be a
few months work. We may need new and interesting relocs to fix this.
We might need clarifications to the medany code model and existing
relocs. Etc.

And this still doesn't relate to the original message. The original
poster made an obvious mistake, and I pointed it out. We shouldn't be
hiding important discussions in obscure threads.

Jim

[Michael Clark]

My apologies. It seems it is easy to move laterally, from a point to the surrounding issues; given the observation that medlow is absolute addressing and medany is relative addressing, and this leads on to other issues related to relative addressing such as PIC/PIE which depend on it. I’ll consider to start another thread next time...

I had actually written more but omitted it. A related idea was a linker option to preserve all Relocs in the final linked binary as metadata. This may also require new relocs to preserve information when relaxations are performed, however if the resulting LO12 relocs all point back to the AUIPC they share, then the current relocs might be okay. We’ll have to chat some more...

[Wei Song]

In https://www.sifive.com/blog/2017/09/11/all-aboard-part-4-risc-v-code-models/

This selects the medium-low code model, which means program and its statically defined symbols must lie within a single 2 GiB address range and must lie between absolute addresses -2 GiB and +2 GiB.

This selects the medium-any code model, which means the program and its statically defined symbols must lie within any single 2 GiB address range. 

Why there is a constraint of "within a single 2 GiB address space" rather than a 4GiB address space?

-Wei

[Andrew Waterman]

On Fri, Aug 31, 2018 at 7:36 PM Wei Song <wso...@gmail.com> wrote:

In https://www.sifive.com/blog/2017/09/11/all-aboard-part-4-risc-v-code-models/

This selects the medium-low code model, which means program and its statically defined symbols must lie within a single 2 GiB address range and must lie between absolute addresses -2 GiB and +2 GiB.

This selects the medium-any code model, which means the program and its statically defined symbols must lie within any single 2 GiB address range. 

Why there is a constraint of "within a single 2 GiB address space" rather than a 4GiB address space?

auipc can address a range of +/- 2 GiB, so everything addressed with auipc must be within 2 GiB of everything else.

(That’s for RV64. For RV32 systems, this is taken mod 4 GiB, so both code models should be able to address everything.)

-Wei

On Friday, August 24, 2018 at 1:43:16 PM UTC+8, Jim Wilson wrote:

On Thu, Aug 23, 2018 at 8:19 PM, Sathya Narayanan N <sath...@gmail.com> wrote:
> My observations are, it has something to do with the size of library or a
> big chunk of code.
> Looks like if the chunk is not fitting in, the truncation is done by the
> tools.

It isn't the size of the code per se, but rather the addresses
involved.  If an address is out-of-range for the instruction in use at
link time you get a relocation truncated message.  Palmer has a blog
that talks about this.
https://www.sifive.com/blog/2017/08/21/all-aboard-part-2-relocations/

Jim

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/a2bbb4f8-e1c5-47e5-9bdd-407258df52a7%40groups.riscv.org.

[Rahul Bodduna]

I tried to compile the "mt" tests in riscv-tests of the riscv-tools. I find myself again relocation truncated error.

syscalls.o: In function `vprintfmt':

syscalls.c:(.text+0x4): relocation truncated to fit: R_RISCV_HI20 against `.L11'

I compiled the tool chain with -mcmodel=medany flag. I still could not get rid of the error. 

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CA%2B%2B6G0BJEhuA9Um83_KF0bbDBVhknZ0v66YXXOsUBZA87Kh%2BHg%40mail.gmail.com.

--

Regards,

Rahul Bodduna,

MS Scholar,
RISE Lab,
IIT Madras.

[Michael Clark]

On 3/09/2018, at 7:00 AM, Rahul Bodduna <rahul....@gmail.com> wrote:

I tried to compile the "mt" tests in riscv-tests of the riscv-tools. I find myself again relocation truncated error.

syscalls.o: In function `vprintfmt':

syscalls.c:(.text+0x4): relocation truncated to fit: R_RISCV_HI20 against `.L11'

I compiled the tool chain with -mcmodel=medany flag. I still could not get rid of the error. 

If you see an R_RISCV_HI20 relocation, then this most likely means the code was compiled with -mcmodel=medlow. You should probably check the compile flags used in riscv-tests.

What branch and commit of riscv-gnu-toolchain are you using? Are you using the version in riscv-tools? The compiler in riscv-tools should be able to compile riscv-tests.

Note to jimw: riscv-tools is not intended for compiling Linux distros. It’s the toolset that is a submodule of rocket-chip:

https://github.com/freechipsproject/rocket-chip

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAHC6zMtPYVAQdoP3ko6HsBs7Xh-noyxE7vmTC9P67BPc56zN2Q%40mail.gmail.com.

[Rahul Bodduna]

I pulled the latest commit of riscv-tests. I added the -mcmodel=medany flag to gcc options and linker options in the makefile of "mt" tests. I still couldn't figure out what am I missing.

[Michael Clark]

Ideally these repos should all build independently, but the /current/ way is to build using the submodules of a parent repo like riscv-tools, as the various submodule commit ids have presumably been tested together. e.g. the compiler version in riscv-tools is possibly different to that in master of riscv-gnu-toolchain

I just ran configure --host=riscv64-unknown-elf in riscv-tests master using a known good compiler package (2018.1) and it builds just fine.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAHC6zMs9yrk8L8Pt1Biby6%2BKNtfc%2BeVopV4OkB6_v6GrvdKeqA%40mail.gmail.com.

[Tommy Murphy]

Are you sure that your standard libraries (e.g. glibc or newlib) are also compiled with -mcmodel=medany?

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAHC6zMs9yrk8L8Pt1Biby6%2BKNtfc%2BeVopV4OkB6_v6GrvdKeqA%40mail.gmail.com.

[Michael Clark]

On 3/09/2018, at 9:11 AM, Tommy Murphy <tommy_...@hotmail.com> wrote:

Are you sure that your standard libraries (e.g. glibc or newlib) are also compiled with -mcmodel=medany?

I believe riscv-tools already adds -mcmodel=medany however perhaps there is a configure test that is tripping it up.

We’d need to see the configure commands, the branch names and commits for riscv-toolchain and riscv-tests as well as config.log and the entire build log. This however is more appropriate to log as an issue on the riscv-tests repo on GitHub.

If someone is building their own tools individually then it’s unlikely to be easy to support. If this issue can be reproduced with top-of-tree riscv-tools, then it may be a genuine bug in riscv-tools (which currently builds spike, openocd, the ELF toolchain and riscv-tests).

[Tommy Murphy]

> If this issue can be reproduced with top-of-tree riscv-tools, then it may be a genuine bug in riscv-tools

This is confusing given that it is claimed elsewhere that most of the RISC-V support is upstreamed and most or all of the tools can (and should?) be built from the upstream projects (gcc,  gdb, binutils, newlib, glibc).

[Jim Wilson]

On Sun, Sep 2, 2018 at 1:10 PM, 'Michael Clark' via RISC-V SW Dev
<sw-...@groups.riscv.org> wrote:
> Note to jimw: riscv-tools is not intended for compiling Linux distros. It’s
> the toolset that is a submodule of rocket-chip:

See the riscv-tools README.md file, which clearly talks about building
a linux system, and is hopelessly out of date. This is confusing
anyone that actually bothers to read the docs. There is also the
problem that no one is actively maintaining riscv-tools. The only
bugs that ever get fixed are show stopper bugs. I am well aware of
the fact that rocket-chip include riscv-tools. I've been told that
rocket-chip will be fixed to stop using riscv-tools. riscv-tools is
incidentally using an old obsolete gcc-7.2 which is known to be
broken. Anyone using riscv-tools for a compiler is making a serious
mistake.

See also the software tools link on the riscv.org home page which points at
https://riscv.org/software-tools/
which in turn points at riscv-tools and has instructions written in
Aug 2014 that also talk about building a linux system and that are
even more hopelessly out-of-date than the riscv-tools README.md file.
This is also confusing people that actually read the docs. We need to
rewrite this page and kill riscv-tools to fix this problem.

riscv-tools made sense 4 years ago when a small group was maintaining
everything and nothing was upstream. Nowadays it is a disaster, tools
maintained by different people with different ideas about how to
maintain tools and different levels of interest in maintaining the old
riscv-* repos versus the upstream repos which means there is no longer
any consistency in riscv-tools. There is also no need for it anymore.
rocket-chip should not be hard wired to a single compiler version.
Also, note that riscv-tools used to contain riscv-llvm, but the LLVM
maintainers completely stopped maintaining the riscv-llvm tree, and it
was so badly broken that we had no choice but to remove it. The
riscv-gnu-toolchain tree is still maintained, but for how long is
unknown. At some point, it probably makes more sense to start
supporting stable RISC-V branches in the FSF trees instead of
riscv-gnu-toolchain, like Linaro does. Most people know to look at
the FSF trees to find the GNU toolchain sources. And to look at the
LLVM trees to find the LLVM toolchain sources. Only RISC-V insiders
know about and use our github trees.

Jim

[Jim Wilson]

On Sun, Sep 2, 2018 at 3:33 PM, Tommy Murphy <tommy_...@hotmail.com> wrote:
>> If this issue can be reproduced with top-of-tree riscv-tools, then it may
>> be a genuine bug in riscv-tools
>
> This is confusing given that it is claimed elsewhere that most of the RISC-V
> support is upstreamed and most or all of the tools can (and should?) be
> built from the upstream projects (gcc, gdb, binutils, newlib, glibc).

There is no one size fits all solution that works for everybody. Some
people will want bleeding edge tools and will use the upstream repos
where development takes place. Some people will want stable releases,
and will use release branches in the upstream trees or alternatively,
for some tools, there are release branches with backported patches
that can be found in the riscv-* trees. Some tools have no upstream,
as they are riscv specific, and are maintained in the riscv-* trees.
Some people want a convenient build script, and may benefit from using
something like riscv-gnu-toolchain. And some people want to use the
same tools they've been using for the last year, because the risk of
breaking something by changing versions is higher than the risk of
hitting known bugs in old tools.

But as for riscv-tools, this is just so hopelessly broken that I must
recommend against using it.

Jim

[Jim Wilson]

On Sun, Sep 2, 2018 at 1:10 PM, 'Michael Clark' via RISC-V SW Dev
<sw-...@groups.riscv.org> wrote:

> Note to jimw: riscv-tools is not intended for compiling Linux distros. It’s
> the toolset that is a submodule of rocket-chip:

And another thing, riscv-tools is used by rocket-chip for a specific
and limited purpose. it is probably used to compile some on-chip rom
or something. They don't need a fancy compiler for that, any old
compiler will do (and yes it is old). But the mere fact that we have
a repo called "riscv-tools" confuses people into thinking that this is
correct place to look for riscv software tools, and it isn't. This is
a specific collection of tools that is needed by rocket-chip to
function correctly. But it is not the correct place to look for riscv
tools in general. If you want a compiler, use riscv-gnu-toolchain
instead of riscv-tools, as riscv-gnu-toolchain is far better. if you
want a linux system, use sifive/freedom-u-sdk instead of riscv-tools,
and sifive/freedom-u-sdk is far better. We need to get rid of
riscv-tools as currently its primary effect is to confuse people.

Jim

[Jim Wilson]

On Sun, Sep 2, 2018 at 12:00 PM, Rahul Bodduna <rahul....@gmail.com> wrote:
> I tried to compile the "mt" tests in riscv-tests of the riscv-tools. I find
> myself again relocation truncated error.
>
> syscalls.o: In function `vprintfmt':
> syscalls.c:(.text+0x4): relocation truncated to fit: R_RISCV_HI20 against
> `.L11'
>
> I compiled the tool chain with -mcmodel=medany flag. I still could not get
> rid of the error.

As Michael mentioned, the fact that you have a R_RISCV_HI20 relocation
is a clear sign that your toolchain was not compiled with
-mcmodel=medany. You didn't give us enough info to reproduce what you
did, so I can't say what you might have done wrong.

What I tried was modifying build.sh to say
build_project riscv-gnu-toolchain --prefix=$RISCV --with-cmodel=medany
and then in riscv-tests/mt/Makefile I modified RISCV_GCC_OPTS and
RISCV_LINK_OPTS to include -mcmodel=medany. Everything compiled and
linked. But it failed due to an apparent elf2hex bug. I get
elf2hex 16 32768 vvadd1.riscv > vvadd1.riscv.hex
elf2hex: ../fesvr/htif_hexwriter.cc:17: virtual void
htif_hexwriter_t::read_chunk(addr_t, size_t, void*): Assertion `taddr
< width*depth' failed.
Makefile:109: recipe for target 'vvadd1.riscv.hex' failed

elf2hex comes from riscv-fesvr. If you can reproduce this, you can
try reporting a bug there. Or you can try to fix it yourself and
submit a patch.

Jim

[Jose Martins]

Hi Andrew,

When reading Palmer's blog post I had the same question as Wei. Your answer clarified this for me. But I still don't see why the 2GiB range limitation is still imposed on the medlow model as using lui is not relative and always allows addressing the full -2GiB to 2 GiB range, even in 64 bit systems.

[Andrew Waterman]

On Wed, Dec 19, 2018 at 6:11 AM Jose Martins <josema...@gmail.com> wrote:

Hi Andrew,

When reading Palmer's blog post I had the same question as Wei. Your answer clarified this for me. But I still don't see why the 2GiB range limitation is still imposed on the medlow model as using lui is not relative and always allows addressing the full -2GiB to 2 GiB range, even in 64 bit systems.

All of these calling conventions use auipc for procedure calls, so they all have the range limitation for the text section.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/9cb1fb70-1463-40ad-a363-7d40a057840b%40groups.riscv.org.