Re: eu-stacktrace: roadmap and discussion thread

[Christian Hergert via Elfutils-devel]

On 5/11/23 12:27 PM, Serhei Makarov wrote:

When the sysprof libraries are available, we could also use sysprof's
mount namespace conversion code (in whatever eventual form it takes)
to get .eh_frame data.


Is it correct that we won't get a PERF_EVENT_MMAP2 for all the processes 
already running when the profiler starts?


If so, do you have a strategy for how we would go extract `build-id` to 
insert into the capture file and/or prime eu-stacktrace?


-- Christian

Sourceware joins Software Freedom Conservancy

[Mark Wielaard]

https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/

After various discussions and lots of positive feedback [1] [2] [3] [4]
Software Freedom Conservancy and Sourceware proudly announce that
Sourceware today joins SFC as a member project!

As the fiscal host of Sourceware, Software Freedom Conservancy will
provide a home for fundraising, legal protection and governance that
will benefit all projects under Sourceware's care.  We share one mission:
developing, distributing and advocactingfor Software Freedom.  Together
we will offer a worry-free, friendly home for core toolchain and
developer tool projects.

We are happy to discuss this in #overseers on irc.libera.chat now
18:00-19:00 UTC. And we will also start regular Overseers Open Office
Hours every second Friday of the month on irc at the same time.

Of course you are welcome to drop into the #overseers channel at any
time and we can also be reached through email and bugzilla:
https://sourceware.org/mission.html#organization

To support the Software Freedom Conservancy, please become a Sustainer
https://sfconservancy.org/sustainer

You can also donate directly to Sourceware:
https://sfconservancy.org/members/current/#Sourceware
as a directed donation (mention Sourceware in the comment or memo line)

See https://sfconservancy.org/donate/ for other ways to donate.

[1] https://sourceware.org/pipermail/overseers/2022q3/018802.html
[2] https://sourceware.org/pipermail/overseers/2022q3/018804.html
[3] https://sourceware.org/pipermail/overseers/2022q3/018834.html
[4] 
https://www.fsf.org/events/sourceware-infrastructure-a-presentation-and-community-q-a

https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/

Sourceware, one of the longest standing Free Software hosting platforms,
joins SFC

Important Free Software infrastructure project finds non-profit home

   May 15, 2023

   As a home for Free Software projects since 1998, Sourceware is a
   keystone in Free Software infrastructure. For almost 25 years
   Sourceware has been the long-time home of various core toolchain
   project communities. Projects like Cygwin, a UNIX API for Win32
   systems, the GNU Toolchain, including GCC, the GNU Compiler Colection,
   two C libraries, glibc and newlib, binary tools, binutils and elfutils,
   debuggers and profilers, GDB, systemtap and valgrind. Sourceware also
   hosts standard groups like gnu-gabi and the DWARF Debugging Standard.
   See the full list project hosted and services provided on the
   [1]Sourceware projects page.

   Becoming an SFC member project will improve future operations carried
   out by dedicated volunteers to and furthering the mission of Free
   Software hosting. This will accelerate the Sourceware [2]technical
   roadmap to improve and modernize the infrastructure.

   As the fiscal host of Sourceware, Software Freedom Conservancy will
   provide a home for fundraising, legal assistance and governance that
   will benefit all projects under Sourceware's care. We share one
   mission: developing, distributing and advocating for Software Freedom.
   And to offer a worry-free, friendly home for Free Software communities.
   We see a bright future working together. With Conservancy as fiscal
   sponsor, Sourceware will also be able to fundraise and have the
   community of volunteers work together with paid contractors and enter
   into contracts for managed infrastructure where appropriate.

   SFC looks to Sourceware's years of experience in providing outstanding
   infrastructure as an inspiration for improving the Free Software
   ecosystem both for other SFC projects, and also in furthering SFC's
   mission around campaigns to promote Software Freedom Infrastructure.
   For decades, Sourceware has shown that hosting Free Software projects
   with Free Software infrastructure is not only possible, but helps
   create and fosters the growth of relationships and networks within the
   Free Software communities. SFC is thrilled to join the powerful history
   of demonstrable experience to grow hosting options that are 100% free
   software, in the future to bring in new ideas, communities, and
   projects!

   Projects hosted by Sourceware are part of the core toolchain for
   GNU/Linux distros, embedded systems, the cloud and, through Cygwin,
   Windows. Back in 1984 Ken Thompson's Reflections on Trusting Trust
   already described how making the source code for these tools available
   is essential to create what today we call secure software supply
   chains. Sourceware provides robust infrastructure and services for
   projects to adopt secure collaboration and release policies. We forsee
   future cooperation with other Conservancy member projects, such as the
   [3]Reproducible Builds project which provides an
   independently-verifiable path to supply chain security. Additionally,
   Sourceware will leverage Conservancy advisory role in how community
   projects are impacted by and can comply with regulations l

Re: [PATCH 1/5] strip: Adapt src/strip -o -f on mips

[Ying Huang]

Hi,

在 2023/5/9 23:15, Mark Wielaard 写道:
> Hi,
>
> On Tue, 2023-04-11 at 16:12 +0800, Ying Huang wrote:
>> From: Ying Huang 
>>
>> In mips64 little-endian, r_info consists of four byte fields(contains
>> three reloc types) and a 32-bit symbol index. In order to adapt
>> GELF_R_SYM and GELF_R_TYPE, need convert raw data to get correct symbol
>> index and type.
> Is there a spec that describes this?
   

 references:

    https://www.linux-mips.org/pub/linux/mips/doc/ABI/elf64-2.4.pdf

    Page40 && Page41

>
> I see you adjusted elf.h to include:
>
> +#define ELF64_MIPS_R_TYPE(i) ((i) & 0xff)
> +#define ELF64_MIPS_R_TYPE2(i)   (((i) >> 8) & 0xff)
> +#define ELF64_MIPS_R_TYPE3(i)   (((i) >> 16) & 0xff)
>
> And various new relocation types for MIPS variants.
> Our elf.h comes from the glibc project. Have you also submitted these
> changes to libc-al...@sourceware.org ?
    Has submitted.

    https://sourceware.org/pipermail/libc-alpha/2023-May/148026.html

    https://sourceware.org/pipermail/libc-alpha/2023-May/148112.html

>
>>   libelf/elf_getdata.c: Some eu-utils use read-mmap method to map file,
>> so we need to malloc and memcpy raw data to avoid segment fault. After
>> modification, the correct value are saved in the malloced memory not in
>> process address space.
> Where do these segfaults show up?

>
>>   libelf/elf_updata.c: Because we converted the relocation info in mips
>> order when we call elf_getdata.c, so we need to convert the modified data
>> in original order bits before writing the data to the file.
    Has tested on big/little endian machine with big/little endian ELF file, 
all were OK.
> It feels like this is in the wrong place and doesn't take into account
> whether the program itself is running on a big or little endian
> machine.
>
> Maybe I am misunderstanding why this conversion is needed always. But I
> would have expected a specific conversion function for MIPS for
> ELF_T_REL and/or ELF_T_RELA (which are currently generic).
>
> Cheers,
>
> Mark
    1.Considering that some people directly use the original data instead of 
the interface function gelf_getrela;

    2.Because there is only one parameter, so can not modify the macro 
ELF64_R_TYPE；

    3.If the mips interface function is added, other packages using libelf will 
not be compatible with mips, and the place where gelf_getrela is used need be 
modified.

    Where do you think is the most suitable place to do mips conversion?

Thanks,

Ying

Re: [PATCH 1/5] strip: Adapt src/strip -o -f on mips

[Ying Huang]

HI,

>>   libelf/elf_getdata.c: Some eu-utils use read-mmap method to map file,
>> so we need to malloc and memcpy raw data to avoid segment fault. After
>> modification, the correct value are saved in the malloced memory not in
>> process address space.
> Where do these segfaults show up?
    The screenshot of the segment error was not uploaded successfully in the 
last email, upload again.

Thanks,

YIng