All,
It has been 30+ years since I played around with some assembly.
Just for learning purposes I'm doing some more playing :-)

First some information :
The system I'm on:
[martijn@fedora asm]$ uname -a
Linux fedora 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
[martijn@fedora asm]$

Then for completeness also the program (for this particular problem I do not think it's that relevant :-) ):
[martijn@fedora asm]$ cat een.asm
section .data

section .text

global _start

_start:
mov al, 1 ; mov 1 into the al register
add al, 1 ; add one to the al register

mov rax, 60 ; syscall for exit
mov rdi, 0 ; Return code
syscall
[martijn@fedora asm]$

Then I compile, link and run the progrm:
[martijn@fedora asm]$ nasm -f elf64 -gdwarf een.asm
[martijn@fedora asm]$ ld -m elf_x86_64 -o een een.o
[martijn@fedora asm]$ ./een
[martijn@fedora asm]$

So far so good (I think):

But I want to see what is actually happening, so I want to see it in my debugger :

[martijn@fedora asm]$ gdb een
GNU gdb (GDB) Fedora 12.1-2.fc36
.....
.....
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from een...
(gdb) list
1 section .data
2 3 section .text
4 5 global _start
6 7 _start:
8 mov al, 1 ; mov 1 into the al register
9 10 add al, 1 ; add one to the al register
(gdb) break 8
No line 8 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb)

As you can see I can not set a breakpoint. And that's my problem.
Whitout breakpoints I can not step through my program.

Does anyone have any pointers/tips/trics on how to resolve this issue.

(I know myself...I probably oversee the obvious...do not hesitate to point that out)

Best Regards,
Martijn Bos

On 2023-11-30, Martijn Bos wrote:
> Does anyone have any pointers/tips/trics on how to resolve this issue.
>
> (I know myself...I probably oversee the obvious...do not hesitate to point that out)

I would just use the disassembler, for example `x/10i _start` instead of
`list _start`!

I don't think nasm will generate line info automatically (just names),
so you would set breakpoints on symbols `b _start` or addresses `b
*0x401000)

However... gas can do it if you prefer this style. Your code is
basically valid gas syntax already. Just add `.intel_syntax noprefix`
and add a `.` before directives, e.g. .section, .global, etc, and use #
for comments instead of ;.

Then you can use `as -g foo.asm -o foo.o` instead.

Now `b foo.asm:123` should work.

Nasm and gas are both great assemblers, it doesn't make much difference
which one you choose while you're getting started.

Tavis.

--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger taviso@sdf.org
_\_V _( ) _( ) @taviso

On 2023-12-02, Tavis Ormandy <taviso@nospicedham.gmail.com> wrote:
> On 2023-11-30, Martijn Bos wrote:
>> Does anyone have any pointers/tips/trics on how to resolve this issue.
>>
>> (I know myself...I probably oversee the obvious...do not hesitate to point that out)
>
> I would just use the disassembler, for example `x/10i _start` instead of
> `list _start`!
>
> I don't think nasm will generate line info automatically (just names),
> so you would set breakpoints on symbols `b _start` or addresses `b
> *0x401000)
>
> However... gas can do it if you prefer this style. Your code is
> basically valid gas syntax already. Just add `.intel_syntax noprefix`
> and add a `.` before directives, e.g. .section, .global, etc, and use #
> for comments instead of ;.
>
> Then you can use `as -g foo.asm -o foo.o` instead.
>
> Now `b foo.asm:123` should work.
>
> Nasm and gas are both great assemblers, it doesn't make much difference
> which one you choose while you're getting started.
>
> Tavis.
>

NASM can generate debugging information which I believe will generate
line info. Pass '-F dwarf' option to nasm if under Linux, and you should see each
line of source in the debugger.

ie.
nasm -f elf32 -F dwarf hello.asm

P.S., I assume you're the same Tavis who is known for your FVWM
config?

Thank you so much for this information.

Today I have to visit my parents (my father turned 83 :-))
So...no testing today.

I'll report back hopefully tomorrow.

Best Regards,
Martijn

Op zaterdag 2 december 2023 om 01:36:03 UTC+1 schreef Tavis Ormandy:
> On 2023-11-30, Martijn Bos wrote:
> > Does anyone have any pointers/tips/trics on how to resolve this issue.
> >
> > (I know myself...I probably oversee the obvious...do not hesitate to point that out)
> I would just use the disassembler, for example `x/10i _start` instead of
> `list _start`!
>
> I don't think nasm will generate line info automatically (just names),
> so you would set breakpoints on symbols `b _start` or addresses `b
> *0x401000)
>
> However... gas can do it if you prefer this style. Your code is
> basically valid gas syntax already. Just add `.intel_syntax noprefix`
> and add a `.` before directives, e.g. .section, .global, etc, and use #
> for comments instead of ;.
>
> Then you can use `as -g foo.asm -o foo.o` instead.
>
> Now `b foo.asm:123` should work.
>
> Nasm and gas are both great assemblers, it doesn't make much difference
> which one you choose while you're getting started.
>
> Tavis.
>
> --
> _o) $ lynx lock.cmpxchg8b.com
> /\\ _o) _o) $ finger tav...@sdf.org
> _\_V _( ) _( ) @taviso

Hi,

Thanks for taking the tmie to answer.
See my remarks inline

Best regards,
Martijn

Op zaterdag 2 december 2023 om 10:24:46 UTC+1 schreef Borax Man:
> On 2023-12-02, Tavis Ormandy <tav...@nospicedham.gmail.com> wrote:
> > On 2023-11-30, Martijn Bos wrote:
> >> Does anyone have any pointers/tips/trics on how to resolve this issue.
> >>
> >> (I know myself...I probably oversee the obvious...do not hesitate to point that out)
> >
> > I would just use the disassembler, for example `x/10i _start` instead of
> > `list _start`!
> >
> > I don't think nasm will generate line info automatically (just names),
> > so you would set breakpoints on symbols `b _start` or addresses `b
> > *0x401000)
> >
> > However... gas can do it if you prefer this style. Your code is
> > basically valid gas syntax already. Just add `.intel_syntax noprefix`
> > and add a `.` before directives, e.g. .section, .global, etc, and use #
> > for comments instead of ;.
> >
> > Then you can use `as -g foo.asm -o foo.o` instead.
> >
> > Now `b foo.asm:123` should work.
> >
> > Nasm and gas are both great assemblers, it doesn't make much difference
> > which one you choose while you're getting started.
> >
> > Tavis.
> >
> NASM can generate debugging information which I believe will generate
> line info. Pass '-F dwarf' option to nasm if under Linux, and you should see each
> line of source in the debugger.
>
> ie.
> nasm -f elf32 -F dwarf hello.asm
>

From 'man nasm' I quote:
==quote==
-F format
Specifies the debug information format. To see a list of valid output formats, use the -y option (for example -felf -y).

-g
Causes nasm to generate debug information.

-gformat
Equivalent to -g -F format.>
==unquote==

When I tried your suggestion I got the same result:
(gdb) break 8
No line 8 in the current file.

So i tried -gdwarf

Same result.

Maybe I should also give the linker some options to handle debug information (?)

Anyway....I'm off for familiy matters.

I'll try further tomorrow

> P.S., I assume you're the same Tavis who is known for your FVWM
> config?

On 2023-12-02, Borax Man wrote:
> NASM can generate debugging information which I believe will generate
> line info. Pass '-F dwarf' option to nasm if under Linux, and you should see each
> line of source in the debugger.

You're thinking of line markers I think (like %line 123), but I think
Martijn wants the assembler to do that automatically so that b
foo.asm:123 works, like it does in gas.

As far as I know nasm won't do that?

>
> P.S., I assume you're the same Tavis who is known for your FVWM
> config?
>

Hah, yes, that was me :)

Tavis.

--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger taviso@sdf.org
_\_V _( ) _( ) @taviso

On 2023-12-02, Tavis Ormandy <taviso@nospicedham.gmail.com> wrote:
> On 2023-12-02, Borax Man wrote:
>> NASM can generate debugging information which I believe will generate
>> line info. Pass '-F dwarf' option to nasm if under Linux, and you should see each
>> line of source in the debugger.
>
> You're thinking of line markers I think (like %line 123), but I think
> Martijn wants the assembler to do that automatically so that b
> foo.asm:123 works, like it does in gas.
>
> As far as I know nasm won't do that?
>

I did a test using nasm with the '-F dwarf' and '-g' parameters, and I
was able to add breakpoints in GDB specifying the line using the
syntax you mentioned.

I didn't mention "-g" before, oops.

>>
>> P.S., I assume you're the same Tavis who is known for your FVWM
>> config?
>>
>
> Hah, yes, that was me :)
>
> Tavis.
>

Cool. Avid and longtime FVWM user here.

On 2023-12-03, Borax Man wrote:
> On 2023-12-02, Tavis Ormandy <taviso@nospicedham.gmail.com> wrote:
>> On 2023-12-02, Borax Man wrote:
>>> NASM can generate debugging information which I believe will generate
>>> line info. Pass '-F dwarf' option to nasm if under Linux, and you should see each
>>> line of source in the debugger.
>>
>> You're thinking of line markers I think (like %line 123), but I think
>> Martijn wants the assembler to do that automatically so that b
>> foo.asm:123 works, like it does in gas.
>>
>> As far as I know nasm won't do that?
>>
>
> I did a test using nasm with the '-F dwarf' and '-g' parameters, and I
> was able to add breakpoints in GDB specifying the line using the
> syntax you mentioned.

Weird.... and this is for elf64?

Perhaps you have a newer version than me, good to know it will arrive eventually!

Tavis.

--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger taviso@sdf.org
_\_V _( ) _( ) @taviso

On 3 Dec 2023 16:43:39 GMT
Tavis Ormandy <taviso@nospicedham.gmail.com> wrote:

> On 2023-12-03, Borax Man wrote:
> > On 2023-12-02, Tavis Ormandy <taviso@nospicedham.gmail.com> wrote:
> >> On 2023-12-02, Borax Man wrote:
> >>> NASM can generate debugging information which I believe will generate
> >>> line info. Pass '-F dwarf' option to nasm if under Linux, and you should see each
> >>> line of source in the debugger.
> >>
> >> You're thinking of line markers I think (like %line 123), but I think
> >> Martijn wants the assembler to do that automatically so that b
> >> foo.asm:123 works, like it does in gas.
> >>
> >> As far as I know nasm won't do that?
> >>
> >
> > I did a test using nasm with the '-F dwarf' and '-g' parameters, and I
> > was able to add breakpoints in GDB specifying the line using the
> > syntax you mentioned.
>
> Weird.... and this is for elf64?
>
> Perhaps you have a newer version than me, good to know it will arrive eventually!
>
> Tavis.

I tested this on Debian 12... 32 bit (my laptop is old).

On 2023-12-04, Borax Man <rotflol2@nospicedham.hotmail.com> wrote:
> On 3 Dec 2023 16:43:39 GMT
> Tavis Ormandy <taviso@nospicedham.gmail.com> wrote:
>
>> On 2023-12-03, Borax Man wrote:
>> > On 2023-12-02, Tavis Ormandy <taviso@nospicedham.gmail.com> wrote:
>> >> On 2023-12-02, Borax Man wrote:
>> >>> NASM can generate debugging information which I believe will generate
>> >>> line info. Pass '-F dwarf' option to nasm if under Linux, and you should see each
>> >>> line of source in the debugger.
>> >>
>> >> You're thinking of line markers I think (like %line 123), but I think
>> >> Martijn wants the assembler to do that automatically so that b
>> >> foo.asm:123 works, like it does in gas.
>> >>
>> >> As far as I know nasm won't do that?
>> >>
>> >
>> > I did a test using nasm with the '-F dwarf' and '-g' parameters, and I
>> > was able to add breakpoints in GDB specifying the line using the
>> > syntax you mentioned.
>>
>> Weird.... and this is for elf64?
>>
>> Perhaps you have a newer version than me, good to know it will arrive eventually!
>>
>> Tavis.
>
> I tested this on Debian 12... 32 bit (my laptop is old).
>
>

Just to clarify, NASM version 2.16.01.

All,

Reporting back was taking a little longer then I expexted ...sorry.

Anyway.
I still cannot get the debugger to break on a linenumber. If I read correctly you had more luck (or wisdom).

However the method mentioned earlier : x/10i _start does work!

Did really helps me, I was not aware of x being able to display instructions.
Then I was able to set a breakpoint on the adress that I need/want.

And now I can start debugging.
Stepping through the program with "s" was running through the program immediately, so I found that I had to use "si" (Step Instruction)

It still seams/seems silly to me that I can list a piece of a program in gdb, but can not set a break on the kines I think trhe debugger knows:

(gdb) list
1 section .data
2 3 section .text
4 5 global _start
6 7 _start:
8 mov al, 1 ; mov 1 into the al register
9 10 mov rax, 60 ; syscall for exit
(gdb) b 8
No line 8 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb)

Anyway....I can dust off some more old assembly knowledge now.

Thanks all for you help and time.

Best Regards,
Martijn

Op maandag 4 december 2023 om 13:12:49 UTC+1 schreef Borax Man:
> On 2023-12-04, Borax Man <rotf...@nospicedham.hotmail.com> wrote:
> > On 3 Dec 2023 16:43:39 GMT
> > Tavis Ormandy <tav...@nospicedham.gmail.com> wrote:
> >
> >> On 2023-12-03, Borax Man wrote:
> >> > On 2023-12-02, Tavis Ormandy <tav...@nospicedham.gmail.com> wrote:
> >> >> On 2023-12-02, Borax Man wrote:
> >> >>> NASM can generate debugging information which I believe will generate
> >> >>> line info. Pass '-F dwarf' option to nasm if under Linux, and you should see each
> >> >>> line of source in the debugger.
> >> >>
> >> >> You're thinking of line markers I think (like %line 123), but I think
> >> >> Martijn wants the assembler to do that automatically so that b
> >> >> foo.asm:123 works, like it does in gas.
> >> >>
> >> >> As far as I know nasm won't do that?
> >> >>
> >> >
> >> > I did a test using nasm with the '-F dwarf' and '-g' parameters, and I
> >> > was able to add breakpoints in GDB specifying the line using the
> >> > syntax you mentioned.
> >>
> >> Weird.... and this is for elf64?
> >>
> >> Perhaps you have a newer version than me, good to know it will arrive eventually!
> >>
> >> Tavis.
> >
> > I tested this on Debian 12... 32 bit (my laptop is old).
> >
> >
> Just to clarify, NASM version 2.16.01.