> It seemed clearer to just set the offset back to 0, which is what it is
> at the start of the function.
Yes. In detail, both .cfi_def_cfa_offset and .cfi_adjust_cfa_offset
are interpreteted by the assembler into DW_CFA_def_cfa_offset byte
codes, so you should get the same .eh_frame contents if using Naveen's
suggestion. It boils down to style really, and the most common style
is to use ".cfi_def_cfa_offset 0" here.
--
Alan Modra
Australia Development Lab, IBM
e codes
in .eh_frame.
> Alan proposed a larger patch that changed to a single stack frame, but it
> needs changes to
> take into account the red zone.
Yes, now that you mention it, I see the obvious error in the patch I
wrote. I did say it was untested!
--
Alan Modra
Australia Development Lab, IBM
On Wed, Mar 10, 2021 at 01:44:57PM +0100, Christophe Leroy wrote:
>
>
> Le 10/03/2021 à 13:25, Alan Modra a écrit :
> > On Wed, Mar 10, 2021 at 08:33:37PM +1100, Alexey Kardashevskiy wrote:
> > > One more question - the older version had a construct "DEFINED (.TOC.)
hen was it added? I have
> the same check in SLOF, for example, do I still need it?
.TOC. symbol support was first added 2012-11-06, so you need
binutils-2.24 or later to use .TOC. as a symbol.
--
Alan Modra
Australia Development Lab, IBM
?
No. "objdump -r prom_init.o | grep GOT" will tell you whether
prom_init.o *may* cause ld to generate .got entries. (Linker
optimisations or --gc-sections might remove the need for those .got
entries.)
> objdump: section '.got' mentioned in a -j option, but not found in any inpu
del=medium if you appropriately decorate variable declarations
with non-default visibility.
Signed-off-by: Alan Modra
diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
index 1d83966f5ef6..e45907fe468f 100644
--- a/arch/powerpc/boot/crt0.S
+++ b/arch/powerpc/boot/crt0.S
@@ -28,7 +28,7 @@ p
__prom_init_toc_start = .;
- arch/powerpc/kernel/prom_init.o*(.toc .got)
+ arch/powerpc/kernel/prom_init.o*(.toc)
__prom_init_toc_end = .;
#endif
- *(.got)
*(.toc)
}
+ __toc_ptr = DEFINED (.TOC.) ? .TOC. : ADDR (.got) + 0x8000;
#endif
/* The initial task and kernel stack */
--
Alan Modra
Australia Development Lab, IBM
gt; > >
> > > The help text for this config options says that e200 is used in 55xx,
> > > and there *is* an -me5500 GAS flag (which probably does this same
> > > thing, too). But is any of this tested, or useful, or wanted?
> > >
> > > Maybe Chris
the comment and uncomment the code.
Note that the advance_loc there bitrotted ever since the nop was added
before the trampoline, so you'd need to change that to an advance_loc
that moves from .Lsigrt_start to immediately after the addi, ie. 0x42.
--
Alan Modra
Australia Development Lab, IBM
ire the .weak directive to be after the
> > symbol
> > -* is defined. See https://bugs.llvm.org/show_bug.cgi?id=38921 */
> > .weak _zimage_start
> > _zimage_start:
>
> Your explanation makes sense to me. I've added Alan to cc for his review.
>
> Reviewed-by: Joel Stanley
>
> Thanks for the patch.
>
> Cheers,
>
> Joel
>
> > .globl _zimage_start_lib
> > --
> > 2.25.1.696.g5e7596f4ac-goog
--
Alan Modra
Australia Development Lab, IBM
; The content seems to be some default value, this file doesn't even
> exist on my system:
> 2f 75 73 72 2f 6c 69 62 2f 6c 64 2e 73 6f 2e 31
> |/usr/lib/ld.so.1|
>
> So the section serves no useful purpose and consumes a small amount of
> space.
>
>
SET) { *(.gnu.hash) }
> .interp : AT(ADDR(.interp) - LOAD_OFFSET) { *(.interp) }
> .rela.dyn : AT(ADDR(.rela.dyn) - LOAD_OFFSET)
> {
> --
> 2.21.1
--
Alan Modra
Australia Development Lab, IBM
0x0
>
>
> So can't we just discard .gnu.hash? And in fact do we need .hash either?
>
> Actually arm64 discards the latter, and parisc discards both.
>
> Would still be good to hear from Alan or someone else who knows anything
> about toolchain stuff, ie. not me :)
.gnu.hash, like .hash, is used by glibc ld.so for dynamic symbol
lookup. I imagine you don't need either section in a kernel, so
discarding both sounds reasonable. Likely you could discard .interp
and .dynstr too, and .dynsym when !CONFIG_PPC32.
--
Alan Modra
Australia Development Lab, IBM
On Thu, Nov 15, 2018 at 11:47:52PM +1100, Michael Ellerman wrote:
> Alan Modra writes:
>
> > On Wed, Nov 14, 2018 at 01:32:18PM +1030, Joel Stanley wrote:
> >> I wasn't sure where this should go or if the ordering matters.
> >
> > The usual answer is:
1]
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=2d7ad24e8726ba4c45c9e67be08223a146a837ce
> Signed-off-by: Joel Stanley
Reviewed-by: Alan Modra
Looks fine to me.
> ---
> I wasn't sure where this should go or if the ordering matters.
The usual answe
other reports of breakage, so is
> this somehow specific to something Go is doing? Or did we just get lucky
> up until now? Or is no one actually testing on Power? ;)
Mapping PIEs above 4G should be fine. It works for gcc C and C++
after all. The problem is that ppc64le Go is generating code n
s
lr in r0, and reflects that fact with ".cfi_register lr,r0". A later
use of r0 means the CFI at that point isn't correct, as r0 no longer
contains the return address. Fix that too.
Signed-off-by: Alan Modra
Tested-by: Reza Arbab
diff --git a/arch/powerpc/kernel/vdso32/data
contains the return address.
__get_datapage also has a CFI error. That function temporarily saves
lr in r0, and reflects that fact with ".cfi_register lr,r0". A later
use of r0 means the CFI at that point isn't correct, as r0 no longer
contains the return address. Fix that too.
Si
%r0,%r6,2 /* v2 or later? */
> + cmpwi 0,%r6,2 /* v2 or later? */
> blt 1f
> li %r4,28
> STWX_BE %r17,%r3,%r4/* Store my cpu as __be32 at byte 28 */
With this one, it would probably be better to omit the zero (BF
field).
--
Alan Modra
Australia Development Lab, IBM
s:
So this change added space for another header, it seems. I suspect
that was accidental, particularly since there was no mention of
get_program_header_size in the ChangeLog entry.
--
Alan Modra
Australia Development Lab, IBM
files that don't. Here, "old" means mid 2004 or
earlier.
As you can imagine, I'm not hugely concerned about the ld bug..
Since every binutils back to at least 2.17 has the bug, what changed
in the kernel to expose it? Are you building without -mcall-aixdesc?
--
Alan Modra
Australia Development Lab, IBM
008 _start
.text 0x000c0x0 fixup2.o
.text.xyz 0x000c0x4 fixup2.o
[snip]
--
Alan Modra
Australia Development Lab, IBM
On Sun, Aug 07, 2016 at 10:26:19PM +0200, Arnd Bergmann wrote:
> On Sunday, August 7, 2016 7:27:39 PM CEST Alan Modra wrote:
> >
> > If it can, then Nicholas' patch should be:
> >
> > *(.text.hot .text.hot.*) *(.text.unlikely .text.unlikely.*) *(.text
&g
;t put .text.fixup too far away then you may as well just use
*(.text .text.*)
--
Alan Modra
Australia Development Lab, IBM
On Sun, Aug 07, 2016 at 11:49:46AM +1000, Stephen Rothwell wrote:
> Hi Sam,
>
> On Sat, 6 Aug 2016 22:10:45 +0200 Sam Ravnborg wrote:
> >
> > Did you by any chance evalue the use of INPUT in linker files.
> > Stephen back then (again based on proposal from Al
> Is this comment about pre-ELF binaries? If yes, would it possible to
> change the default for ELF binaries?
>
> Thanks,
> Florian
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
he ELFv2 global entry point
code. If you trash r11 here you're killing the static chain pointer,
used by C nested functions or other languages that use a static chain,
eg. Pascal. r11 has *not* been saved for ELFv2.
r12 might be a better choice for a temp reg.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
turn (struct thread_info *)(sp & ~(THREAD_SIZE-1));
> }
With both versions, the original rtl for current_thread_info consists
of two instructions, copy r1 to a pseudo reg, then the "and". With
the above version, fwprop1 manages to combine this to a single "and"
insn. When
s you might guess, gcc
treats the vector of expressions inside the square brackets of the
parallel as happening "in parallel". Meaning that as far as gcc is
concerned the toc restore part (third element) happens at the same
time as the call (first element). So if gcc replaces (reg:
g,(expr)@h;
> .else
> oris reg,reg,(expr)@high;
> .endif
>
> Thanks,
> Guenter
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
d
R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit
signed range. ie. @h and @ha assume you're building a 32-bit value.
This is needed to report out-of-range -mcmodel=medium toc pointer
offsets in @toc@h and @toc@ha expressions, and for consistency I did
the same for
00043.html
git show 3b8b57a9495016b2b02fbc2612dd1607d4b6f9ba
The part that actually fixes this problem is "Leave insn field zero...".
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
cial symbol giving the toc
base, so no, it shouldn't have a CRC.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
> @@ -85,8 +85,8 @@ typedef struct {
>
> #define SA_RESTORER0x0400U
>
> -#define MINSIGSTKSZ2048
> -#define SIGSTKSZ 8192
> +#define MINSIGSTKSZ 4096
> +#define SIGSTKSZ 16384
>
> Thanks
> Haren
--
Alan Modra
Australia Development Lab, I
= (*((uint16_t *) location) & ~0x)
> + | (value & 0x);
and again.
> + break;
> +
> default:
> printk("%s: Unknown ADD relocation: %lu
On Wed, Mar 26, 2014 at 08:34:49PM +1030, Alan Modra wrote:
> On Tue, Mar 25, 2014 at 10:44:21PM +1100, Anton Blanchard wrote:
> > Fix STK_PARAM and use it instead of hardcoding ABIv1 offsets.
>
> > _GLOBAL(memcpy)
> > BEGIN_FTR_SECTION
> > - std r3,48
ld 0,16(1)
mtlr 0
blr
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tue, Mar 25, 2014 at 10:44:16PM +1100, Anton Blanchard wrote:
> The linker fixes up TOC. relocations, so prom_init_check.sh should
> ignore them.
Err, .TOC. you mean. Presumably something strips off the leading dot
somewhere?
> -btext_setup_display"
> +btext_setup_displa
On Mon, Sep 02, 2013 at 09:59:12AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2013-08-27 at 16:42 +0930, Alan Modra wrote:
> > The proper fix is to define a whole slew of new relocations and reloc
> > specifiers, and modify everything to use them, but that seems like too
>
ild up 64-bit values.)
The proper fix is to define a whole slew of new relocations and reloc
specifiers, and modify everything to use them, but that seems like too
much bother. I had ideas once upon a time to implement gas and ld
options that makes @ha and _HA report overflows, but haven'
On Tue, Aug 20, 2013 at 02:02:11PM +0930, Alan Modra wrote:
> On Tue, Aug 20, 2013 at 12:37:50PM +1000, Anton Blanchard wrote:
> > address of the trap instruction for our bug exception table. Maybe
> > we need a gcc builtin in which we can get a label on the trap
> > instr
nt foo(unsigned int *bar)
{
unsigned int holder_cpu;
holder_cpu = *bar & 0xffff;
BUG_ON(holder_cpu >= 32);
return 1;
}
--
Alan Modra
Australia Development Lab, IBM
--
Alan Modra
Australia Development Lab, IBM
___
ed the values as you indicated and
> it cleaned up the failing tst-cancel21* testcases on POWER8. I didn't try
> it on POWER7 yet.
I've tested on power7 using a copy of
sysdeps/unix/sysv/linux/sparc/bits/sigstack.h
as
sysdeps/unix/sysv/linux/powerpc/bits/sigstack.h
--
Alan
)
#15 0x1ffb6f84 in ?? ()
#16 0x10002274 in ?? ()
#17 0x10002430 in ?? ()
#18 0x10002644 in ?? ()
#19 0x10001a1c in ?? ()
#20 0x1fe17f0c in ?? ()
#21 0x1fffffe18134 in ?? ()
#22 0x
On Mon, May 13, 2013 at 04:48:19PM +1000, Anton Blanchard wrote:
> On Fri, 10 May 2013 22:18:27 +0100
> David Woodhouse wrote:
>
> > From: David Woodhouse
> >
> > Some versions of GCC apparently expect this to be provided by libgcc.
>
> Thanks Dave. We were di
oesn't optimize those unsigned chars
back to bit fields.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
p. This is not a powerpc64 specific problem. See
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Fixed in 4.8.0 and 4.7.3.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
es that ld inserts to extend branch reach. Did I mention
that ld -r is a bad idea?
One workaround might be to compile with -ffunction-sections.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
htt
ed into a .text containing normal functions with toc references by
ld -r. Well, you could stop using ld -r. Otherwise, try
.section ".text.save.restore","ax",@progbits
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-
toc relocations (from normal compiled code), so ld decides that
any function in that section must have a proper value for the toc
register. But calls to _savegpr0_29 don't have a following nop to
overwrite with a toc restore insn, hence the ld error.
Score another
On Thu, Jun 21, 2012 at 08:18:39PM +0930, Alan Modra wrote:
> Linker bug. That's not a sibling call, but a normal function return
> via an out-of-line register restore function.
I couldn't see how this might be occurring, then I remembered the
kernel has this horrible practise o
his with gcc-4.6 though. Or does this gcc-4.6 have
some of my recent mainline gcc patches enabling out-of-line
save/restore functions for -Os?
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
;ll need to use (and lose) one of the
non-volatile regs.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
mflrr0
> >bl 8 <.foo+0x8>
Yeah. Also, I should have used a different name for this mcount from
the standard 64-bit mcount.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxpp
On Sat, Jul 11, 2009 at 09:35:03AM +0930, Alan Modra wrote:
> Did you try the patch I posted?
/me reads other email. I see you did. Applying.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.
otes:
>
> binutils-2.19.50.0.1 is based on CVS binutils 2008 1007
> binutils-2.19.51.0.1 is based on CVS binutils 2009 0106
Yes, I already have good reason to suspect this patch
2008-10-22 Alan Modra
* ldlang.c (lang_output_section_find_by_flags): Handle non-alloc
sections.
een
_end3 = . ;
. = _end3;
So dot is restored after the orphan section sets it.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797 wrote:
> Kumar Gala wrote:
>>
>> On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:
>>
>>> On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
>>>> To further verify this if I s
orphan sections.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
result is:
>
> 1000 A _end
> c067f678 A _end2
> c068 A _end3
> c068 A _end4
Possibly some section with a zero vma is being placed before _end.
Generate a link map to see if this is so.
--
Alan Modra
Australia Development Lab, IBM
_
Try using thin archives instead.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
the .opd
section, a data section. The address of a function is that of its
descriptor, which nm correctly shows as a 'D' type symbol. A symbol
marking the start of the function code is unnecessary since you can
find that from the descriptor, so later compilers omit the "dot"
sy
ing in one monster .text then --relax quite likely
won't help. ld can't break apart an input section to insert
trampolines in the middle.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https:/
smart enough to insert trampolines. I don't know whether
> GNU ld is that smart.
It is, but you need to pass --relax to enable generation of the
trampolines.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-
On Tue, Oct 23, 2007 at 02:02:31PM +1000, Stephen Rothwell wrote:
> Anyone have any ideas?
The segfault with --emit-relocs and complaints about .fixup are linker
bugs. I'm about the commit fixes for both of these problems.
--
Alan Modra
Australia Development
r a long time, powerpc gcc has passed "-many" to the assembler,
which should avoid this sort of problem. Broken toolchain, I'd say.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
66 matches
Mail list logo
