Re: [discuss] Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

On Mon, Jun 8, 2009 at 6:30 AM, Paul Brook<paul <at> codesourcery.com> wrote:
>> The only other alternative to #1 that I see is some scheme whereby "&func"
>> will in all cases resolve to a PLT entry rather than the actual
>> STT_GNU_IFUNC symbol's st_value.  i.e., the ifunc resolver is only called
>> for PLT resolution (and you can do all those last for BIND_NOW).
>
> This will break pointer comparisons across modules.
>

Please try the current binutils in CVS. I think I have fixed all
problems. If not,
please open a bug report with a testcase.

Thanks.

--

-- 
H.J.

Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

Hi,

Here is a proposal for STT_GNU_IFUNC and R_*_IRELATIVE. It
has been implemented in the Linux binutils 2.19.51.0.5.

H.J.
----
STT_GNU_IFUNC

      This symbol type is the same as STT_FUNC except that it always
      points to a function or piece of executable code which takes no
      arguments and returns a function pointer.  If an STT_GNU_IFUNC
      symbol is referred to by a relocation, then evaluation of that
      relocation is delayed until load-time.  The value used in the
      relocation is the function pointer returned by an invocation
      of the STT_GNU_IFUNC symbol.

      The purpose of this symbol type is to allow the run-time to
      select between multiple versions of the implementation of a
      specific function.  The selection made in general will take the
      currently available hardware into account and select the most
      appropriate version.

STT_GNU_IFUNC is defined in OS-specific range:

#define STT_LOOS	10	/* OS-specific semantics */
#define STT_GNU_IFUNC	10	/* Symbol is an indirect code object */
#define STT_HIOS	12	/* OS-specific semantics */

R_*_IRELATIVE

[x86-64 psABI]: PATCH: Clarify aggregate with X87UP

Hi,

x86-64 psABI isn't very clear how X87UP should be handled
in post merger cleanup. This patch clarifies post merger cleanup for
aggregate with X87UP is not preceded by X87.

-- 
H.J.
----
2009-02-03  H.J. Lu  <hongjiu.lu <at> intel.com>

	* low-level-sys-info.tex: Clarify post merger cleanup for
	aggregate with X87UP is not preceded by X87.

2009-02-03  H.J. Lu  <hongjiu.lu <at> intel.com>

	* low-level-sys-info.tex: Clarify post merger cleanup for
	aggregate with X87UP is not preceded by X87.

Index: low-level-sys-info.tex
===================================================================
--- low-level-sys-info.tex	(revision 5122)
+++ low-level-sys-info.tex	(revision 5135)
@@ -452,7 +452,9 @@ types works as follows:
 \item Then a post merger cleanup is done:
   \begin{enumerate}
   \item If one of the classes is MEMORY, the whole argument is passed in memory.
-  \item If SSEUP is not preceeded by SSE, it is converted to SSE.
+  \item If X87UP is not preceded by X87, the whole argument is passed in

RFA: union with long double doesn't follow x86-64 psABI

Hi,

Gcc doesn't follow x86-64 psABI when passing and returing
union with long double:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082

Gcc converts X87UP to SSE if X87UP is not preceded by X87.
I don't believe x86-64 psABI calls for it. I think psABI should
be updated with:

Index: low-level-sys-info.tex
===================================================================
--- low-level-sys-info.tex	(revision 5122)
+++ low-level-sys-info.tex	(working copy)
@@ -452,7 +452,9 @@ types works as follows:
 \item Then a post merger cleanup is done:
   \begin{enumerate}
   \item If one of the classes is MEMORY, the whole argument is passed
in memory.
-  \item If SSEUP is not preceeded by SSE, it is converted to SSE.
+  \item If X87UP is not preceded by X87, the whole argument is passed in
+    memory.
+  \item If SSEUP is not preceded by SSE, it is converted to SSE.
   \end{enumerate}
 \end{enumerate}

The gcc patch is:

--- ./i386.c.x87	2009-02-02 15:36:01.000000000 -0800

[AVX]: Update x86-64 psABI for aggregates with __m256

Hi,

We like to update x86-64 psABI to pass aggregates of 32 bytes with
single __m256 field
in AVX registers, instead of memory. However, finding the proper
wording seems tricky.
Here is what I got.  Any comments?

Thanks.

-- 
H.J.

Index: low-level-sys-info.tex
===================================================================
--- low-level-sys-info.tex	(revision 5099)
+++ low-level-sys-info.tex	(working copy)
@@ -343,10 +343,12 @@ classes are corresponding to \xARCH regi
 \begin{description}
 \item[INTEGER] This class consists of integral types that fit into one of
   the general purpose registers.
-\item[SSE] The class consists of types that fit into a SSE register.
-\item[SSEUP] The class consists of types that fit into a SSE register
+\item[SSE] The class consists of types that fit into an SSE register.
+\item[SSEUP] The class consists of types that fit into an SSE register
+  and can be passed and returned in the most significant half of it.
+\item[AVX] The class consists of types that fit into an AVX register.
+\item[AVXUP] The class consists of types that fit into an AVX register
   and can be passed and returned in the most significant half of it.

[PATCH 2/5] arch/x86/kernel/pci-calgary_64.c: change simple_strtol to simple_strtoul

From: Julia Lawall <julia <at> diku.dk>

Since bridge is unsigned, it would seem better to use simple_strtoul that
simple_strtol.

A simplified version of the semantic patch that makes this change is as
follows: (http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@r2@
long e;
position p;
@@

e = simple_strtol <at> p(...)

@@
position p != r2.p;
type T;
T e;
@@

e = 
- simple_strtol <at> p
+ simple_strtoul
  (...)
// </smpl>

Signed-off-by: Julia Lawall <julia <at> diku.dk>

RFC: Extend x86-64 psABI for 256bit AVX register

Hi,

x86-64 psABI defines

typedef struct
{
  unsigned int gp_offset;
  unsigned int fp_offset;
  void *overflow_arg_area;
  void *reg_save_area;
} va_list[1];

for variable argument list. "va_list" is used to access variable argument
list:

void
bar (const char *format, va_list ap)
{
  if (va_arg (ap, int) != 0)
    abort ();
}

void
foo(char *fmt, ...)
{
  va_list ap;
  va_start (fmt, ap);
  bar (fmt, ap);
  va_end (ap);
}

Does Linux have plan to support memory hole remapping?

Hi experts,

I ask this because I run kernel 2.6.25-rc8 on a x64 system with 32GB
physical memory, and kernel only use (32GB-512MB) physical memory. See
below related information:
E820 table:
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 0000000000098c00 (usable)
 BIOS-e820: 0000000000098c00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000dffa0000 (usable)
 BIOS-e820: 00000000dffae000 - 00000000dffb0000 type 9
 BIOS-e820: 00000000dffb0000 - 00000000dffbe000 (ACPI data)
 BIOS-e820: 00000000dffbe000 - 00000000dfff0000 (ACPI NVS)
 BIOS-e820: 00000000dfff0000 - 00000000dfffe000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 0000000820000000 (usable)

/proc/mtrr:
reg00: base=0x00000000 (   0MB), size=32768MB: write-back, count=1
reg01: base=0x800000000 (32768MB), size= 512MB: write-back, count=1
reg02: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1

/proc/meminfo:
MemTotal:     33010240 kB
MemFree:      32715924 kB
Buffers:          1624 kB

Re: [discuss] Weird cpu mapping on 8-way dual-core machine

On Tue, Feb 26, 2008 at 9:48 PM, Yinghai Lu <yhlu.kernel <at> gmail.com> wrote:
> On Tue, Feb 26, 2008 at 9:58 AM, Francisco Jesús Martínez Serrano
>  <franjesus <at> gmail.com> wrote:
>  > 2008/2/26, Andre Przywara:
>  >
>  > >  So your BIOS option disables the shifting workaround and everything
>  >  >  works as intended by the specification, although I am not sure whether
>  >  >  you have any side effects (see above).
>  >
>  >  Maybe I'm getting some side effects, but I'm not sure, when running an
>  >  OpenMP code, I get a lot of numa_misses, at node1 and the same number
>  >  of numa_foreign at node0.
>  >
>  >  Out of pure ignorance, I was wondering if it could be related to the
>  >  node0 getting 505896 pages  (I believe that's 1976.2 MB) of
>  >  ZONE_DMA32. I've seen options to disable DMA and DMA32. Is it safe?
>  >
>  can you try x86.git#testing ?
>
>  http://people.redhat.com/mingo/x86.git/README
>
>  and connect with serial console.
>
>  command line:
>  apic=debug acpi.debug_level=0x0000000F debug console=uart8250,io,0x3f8,115200n8
>
core fix is in x86.git#testing
http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ae2627a87c6f186ced0539d8e6f7a2c78dabc4c5

it will make sure that apicid to node mapping is right.

When is RBX used for base pointer?

Hi,

We need a callee-saved register for stack alignment. In 64bit, our
choices are rbx, and
r12-r15. r12-r15 need the REX byte and r12 also needs the SIB byte. So
I'd like to use rbx.
x86-64 psABI says rbx is callee-saved and optionally used as base
pointer. However,
I couldn't find an example where rbx is used as base pointer. Is this
a carryover from
i386 psABI where ebx is used to hold GOT?

Thanks.

H.J.

"ide=reverse" do we still need this?

Hi,

I'm reworking the pci device list logic (we currently keep all PCI
devices in 2 lists, which isn't the nicest, we should be able to get
away with only 1 list.)

The only bother I've found so far is the pci_get_device_reverse()
function, it's used in 2 places, IDE and the calgary driver.

I'm curious if we really still support the ide=reverse option?  It's a
config option that I don't think the distros still enable (SuSE does
not).  Is this still needed these days?

In digging, we changed this option in 2.2.x from being called
"pci=reverse" and no one else seems to miss it.

Any thoughts?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html