your patch "RISC-V: Add PT_RISCV_ATTRIBUTES and add it to PHDR"

your patch "RISC-V: Add PT_RISCV_ATTRIBUTES and add it to PHDR"

[Jan Beulich]

Kito,

it looks like it is this patch which has caused the ld-elf/seg-2
ld testcase to be failing in 2.38, as compared to 2.37. It's the
extra phdr which looks to be getting in the way. The testcase
already has a fair number of #xfail targets - perhaps RISC-V wants
adding there, too?

Jan

Re: your patch "RISC-V: Add PT_RISCV_ATTRIBUTES and add it to PHDR"

[Nelson Chu]

Hi Jan,

On Thu, Feb 10, 2022 at 8:38 PM Jan Beulich via Binutils
<binutils@sourceware.org> wrote:
>
> Kito,
>
> it looks like it is this patch which has caused the ld-elf/seg-2
> ld testcase to be failing in 2.38, as compared to 2.37. It's the
> extra phdr which looks to be getting in the way. The testcase
> already has a fair number of #xfail targets - perhaps RISC-V wants
> adding there, too?

After building the
rv32i-newlib/rv64gc-newlib/rv32gc-glibc/rv64gc-glibc toolchains, with
master branches of gcc and glibc, and the binutils 2.38 release
branch, I don't see the error you mentioned.  Could you give more
information, like which gcc or glibc branch you are using? Or other
details that might help.

Thanks
Nelson

Re: your patch "RISC-V: Add PT_RISCV_ATTRIBUTES and add it to PHDR"

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On 11.02.2022 06:56, Nelson Chu wrote:
> On Thu, Feb 10, 2022 at 8:38 PM Jan Beulich via Binutils
> <binutils@sourceware.org> wrote:
>> it looks like it is this patch which has caused the ld-elf/seg-2
>> ld testcase to be failing in 2.38, as compared to 2.37. It's the
>> extra phdr which looks to be getting in the way. The testcase
>> already has a fair number of #xfail targets - perhaps RISC-V wants
>> adding there, too?
> 
> After building the
> rv32i-newlib/rv64gc-newlib/rv32gc-glibc/rv64gc-glibc toolchains, with
> master branches of gcc and glibc, and the binutils 2.38 release
> branch, I don't see the error you mentioned.  Could you give more
> information, like which gcc or glibc branch you are using? Or other
> details that might help.

Well, I'm observing this in a cross build on ix86. As per the test I
don't see how gcc could be involved (the sole source file is an
assembly one), and it being a dump test glibc also shouldn't matter.
Attached the (gzip-ed) binary that I've reproduced using the ld
options logged and the object file found in ld/tmpdir/. It clearly
shows that the processor-specific program header comes first, which
is what is causing the test to fail (from all I can tell).

Jan

[-- Attachment #2: seg-2.gz --]
[-- Type: application/x-gzip, Size: 14952 bytes --]