Modify

Opened 5 years ago

Closed 5 years ago

#12318 closed defect (wontfix)

Problem with TLS support when using MIPS16 AES

Reported by: Tóth F. János <janos666@…> Owned by: florian
Priority: low Milestone: Chaos Calmer 15.05
Component: toolchain Version: Trunk
Keywords: GCC, MIPS, TLS Cc:

Description

I hoped updating the compiler will fix this problem because the change log
of GCC 4.7.1-final said: "GCC now supports thread-local storage (TLS) for MIPS16".
But may be there is something else in the background because I am still getting this error message during compilation of eglibc if I use the -mips16 CFLAG, even though I set CONFIG_TLS_SUPPORT=y. So, may be the CONFIG_TLS_SUPPORT parameter or this dependency checking is broken...?

running configure fragment for ports/sysdeps/mips
checking for MIPS TLS support... no
configure: error: the assembler must support TLS
make[3]: * /home/janos666/openwrt/trunk/build_dir/toolchain-mips_gcc-4.7-linaro_eglibc-2.16/eglibc-2.16-r19922-headers/.configured Error 1

Attachments (0)

Change History (8)

comment:1 Changed 5 years ago by florian

  • Owner changed from developers to florian
  • Status changed from new to assigned

We have no plans supporting mips16, so you are really on your own here, report these issues upstream so we can know what we might be configuring wrong maybe?

comment:2 Changed 5 years ago by florian

Can you now try with the latest toolchain updates and see if that works better?

comment:3 Changed 5 years ago by Jay Carlson <nop@…>

For uclibc and most of base, you can mostly get by with "recompile anything that errors out in -mips16 in -mno-mips16" but I think you really need a gcc wrapper with a blacklist to deal with link-time problems.

In the longer term, it would be nice to be able to have an external file declaring which functions are mips16/no-mips16, since it seems like a maintenance disaster to stick attributes all over world for the sake of one port.

FWIW, mips16 was a lot more attractive before cramfs and gcc 4; there's still a difference between a compressed no-mips16 and a compressed mips16 executable but it's a lot smaller than you might expect. Maybe I should put up a wiki page.

comment:4 Changed 5 years ago by florian

Considering the number of number of possible issues with intermixing mips32 with mips16 code or just having mips16 code, I am not sure this is worth the effort, especially considering that the devices out there supporting mips16 are usually not limited in terms of flash.

comment:5 Changed 5 years ago by anonymous

Grepping through the chaos of the RTL8196 SDK, it looks like Realtek is shipping mips16 binaries against a gcc-3.6-era toolchain. There's even an option to compile the kernel and/or drivers as mips16, which scares the crap out of me.

The ancient broadcom 43xx chips don't speak mips16e but do have mips16 But there's not a huge flash size win given lzma-everywhere. RAM and icache pressure are the best reasons to look at this.

comment:6 Changed 5 years ago by nop@…

In any case, you can't stop me from having a try at this, it's been bugging me for like a decade. :-)

comment:7 Changed 5 years ago by Jay Carlson <nop@…>

OK, one last comment here, so I can close out some browser tabs: you can see in-kernel mips16 framework as part of http://wive-ng.git.sourceforge.net/git/gitweb.cgi?p=wive-ng/wive-ng;a=commitdiff_plain;h=f70052ba21382a2cc939601423419bee9d4558f9

It includes a mips16_lib.h which provides re-#defines for some functions; mips16_lib.c appears to be 32-bit-mode shims like void __cli__(void) { __cli(); }. I think the big motivation for using mips16 is fitting critical drivers inside the ~8k internal RAM. They've got a bunch of linker sections defined to arrange things there. I wonder if any openwrt devices have the mips spram; with a 16-bit path to memory it'd be a huge deal for cache refill for example...oh well, another day.

comment:8 Changed 5 years ago by florian

  • Resolution set to wontfix
  • Status changed from assigned to closed

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.