On Tue, Apr 22, 2025 at 10:24 AM Serhei Makarov wrote:
>
> On Tue, Apr 22, 2025, at 10:17 AM, Aaron Merey wrote:
> >> One question this raises re: the Dwfl_Process_Tracker structure and where
> >> its implementation should be located. In the patches, the Dwfl struct
> >> implementation includes
On Tue, 22 Apr 2025 at 13:36, Guinevere Larsen via Gcc wrote:
>
> On 4/21/25 12:59 PM, Mark Wielaard wrote:
> > Hi hackers,
> >
> > TLDR; When using https://patchwork.sourceware.org or Bunsen
> > https://builder.sourceware.org/testruns/ you might now have to enable
> > javascript. This should not
On 4/22/25 10:06 AM, Jonathan Wakely wrote:
On Tue, 22 Apr 2025 at 13:36, Guinevere Larsen via Gcc wrote:
On 4/21/25 12:59 PM, Mark Wielaard wrote:
Hi hackers,
TLDR; When using https://patchwork.sourceware.org or Bunsen
https://builder.sourceware.org/testruns/ you might now have to enable
jav
On Tue, Apr 22, 2025, at 10:17 AM, Aaron Merey wrote:
>> One question this raises re: the Dwfl_Process_Tracker structure and where
>> its implementation should be located. In the patches, the Dwfl struct
>> implementation includes a pointer to a Dwfl_Process_Tracker. I’m not sure if
>> elfuti
On Tue, Apr 22, 2025 at 9:53 AM Serhei Makarov wrote:
> On Tue, Apr 22, 2025, at 9:45 AM, Aaron Merey wrote:
> >
> > Let's move the process_tracker interface as well for additional
> > flexibility to modify if needed. As for a name, I like
> > libdwfl_stacktrace. It clearly communicates the purpos
On Mon, Apr 21, 2025, at 12:29 AM, Aaron Merey wrote:.
>
> I know we're close to the next release and I do want this work to be
> included. My proposal is to move the current API out of libdwfl and
> into a new library, as-is but clearly marked as experimental and
> subject to possible API/ABI
On 4/21/25 12:59 PM, Mark Wielaard wrote:
Hi hackers,
TLDR; When using https://patchwork.sourceware.org or Bunsen
https://builder.sourceware.org/testruns/ you might now have to enable
javascript. This should not impact any scripts, just browsers (or bots
pretending to be browsers). If it does ca
Hi Serhei,
On Tue, Apr 22, 2025 at 9:27 AM Serhei Makarov wrote:
>
> On Mon, Apr 21, 2025, at 12:29 AM, Aaron Merey wrote:.
> >
> > I know we're close to the next release and I do want this work to be
> > included. My proposal is to move the current API out of libdwfl and
> > into a new library,
On Tue, 22 Apr 2025, 14:17 Guinevere Larsen, wrote:
>
> On 4/22/25 10:06 AM, Jonathan Wakely wrote:
> > On Tue, 22 Apr 2025 at 13:36, Guinevere Larsen via Gcc
> > wrote:
> >> On 4/21/25 12:59 PM, Mark Wielaard wrote:
> >>> Hi hackers,
> >>>
> >>> TLDR; When using https://patchwork.sourceware.org
On Tue, Apr 22, 2025, at 9:45 AM, Aaron Merey wrote:
> Hi Serhei,
>
> On Tue, Apr 22, 2025 at 9:27 AM Serhei Makarov wrote:
>>
>> On Mon, Apr 21, 2025, at 12:29 AM, Aaron Merey wrote:.
>> >
>> > I know we're close to the next release and I do want this work to be
>> > included. My proposal is
Hi Mark,
On Tue, 22 Apr 2025, 4:00 am Mark Wielaard, wrote:
> Hi hackers,
>
> TLDR; When using https://patchwork.sourceware.org or Bunsen
> https://builder.sourceware.org/testruns/ you might now have to enable
> javascript. This should not impact any scripts, just browsers (or bots
> pretending
On 2025-04-22 14:06, Jonathan Wakely wrote:
> On Tue, 22 Apr 2025 at 13:36, Guinevere Larsen via Gcc
> wrote:
> >
> > On 4/21/25 12:59 PM, Mark Wielaard wrote:
> > > Hi hackers,
> > >
> > > TLDR; When using https://patchwork.sourceware.org or Bunsen
> > > https://builder.sourceware.org/testruns/
Sourceware infrastructure community updates for Q1 2025
Sourceware has provided the infrastructure for core toolchain
and developer tools projects for more than 25 years.
https://sourceware.org/sourceware-25-roadmap.html
Over the last couple of years, Sourceware has transformed from a
purely volu
On Tue, Apr 22, 2025, at 10:17 AM, Aaron Merey wrote:
> dwfl_st or dwflst prefixes work for me. I think I slightly prefer
> dwfl_st. As for where to define Dwfl_Process_tracker let's try to keep
> it to the new dwfl_stacktraceP.h and if possible use forward
> declarations to avoid circular depen
Hi -
> CCLD libdw.so
> /usr/bin/ld: ../libdwfl/libdwfl_pic.a(dwfl_module_getdwarf.os): in function
> `open_elf':
> Calling a public function across the library boundary should be no problem,
> but we run into this -- circular dependency?
It might just require the libdw.so LDFLAGS/LDADD to
On Tue, Apr 22, 2025, at 6:26 PM, Frank Ch. Eigler wrote:
> Hi -
>
>> CCLD libdw.so
>> /usr/bin/ld: ../libdwfl/libdwfl_pic.a(dwfl_module_getdwarf.os): in function
>> `open_elf':
>> Calling a public function across the library boundary should be no problem,
>> but we run into this -- circu
16 matches
Mail list logo
